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

[Vladimir Oltean <olteanv@gmail.com>]

Hi Harry

On Fri, Mar 10, 2023 at 08:34:12AM +1000, Qingtao Cao wrote:
> Hi Vladimir,
> 
> Yes, yes, yes!

Please resolve your problems with top-posting style and plain text
emails pointed out earlier. This reply did not make it to the mailing
list either, AFAICS.

> 
> The net2p9 along with all other ports are under a bridge (eth2) on my box,
> which is setup by a script using ip and brctl command after reboot.
> 
> My box previously supports a kernel configuration without any DSA driver
> enabled, so all those marvell 6390r switches work as a "dumb" one: their
> backend is the intel i210 and switch ports just act as its PHYs, so they
> are used as a normal home network switch.
> 
> Whereas the new configuration enables kernel DSA and driver, the physical
> interface eth2 was renamed to eth2cpu and a bridge interface named eth2 was

it's slightly unconventional to name a bridge interface "eth2", but okay...

> created to enslave all switch ports. From brctl showstp command, I could
> see the net2p9 had entered all the way to the forwarding state when I
> kicked off the wpa_supplicant on it.

the modern command for that would be "bridge link", but okay

> 
> Of course, I would try the ebtables command first things first in the
> morning today!
> 
> If it works, then I would have more questions, such as:
> 1. is the bridge layer RX handler involved just because net2p9 is enslaved
> to a bridge? (although wpa_supplicant was not operating on the bridge
> interface)

yes

> 2. if yes, then running wpa_supplicant against the net2p9 before creation
> of the bridge, would this prevent the bridge RX handler from stealing the
> packet?

yes

> 3. if still yes, then perhaps I could run the wpa_supplicant before setting
> up the bridge, so that the d-link switch port could still be authorized and
> all the rest DSA switch ports could still share the same uplink via net2p9

that's a question for you to answer

doesn't the port need reauthorization from time to time? if it does, do
you plan to temporarily remove it from the bridge and add it back?

> 4. if yes again, would the bridge RX handler steal other protocols than
> EAPOL?

the source code of br_handle_frame() that it steals *all* packets except
for a select few, namely packets sent to the reserved link-local multicast
range (01-80-c2-00-00-xx).

> how would we come up with a more generalized solution to prevent
> this from happening?

You'd need to talk to the bridge maintainers about this. Currently,
stealing is avoided for frames for which the frame_handler() of their
protocol added via br_add_frame() (currently MRP and CFM) returns an
error. I suppose this mechanism could be extended/abused to add new
protocols which the bridge should always know it should never steal:
their frame_handler() identifies them and returns an error.

However the list is bound to get quite large (PTP over IP needs this too)
https://lore.kernel.org/netdev/871r3gbdxv.fsf@kurt/
and not all bridge users need all rules, but if the rules get built-in,
then all users need to suffer the performance penalty associated with
the frame_type lookups. So I guess this is why we have the netfilter
based system. I would expect some pushback from bridge maintainers, but
I guess it's worth a shot.

> 
> BTW, running wpa_supplicant on the bridge interface doesn't work, just
> because of EAPOL Start packet with that multicast address as MAC DA will be
> dropped by the bridge since STP has been enabled on it.

I didn't suggest that you run wpa_supplicant on the bridge interface.
I wasn't expecting it to work.