[LEDE-DEV] [PATCH] BT Home Hub 5A: configure Red Ethernet as DMZ interface (FS#490) and fix Red Ethernet switch port (FS#390)

[Felix Fietkau]

On 2017-02-18 16:57, Mathias Kresin wrote:
> 17.02.2017 11:42, Mauro Mozzarelli:
>> The BT Home Hub routers described in the scenario(s) below are connected
>> also on the LAN side.
>>
>> I ran further tests in the first SCENARIO (Red Ethernet as eth0.2)
>> monitoring the red Ethernet WAN end with wireshark and I saw arp
>> requests coming from the Red Ethernet that have both mac address and IP
>> that belong to the LAN port. I saw also arp requests with the correct
>> mac and IP from the Red Ethernet, but these requests did not get a reply
>> when the destination was another BT Home Hub 5 with the same
>> configuration (and only in that case). Both routers were on the same
>> subnets on LAN on the Yellow switch and WAN on the Red Ethernet.
>>
>> This does not happen with the unmodified code where the Red Ethernet is
>> configured as eth1.2.
>>
>> It looks like the Ethernet ports get into an identity crisis with the
>> patch.
> 
> So what you are length trying to describe is that ARP packages from the 
> router are send to all vlans, right?
> 
> That bug isn't strictly related to my patch, it is just that my changes 
> make the bug more obvious.
> 
> I added "lantiq: fix arp package leaking in xrx200 ethernet driver" to 
> my staging tree to fix this issue as well. Would you please add this 
> patch to your tree and test if it fixes the ARP package leakage for you. 
> A word of warning, it might be that the patch introduces new issues.
> 
> @Felix: Would you please do a review of my changes. You added the 
> function in question with c536da3 "lantiq: add VLAN handling fixes to 
> xrx200 ethernet driver" but unfortunately without commit message.
> 
> I'm not sure about the purpose of the introduced function or which 
> (reproducible) issue gets fixed with the function. Might be that there 
> is some kind of logic bug in the function that I workaround for 
> broadcast packages now. The best case would be if you only missed that 
> is_multicast_ether_addr() is true for the broadcast address as well and 
> the function was never intended to handle broadcast packages.
This function actually was intended to handle broadcast packets, and in
the tests that I made back when I wrote the patch, it resolved an issue
pretty much like you're describing.

So the patch in your staging tree which adds the is_broadcast_ether_addr
check is wrong, and we need to look into why the portmap feature for
multicast packets doesn't work properly.

If you can reproduce the issue, please add a printk to show the data of
the special tag for packets which are leaking onto the wrong vlan, as
well as the switch configuration and the values of hw->vlan_port_map.

- Felix