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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev