Date: Mon, 5 Feb 2001 12:11:19 -0800 (PST) From: Luigi Rizzo <rizzo@aciri.org> To: patrick@netzuno.com (Patrick Bihan-Faou) Cc: freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) Message-ID: <200102052011.f15KBJb24985@iguana.aciri.org> In-Reply-To: <HJEEKLMFLKEOKHOKNPBMAEBECKAA.patrick@netzuno.com> from Patrick Bihan-Faou at "Feb 5, 2001 2:45:28 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
as a matter of fact -- i believe the recent commit by julian on netinet/if_ether.c (1.74 -> 1.75 and 1.64.2.5 -> 1.64.2.6, specifically the first part of the patch) is responsible for this bug. Essentially: before that patch, as the comment near to the code clearly says, if bridging was active, an address match must be attempted irrespective of the interface the packet is coming from, because you do not know on which side the client is. After this patch, when bridging is active, the code never attempts to match the address and so an ARP reply is never generated. Hate to say this, but I do not understand the hurry for applying this patch without testing that it does the right thing and without contacting the committers involved with this code (me in this case). The PR was reported only a few days ago, it is not critical at all, and is wrong anyways because what you really want, even if you have bridging enabled, is to try an address match only on the interfaces which are part of the same cluster the input interface belongs to. cheers luigi > > I should add something else. My bridge =does= pass ARP info between > > the two bridged NIC's. Thus, for example, a machine on the "rl0" side > > of the bridge can successfully use a default Internet gateway which is > > on the "xl0" side of the bridge (and "arp -a" on the rl0-side machine > > shows the hardware address of the xl0-side gateway). > > > > So the problem doesn't seem to have anything to do with ARP bridging. > > Even though ARP packets are being passed through the bridge, the bridge > > itself doesn't reply to ARP requests asking it for its own MAC address. > > (Or, to be more precise, it sometimes does send out ARP replies, but > > only sporadically and unpredictably.) > > > I am seeing exactly the same behaviour here. I have up-to-date > FreeBSD -STABLE code. What I am seeing is that the FreeBSD machine running > bridging does not answer ARP request asking for its own mac address. At > first I thought I was seeing a me-only problem, but it seems that it is not > the case. Also as Rich mentions, this problem is sporadic: it will work > sometimes (i.e. FreeBSD answers the ARP request) but not at other times. I > have not been able to determine the set of conditions that make the problem > occur. The behaviour seems consistent for an entire "booted" session: if it > works when the machine starts, it will always work, if it does not work when > the machine starts, it will never work. > > Also I am using a combination of "rl", "ed" and "xl" cards. > > I have all the setup to do testing and tracing of this problem. So if > anybody has suggestions I am available, this very problem is #1 on my work > list... > > Patrick. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102052011.f15KBJb24985>