[FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection

[Ignjatović, Lazar (RS)]

>> I've compared ffmpeg 5.1.2 against my MR on IPv6 multicast. Here are
>> the
>> results:
>
> I don't care. That does not make your MR any less counter-sensical.

If I may cite Marton Balint
```
d3bda871f033be4825ecb69d444b3396bf2a2eb7
avformat/udp: specify the local address for some source filtered multicast joins

We already use localaddr for the multicast joins without source filters, so we
should use them for source filters as well. This patch only fixes the
IP_ADD_SOURCE_MEMBERSHIP and the IP_BLOCK_SOURCE case.

Unless we do this, the kernel automatically selects an interface based on the
source address, and that interface might be different from the one set in
localaddr. For blocked sources this even casues EINVAL because we joined the
multicast group on a different interface.

Signed-off-by: Marton Balint <cus at passwd.hu>
---
 ...
//TODO: Interface index should be looked up from local_addr
...
```

And another commit
```
ab0812c1a8925a95315354b88b41256faad5faa8
avformat/udp: always use IP_ADD_SOURCE_MEMBERSHIP for subscribing to an UDP multicast source group in IPv4

That alone supports specifying the interface based on its address. Getting the
interface index from the local address seems quite a bit of work in a platform
independent way...

Obviously for IPv6 we still always use MCAST_JOIN_SOURCE_GROUP.

As a side effect this also fixes ticket #7459.

Signed-off-by: Marton Balint <cus at passwd.hu>
```

From this I understand that the intention is to still use localaddr parameter
with the same semantics as with IPv4

> If you could infer the scope ID from the IPv6 address, there wouldn't be a
> scope ID field in the socket address in the first place. Is it that hard to
> understand?

Well, it's not that simple. Here I have to cite ipv6(7) — Linux manual page
```
       sin6_scope_id
       is an ID depending on the scope of the address.  It is new in
       Linux 2.4.  Linux supports it only for link-local addresses, in
       that case sin6_scope_id contains the interface index (see
       netdevice(7))
```

> That "problem" was solved before FFmpeg existed by adding a separate parameter
> (ping6) or prepending the interface name after a percent sign (glibc).

And this is the closest you've got to providing an alternate solution to the proposed.
Which is adding another parameter, or relying on % for every type of multicast.

> If you tests show anything, it's that LL addressing is not intended for application protocols.

And just to clarify
FF11::1%eth0 is an interface-local multicast, thus supported
FF12::1%eth0 is a link-local multicast, thus supported

All other multicast scopes are not supported by Linux in respect to %scope.

If we choose to support ff15::1%eth0 for example, we are introducing something that
is not normally supported on Linux, potentially creating confusion among users.
Interface parameter seems like a better option than the %scope for everything.

Can someone else agree with this?

If this is, in fact, the preferred way, then okay. I will propose the v3 of the patch
done this way. Still, I prefer keeping the IPv4 semantics for v6.

Lazar Ignjatović
Associate Software Engineer

Cubic Defense
cubic.com

This message has been marked as Public on 03/22/2024 09:31Z.