netdev - Re: mv88e6320: Failed to forward PTP multicast

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87sfbuprdf.fsf@waldekranz.com>
Date: Wed, 17 May 2023 23:42:04 +0200
From: Tobias Waldekranz <tobias@...dekranz.com>
To: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>
Cc: Fabio Estevam <festevam@...il.com>, Florian Fainelli
 <f.fainelli@...il.com>, Steffen Bätz
 <steffen@...osonix.de>, netdev
 <netdev@...r.kernel.org>
Subject: Re: mv88e6320: Failed to forward PTP multicast

On ons, maj 17, 2023 at 19:07, Andrew Lunn <andrew@...n.ch> wrote:
>> Slightly unrelated to the original topic and probably completely
>> unrelated to Fabio's actual issue.
>> 
>> I'm completely inapt when it comes to IP multicast. Tobias, does the
>> fact that br0 have mcast_router 1 mean that the CPU port should be a
>> recipient of all multicast traffic, registered or unregistered?

If the bridge is the elected querier, then yes, br0 should receive _all_
IP multicast.  However, I believe that mcast_router=1 only means that
the bridge is allowed to take part in the election, if you have another
querier/router somewhere on the LAN, then that might be elected.

Assuming that br0 is the elected querier, Fabio is probably hitting a
long-standing issue with the MDB-implementation in the DSA/mv88e6xxx
layers.  Typically, drivers will ensure that router ports (and host
mrouter) receive _unknown_ multicast.  However, existing _registered_
groups still won't reach these ports.

In all hardware that I've seen, this must be handled by iterating over
all known (IP) groups in the MDB, ORing in the new router port (which
could be the CPU port in the host mrouter case).  Conversely, when new
groups are registered, you must also make sure to OR in all existing
router ports.

Deletions are even more perilous, because now each bit in a hardware MDB
(ATU) entry might have been set for either one or both of two reasons:

1. Because an IGMP/MLD report or a static configuration said so.
2. Because a router/querier is located behind it.

This means that you need to cache all this information in software to
know when it is safe to clear a bit in the hardware.

I have made a draft implementation of this, which I do not have access
to at the moment.  I'll poke around and see if I can find it.

> It is a long time since i did much with multicast. But my
> understanding is that a multicast router should be taking part in
> IGMP. If there is a group member on the other side of the gateway, the
> router should indicate it has interest in the group so traffic flows
> to it. It can then forward the traffic between its multicast
> interfaces, based on that interest.

Yes, that would have been the sane thing to do.  Indeed, if you're
running a protocol like PIM-SM, it could have been done that way.  Alas,
we also have flood-and-prune based protocols like DVMRP to deal with,
where the router has to flood all groups to all other routers until it
receives a prune message.  This is why, AFAIK, the standard says that a
router port needs to also receive unregistered groups.