kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge

Eygene Ryabinkin rea-fbsd at
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>
To: Roman Kurakin <rik at>
Cc: FreeBSD-gnats-submit at, rik at, glebius at,
	andre at, thompsa at
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.

More information about the freebsd-bugs mailing list