Date: Sun, 4 Mar 2007 06:30:12 GMT From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge Message-ID: <200703040630.l246UCDF015971@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/109815; it has been noted by GNATS. From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: Roman Kurakin <rik@inse.ru> Cc: FreeBSD-gnats-submit@FreeBSD.org, rik@FreeBSD.org, glebius@FreeBSD.org, andre@FreeBSD.org, thompsa@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge Date: Sun, 4 Mar 2007 09:22:03 +0300 Sun, Mar 04, 2007 at 01:08:40AM +0300, Roman Kurakin wrote: > The idea behind current code could be that in case of bridge the interface for > which this > packet in?nded is much more important than the physical interface it is arrived > from. So, you're saying the following: let us have two interfaces in the bridge ifA and ifB with the MAC-A and MAC-B. In the current situation packet coming from the physical interface ifA but destined to the MAC-B, then the interface seen by the packet filter will be ifB and not the ifA. Right? In principle, this situation can be used for something. But then we should at least teah BPF to behave this way, because as you remember from spending three hours before the console with me and trying to diagnose the problem with tcpdump we were amazed to see the discrepance between bpf and pfil. So it should be at least documented. But as I understand, my patch will let the described situation to work as usual -- packets will still be delivered to the ifB, but packet filter will see the physical incoming interface. The patch should not break the delivery of the packet since all I do is the change of the rcvif. Or I am wrong? > If this is the case, than it would be much better do the same logic for ifp and > in case > it is not that interface to check the list. This will fix the problem in case > of vlans and > will leave the old behavior for the other cases. > > Any comments? I am eager to listen to the comments on the current behaviour too, because as I understand the situation, the offending code in if_bridge was just written with the thoughts that the MAC address in a single system uniquely identifies the interface. -- Eygene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703040630.l246UCDF015971>