GNOME Bugzilla – Bug 687092
IPv6 <-> IPv4 mismatch when subscribing to multicast (send)
Last modified: 2012-12-17 14:03:09 UTC
Entered in GStreamer, but is caused by GLib. https://bugzilla.gnome.org/show_bug.cgi?id=687090 I am trying to confirm with git atm.
A system built with jhbuild and including a git version of glib has the same issue. libglib-2.0.so.0.3501.0
Created attachment 227514 [details] [review] Use IPv4 socket handling when mc address is IPv4, even on IPv6 socket
> Debian is running in IPv6 completely; while providing compatibility with an > IPv4 network. Can you clarify exactly what you mean by that? How is your networking configured?
As far as I know, a lot of distros are internally running IPv6; so software is mostly creating IPv6 sockets; but the configuration provides compatibility with a classical ipv4 network. As a result the software can completely be written for IPv6; while the lower layers of the OS do the backwards compatibility layer. So, when a socket is created, it is mostly an ipv6 socket on modern distros (tested with Debian, ArchLinux, I assume that Ubuntu is the same). In the case of GLib; an IPv6 socket is also created and used; but when joining a multicast group, there is check if the socket (IPv6) matches the family of the multicast group (IPv4); if this fails; the code exits. The patch here removes this check and will apply the IPv4 logic if either the socket is IPv4 or if the multicast group is IPv4. As a result; the IPv6 socket joins a IPv4 multicast group. eth0 Link encap:Ethernet HWaddr bc:ae:c5:0d:da:d6 inet addr:172.16.10.78 Bcast:172.16.10.255 Mask:255.255.255.0 inet6 addr: fe80::beae:c5ff:fe0d:dad6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5230258 errors:0 dropped:4 overruns:0 frame:0 TX packets:3972303 errors:0 dropped:0 overruns:0 carrier:13 collisions:0 txqueuelen:1000 RX bytes:4544346828 (4.2 GiB) TX bytes:1388919311 (1.2 GiB) Because of this strict checking; GStreamer cannot send out data on a multicast address on any of these OSes.
Comment on attachment 227514 [details] [review] Use IPv4 socket handling when mc address is IPv4, even on IPv6 socket That's not entirely accurate, but, ok, yes, udpsink appears to always create IPv6 sockets and then expect the v4mapping magic to work. >+ if ((socket->priv->family == G_SOCKET_FAMILY_IPV4) >+ || (g_inet_address_get_family (group) == G_SOCKET_FAMILY_IPV4)) Really, we should just base the decision on the address's family, not the socket's, and just return the underlying setsockopt() error if the caller tries to do something that doesn't work. However, there's still another problem, which is that the g_socket_set_multicast_loopback(), g_socket_set_multicast_ttl(), and g_socket_set_ttl() calls will end up setting the IPv6 sockopts, not the IPv4 sockopts, and so won't have any effect on IPv4 multicast. I think. Are you able to test that? If so, there's not really any good fix for this, other than "don't try to do IPv4 multicast on an IPv6 socket"
I'm attaching a patch to catch this on GStreamer level, the alternative would be to catch the error on setsockopts for IPv4 and try again with IPv6.
Created attachment 227538 [details] [review] force ipv4 socket if dest is ipv4
Created attachment 227539 [details] [review] verbose socket creation
(In reply to comment #5) > If so, there's not really any good fix for this, other than "don't try to do > IPv4 multicast on an IPv6 socket" actually, that's not true; we can just always try to set both the IPv6 property and the IPv4 property if we have an IPv6 socket
Created attachment 231388 [details] [review] gsocket: improve sockopt handling for IPv4-wrapped-IPv6 sockets On IPv6 sockets, set both the IPv4 and IPv6 versions of IP socket options, in case the socket is (or might become) IPv4-wrapped. (But ignore errors when setting the IPv4 version.) Similarly, when joining or leaving a multicast group, pick the sockopt to use based on the address family of the multicast address rather than the address family of the socket.
Review of attachment 231388 [details] [review]: Ok, not a networking expert, but this looks reasonable to me.
Attachment 231388 [details] pushed as df334d6 - gsocket: improve sockopt handling for IPv4-wrapped-IPv6 sockets