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 [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> >
--
__--_|\ Julian Elischer
/ \ [EMAIL PROTECTED]
( OZ ) World tour 2000-2001
---> X_.---._/
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
