Date: Mon, 05 Feb 2001 11:43:33 -0800 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@aciri.org> Cc: Patrick Bihan-Faou <patrick@netzuno.com>, freebsd-net@FreeBSD.ORG, richw@webcom.com, julian@FreeBSD.ORG Subject: Re: BRIDGE breaks ARP? (more info) Message-ID: <3A7F0265.80104C75@elischer.org> References: <200102052011.f15KBJb24985@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > > 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. who cares about clusters if bridging is disabled? I want bridging to completely dissappear if it's disabled in the sysctl. If this is changing the behaviour of bridging when it is enabled then I misread the code and I will go check it again now. .. The reason I put it in -stable is because people were complaining to me that if they compiled it with bridging compiled in but disabled then it was screwing up Netgraph bridging. > > 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 > > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v 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?3A7F0265.80104C75>