netdev - Re: Question: DSA on Marvell 6390R switch dropping EAPOL packets with unicast MAC DA

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230309110639.lvbhzexnim7vrkwx@skbuf>
Date:   Thu, 9 Mar 2023 13:06:39 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Qingtao Cao <qingtao.cao.au@...il.com>
Cc:     andrew@...n.ch, vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: Question: DSA on Marvell 6390R switch dropping EAPOL packets
 with unicast MAC DA

Hi Harry,

On Thu, Mar 09, 2023 at 08:19:27PM +1000, Qingtao Cao wrote:
> In this success case, there are two major differences from the Setup One:
> 1. The MAC DA in the EAPOL packet of Request Identity, the 2nd packet in
> the above example, was the multicast address 0180 c200 0003.I guess this is
> understandable since the hostapd has no port-level authentication so it has
> to use a multicast address to reach the potential supplicant.
> 2. The DSA tag = "0108 efff", specifically, the mode = 0, or *TO_CPU*.

> So, how to make the EAPOL a success in the Setup One when the MAC DA is a
> unicast address instead of a multicast address?

My summary of your issue description is: when wpa_supplicant on your DSA
box receives packets with the MAC DA of the PAE group address (01:80:c2:00:00:03),
it can process them. When it receives packets with the MAC DA equal to
the port's unicast MAC address, it can't.

How have you determined that this is a problem with the kernel?

In the title, you claim "switch dropping packets", but there is no
evidence backing this claim in the email body. Furthermore, we do see
those packets in tcpdump. To drop a packet would mean that some drop
counter increases, either on the DSA switch interface
(ethtool -S net2p9 | grep -v ': 0'), or on the DSA master
(ethtool -S eth2cpu | grep -v ': 0'). Note that on the DSA master, DSA
also appends the port counters of the switch's CPU port.

I am also curious to see drop counters when tcpdump is active, and when
it isn't active. This is because tcpdump puts the interface in
promiscuous mode (accept packets with any MAC DA), so there may be a
problem there as well. The command "ip link set eth2cpu promisc on" may
also help to diagnose whether it is a filtering problem on the DSA master.

I have not used wpa_supplicant, but I guess it might be possible that
the application is simply written to bind() the socket() only to the PAE
group address (01:80:c2:00:00:03). Otherwise said, the kernel doesn't
drop the unicast packets, but the application is written such that it
doesn't process them. This is just speculation. Apart from inspecting
the hostapd source code (which I haven't done), "strace" could also be
used to determine this.

If no ethtool counters increment, there is no reason to suspect a
hardware drop of your packets. In that case, the kernel network stack
could still drop them somewhere. This set of commands run on the DSA box
might help identify where:

CONFIG_NET_DROP_MONITOR=y
sudo apt install libpcap-dev binutils-dev libtool
git clone https://github.com/nhorman/dropwatch.git
cd dropwatch
./autogen.sh
dropwatch -l kas

I have no reason to suspect at the moment that any change to net/dsa/tag_dsa.c
would be needed. Until proven otherwise, the difference between FORWARD
and TO_CPU DSA headers is a red herring IMO.

Hope this helps.