On Mon, Jun 10, 2019 at 09:24:26AM +0200, Sven Eckelmann wrote:
On Monday, 10 June 2019 02:45:34 CEST Linus Lüssing wrote:
@@ -107,12 +107,20 @@ enum batadv_icmp_packettype {
- @BATADV_MCAST_WANT_ALL_UNSNOOPABLES: we want all packets destined for
- 224.0.0.0/24 or ff02::1
- @BATADV_MCAST_WANT_ALL_IPV4: we want all IPv4 multicast packets
- (both link-local and routeable ones)
- @BATADV_MCAST_WANT_ALL_IPV6: we want all IPv6 multicast packets
- (both link-local and routable ones)
- @BATADV_MCAST_WANT_NO_RTR4: we have no IPv4 multicast router and therefore
- only need routeable IPv4 multicast packets we signed up for explicitly
- @BATADV_MCAST_WANT_NO_RTR6: we have no IPv6 multicast router and therefore
*/
- only need routeable IPv6 multicast packets we signed up for explicitly
enum batadv_mcast_flags { BATADV_MCAST_WANT_ALL_UNSNOOPABLES = 1UL << 0, BATADV_MCAST_WANT_ALL_IPV4 = 1UL << 1, BATADV_MCAST_WANT_ALL_IPV6 = 1UL << 2,
BATADV_MCAST_WANT_NO_RTR4 = 1UL << 3,BATADV_MCAST_WANT_NO_RTR6 = 1UL << 4,};
I wonder what a good interpretation of 0x1f would be (all bits set). The code doesn't seem to be able to handle this but an interpretation would be:
- get all unsnoopable
- get all link-local but not rtr
Good question. Currently code-wise it's neither of those and the BATADV_MCAST_WANT_ALL_IPV{4,6} is authoritative. So if those are set then you'd get all IPv4/IPv6 multicast traffic regardless of the other flags.
- get all unsnoopable
That one does not make so much sense to me. That should be covered by only setting BATADV_MCAST_WANT_ALL_UNSNOOPABLES and would currently contradict the purpose of BATADV_MCAST_WANT_ALL_IPV{4,6}, wouldn't it?
- get all link-local but not rtr
That could be another way to interpret it. It's an option we currently do not have, the option to receive all IPv6 link-local but not routeable IPv6 multicast traffic.
I'm currently unsure when we would need that. Are you suggesting to interpret it that way, just in case we might need it some day?
Note that this would also be a "soft compatibility break". So old nodes would still interpret 0x1f the same way as 0x07, meaning they would send all multicast traffic to nodes announcing either 0x1f or 0x07. It'd be a "soft break" because it wouldn't cause packet loss, old nodes would just overestimate.