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

Mathias Kresin dev at kresin.me
Sat Feb 18 07:57:54 PST 2017

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.


More information about the Lede-dev mailing list