kern/109815: wrong interface identifier at pfil_hooks for vlans
rea-fbsd at codelabs.ru
Sun Mar 4 06:30:12 UTC 2007
The following reply was made to PR kern/109815; it has been noted by GNATS.
From: Eygene Ryabinkin <rea-fbsd at codelabs.ru>
To: Roman Kurakin <rik at inse.ru>
Cc: FreeBSD-gnats-submit at FreeBSD.org, rik at FreeBSD.org, glebius at FreeBSD.org,
andre at FreeBSD.org, thompsa at 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
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.
More information about the freebsd-bugs