Date: Mon, 05 Feb 2001 11:38:55 -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: <3A7F014E.FC4536C@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.
all the patch does is look at the sysctl variable, and if the sysctl variable
says that Bridging is turned off, then it acts exactly as if bridging were
not compiled in. At least that's my reading of it and it is what id seemed
to do when I tested it.
>
> 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.
yes but my reading of it is that the behaviour should be unchanged for
when bridging is turned on.
>
> 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?3A7F014E.FC4536C>