ethernet: Missing multicast addr assignment

[JannesVolkens]

Description

PR #13383 fixed the unicast filtering for stm32, but at the same time blocked the filtering of multicast addresses. However, since NDP maps to a multicast address, the neighbor table remained empty, which prevented the sending of IPv6 packets.
PR #13487 then fixed this issue by reactivating the passing of all frames with a multicast address.

So far, an adequate multicast address assignment is missing in RIOT so that the stm32 has to filter for every frame containing a multicast address.

Useful links

None.

[kfessel]

Here is a list of Protocolls using Ethernet Group-Messages (Multicast)

https://en.wikipedia.org/wiki/Multicast_address#Ethernet

[PeterKietzmann]

I've changed the title because this is a general question to all Ethernet interfaces aka driver implementations. How do we deal with multicast address assignment? Most devices seem to have more or less advanced filter rules but if I see it correctly, we rely on always receiving all multicast traffic (e.g. triggered from ICMPv6 control traffic) on a node. This is inefficient. Do have have a convention for that, a piece of documentation or has Ethernet multicast address assignment just not been looked at?

[kfessel]

this may seem inefficient but it is not less efficient than dealing with the same but in Braodcasts (which afaik IPv4 ARP does)

[miri64]

See #15287 for a provided framework within GNRC (there is no device support in that PR however, that I leave to people who like to read data sheets ;-))

[miri64]

#15287 did not fix the issue. There is still driver support required for that.