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

[Mauro Mozzarelli]

Mathias,

Thank you for the patch

I just built SNAPSHOT r3526-bececcc with your "fix arp package leaking 
in xrx200"  patch and the problem is solved.

Excellent work.

Thank you!


Mauro



On 18/02/17 15: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.
>
> Mathias
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev