netdev - Re: [RFC 0/3] VLANs, DSA switches and multiple bridges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Jan 2020 20:53:57 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Pali Rohár <pali.rohar@...il.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Vivien Didelot <vivien.didelot@...il.com>
Cc:     Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org,
        Jiri Pirko <jiri@...nulli.us>,
        Ivan Vecera <ivecera@...hat.com>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [RFC 0/3] VLANs, DSA switches and multiple bridges



On 1/1/2020 10:07 AM, Pali Rohár wrote:
> On Wednesday 01 January 2020 17:30:14 Russell King - ARM Linux admin wrote:
>> I think the most important thing to do if you're suffering problems
>> like this is to monitor and analyse packets being received from the
>> DSA switch on the host interface:
>>
>> # tcpdump -enXXi $host_dsa_interface
> 
> Hello Russell! Main dsa interface for me is eth0 and it does not see any
> incoming vlan tagged packets. (Except that sometimes for those 5 minutes
> periods it sometimes see them. And when tcpdump saw them also they
> arrived to userspace.)

Based on your description it sounds like there is possibly an address
learning issue, which is why the ATU patches that Russell mentioned
(latest I know are available at [1]) could come in handy.

[1]: https://github.com/vivien/linux/tree/dsa/debugfs

Since this is a DSA set-up, you could try a few things to isolate the
problems further:

- if you keep the same MAC address for wan and wan.10 does the problem
go away? If so, this could suggest that the DSA master network device
driver potentially has a problem with programming its receive filter for
other unicast MAC addresses than the default one (more on that below)

- if your DSA master supports receive VLAN filter offload
(NETIF_F_HW_VLAN_CTAG_FILTER) does it work better if you turn it off?

- does it help if you go back to a kernel before and not including v5.1
which does not have commit 061f6a505ac33659eab007731c0f6374df39ab55
("net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation") or if you
can change your kernel, try something similar to [2] for mv88e6xxx and
see if it helps

[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9bf96943b408e6c99dd13fb01cb907335787c61

Regarding the programing of MAC addresses happening through
ndo_set_rx_mode(), we should program static unicast and multicast
addresses when dev_{mc,uc}_sync() gets called similar to [3] because
those addresses are static in nature and the host stack can add/remove
them accordingly. This would help with aging as much as unknown/known
multicast traffic. I will try to cook something later this week.

[3]:
https://github.com/ffainelli/linux/commit/f91b53449e0346a8d7157e5a9225faaa810cbeab
--
Florian