if_bridge forwarding incorrectly forwarding ethernet link local addressed packets (e.g. lldp)

[Tom Judge]

Andrew Thompson wrote:
> On Thu, Jan 17, 2008 at 02:22:53AM +0000, Tom Judge wrote:
>> Hi,
>>
>> As brought up in the thread "Programming interface MAC filter without 
>> enabling PROMISC on an interface from user space." it would seem that 
>> if_bridge does not conform to IEEE 802.1D-2004.  Which states:
>>
>> <quote>
>> 7.12.6 Reserved addresses
>> Frames containing any of the group MAC Addresses specified in Table 7-10 in 
>> their destination address field shall not be relayed by the Bridge. They 
>> are configured in the Permanent Database. Management shall not provide the 
>> capability to modify or remove these entries from the Permanent or the 
>> Filtering Databases. These group MAC Addresses are reserved for assignment 
>> to standard protocols, according to the criteria for such assignments 
>> (Clause 5.5 of ISO/IEC TR 11802-2).
>> </quote>
>>
>>
>> <table 7-10>
>>                      Assignment                            Value
>> Bridge Group Address                              01-80-C2-00-00-00
>> IEEE Std 802.3x Full Duplex PAUSE operation       01-80-C2-00-00-01
>> IEEE Std 802.3ad Slow_Protocols_Multicast address 01-80-C2-00-00-02
>> IEEE P802.1X PAE address                          01-80-C2-00-00-03
>> Reserved for future standardization               01-80-C2-00-00-04
>> Reserved for future standardization               01-80-C2-00-00-05
>> Reserved for future standardization               01-80-C2-00-00-06
>> Reserved for future standardization               01-80-C2-00-00-07
>> Reserved for future standardization               01-80-C2-00-00-08
>> Reserved for future standardization               01-80-C2-00-00-09
>> Reserved for future standardization               01-80-C2-00-00-0A
>> Reserved for future standardization               01-80-C2-00-00-0B
>> Reserved for future standardization               01-80-C2-00-00-0C
>> Reserved for future standardization               01-80-C2-00-00-0D
>> Reserved for future standardization               01-80-C2-00-00-0E
>> Reserved for future standardization               01-80-C2-00-00-0F
>> </table 7-10>
>>
>> Should I raise a PR about this?
> 
> Yes please, just paste the same content in. Thanks for investigating
> this, I will sort out a patch.
> 
> 
> Andrew

Hi,

I have raised a PR about this: kern/119744 
<http://www.freebsd.org/cgi/query-pr.cgi?pr=119744>

I also put a possible solution into the PR.  I'm not sure if the boolean 
logic on eh->ether_dhost is valid though:
if (eh->ether_dhost & 0xFFFFFFFFFFF0 == 0x0180C2000000) {}

How ever the symantics of the logic should be correct even if the code 
is wrong.  I have not tested this fix at all (not even compile).

Tom