kernel/2202: bridge does not forward ARP replies

[cmarby@lhasa.harvard.edu]

>Number:         2202
>Category:       kernel
>Synopsis:       Bridge does not forward ARP replies
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 26 14:10:01 MST 2001
>Last-Modified:
>Originator:     Craig A. Marby
>Organization:
Harvard University
>Release:        2.7 (Generic) #25 Sat May 13 18:04:26 MDT 2000
>Environment:
	System      : OpenBSD 2.7
	Architecture: OpenBSD.i386
	Machine     : i386
        Network cards: 2 3com 3c905B ethernet cards both at 100baseTX
>Description:
	I've been using OpenBSD 2.6 and later for a few months. I've tried
several recent versions, including versions after bug 1085 was fixed. All
of the versions I have tried have exhibited problems with ARP
forwarding by the kernel when using two 3com 3c905B ethernet cards configured
as a transparent firewall.
	My symptoms have no correlation with uptime or amount of
traffic being handled by the bridge. I have no idea if my problem is specific
to the particular ethernet cards I am using (which appear as xl0 and xl1).
	The basic symptom is that the OpenBSD box acting as a transparent
firewall *erratically* forwards ARP replies from the outside world to the
machines that it is protecting. Outgoing ARP requests always go through, 
the responses only sometimes are forwarded -- it is unpredicatable.
My Windows 9x machines appear to be especially susceptible. Obviously
no IP traffic can occur until the sender knows the MAC address to send to.
	The problem was tracked down using the tcpdump program looking at
the traffic appearing on each of the two interfaces of the bridge.
	I believe that this is a serious problem as this kind of failure
essentially renders the firewall a very weak link in the network
topology.
>How-To-Repeat:
	Boot OpenBSD using a box doing basically just transparent bridging via
2 3Com 3c905B ethernet cards. Put a windoze box on one side, and (say)
its default gateway, or someother machine on the far side of the bridge.
Try to send IP traffic to the gateway. Test IP traffic for multiple
connections (web surfing is an excellent test) for say 20 mins. My bridge
is configured to block non-ip and multicast traffic, which should not be
an issue. I am using IP filtering, but setting pass through all still
exhibits this problem.
	At one point I was getting what appeared to be an approximately
10 minute cycle in which the windoze box would work fine for 10mins, and then
the bridge would stop forwarding ARP replies needed when windows flushed the
ARP entry for the gateway. The openBSD box fails to forward the ARP resonse
needed by the windoze box. After about 10mins an ARP reponse would get through
to the windoze machine and things would work again for 10mins.
	One great way to work around this problem would be to use proxy ARP. 
I'd love to do that, but it only really make sense for me if the bridge could
block ARP traffic from being forwarded. That's not currently available.

>Fix:
>Audit-Trail:
>Unformatted: