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

[Eygene Ryabinkin]

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 
 > 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