GNOME Bugzilla – Bug 687090
IPv6 <-> IPv4 mismatch when subscribing to multicast (send)
Last modified: 2015-02-24 13:12:42 UTC
This bug has IMO more to do with GLib, but since it is triggered in GStreamer, I'm entering it here for tracking. I'll enter one for GLib too. I'm running GNU/Debian wheezy/sid. Debian is running in IPv6 completely; while providing compatibility with an IPv4 network. As such, the sockets that get created are IPv6 by default. Since the move to GSocket in GStreamer in 1.0; a mismatch is triggered in the GSocket and GInetAddress classes and an assertion creates a block. A (workaround) is to force creation of IPv4 sockets; but this is not really an option since it forces IPv4 on the higher application levels. [marc@eee1215n ~]$ GST_DEBUG=*udpsink*:5 gst-launch-1.0 fakesrc ! udpsink host=239.1.2.3 port=1234 0:00:00.107637954 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1002:gst_multiudpsink_add_internal:<GstUDPSink@0x1b2c880> adding client on host localhost, port 5004 0:00:00.109436578 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:404:create_client:<GstUDPSink@0x1b2c880> IP address for host localhost is 127.0.0.1 0:00:00.109549442 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1026:gst_multiudpsink_add_internal:<GstUDPSink@0x1b2c880> add client with host localhost, port 5004 0:00:00.109592184 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1036:gst_multiudpsink_add_internal:<GstUDPSink@0x1b2c880> added client on host localhost, port 5004 0:00:00.109697296 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1076:gst_multiudpsink_remove:<udpsink0> found 1 clients with host localhost, port 5004 0:00:00.109738292 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1083:gst_multiudpsink_remove:<udpsink0> remove client with host localhost, port 5004 0:00:00.109786832 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1002:gst_multiudpsink_add_internal:<udpsink0> adding client on host 239.1.2.3, port 5004 0:00:00.109857931 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:404:create_client:<udpsink0> IP address for host 239.1.2.3 is 239.1.2.3 0:00:00.109926375 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1026:gst_multiudpsink_add_internal:<udpsink0> add client with host 239.1.2.3, port 5004 0:00:00.109964788 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1036:gst_multiudpsink_add_internal:<udpsink0> added client on host 239.1.2.3, port 5004 0:00:00.110023804 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1076:gst_multiudpsink_remove:<udpsink0> found 1 clients with host 239.1.2.3, port 5004 0:00:00.110060401 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1083:gst_multiudpsink_remove:<udpsink0> remove client with host 239.1.2.3, port 5004 0:00:00.110105937 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1002:gst_multiudpsink_add_internal:<udpsink0> adding client on host 239.1.2.3, port 1234 0:00:00.110169074 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:404:create_client:<udpsink0> IP address for host 239.1.2.3 is 239.1.2.3 0:00:00.110235353 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1026:gst_multiudpsink_add_internal:<udpsink0> add client with host 239.1.2.3, port 1234 0:00:00.110388306 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:1036:gst_multiudpsink_add_internal:<udpsink0> added client on host 239.1.2.3, port 1234 Setting pipeline to PAUSED ... 0:00:00.111204262 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:878:gst_multiudpsink_start:<udpsink0> Initialising the sockets 0:00:00.111248821 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:880:gst_multiudpsink_start:<udpsink0> creating sockets 0:00:00.111325995 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:881:gst_multiudpsink_start:<udpsink0> creating IPV6 sockets 0:00:00.111687564 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:892:gst_multiudpsink_start:<udpsink0> have socket 0x1b348f0 0:00:00.111734218 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:931:gst_multiudpsink_start:<udpsink0> have udp buffer of 212992 bytes 0:00:00.111780942 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:823:gst_multiudpsink_configure_client:<udpsink0> configuring client 0x1b16b00 0:00:00.111816072 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:826:gst_multiudpsink_configure_client:<udpsink0> we have a multicast client 0x1b16b00 0:00:00.111854694 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:829:gst_multiudpsink_configure_client:<udpsink0> autojoining group 239.1.2.3 0:00:00.111886961 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:831:gst_multiudpsink_configure_client:<udpsink0> used_socket 0x1b348f0 0:00:00.111919227 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:832:gst_multiudpsink_configure_client:<udpsink0> multi_iface (nil) 0:00:00.112040961 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:833:gst_multiudpsink_configure_client:<udpsink0> g_inet_address_get_family 2 0:00:00.112075672 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:834:gst_multiudpsink_configure_client:<udpsink0> g_socket_get_family 10 0:00:00.112108428 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:835:gst_multiudpsink_configure_client:<udpsink0> G_SOCKET_FAMILY_INVALID 0 0:00:00.112140834 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:836:gst_multiudpsink_configure_client:<udpsink0> G_SOCKET_FAMILY_UNIX 1 = GLIB_SYSDEF_AF_UNIX 1 0:00:00.112174009 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:837:gst_multiudpsink_configure_client:<udpsink0> G_SOCKET_FAMILY_IPV4 2 = GLIB_SYSDEF_AF_INET 2 0:00:00.112206974 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:838:gst_multiudpsink_configure_client:<udpsink0> G_SOCKET_FAMILY_IPV6 10 = GLIB_SYSDEF_AF_INET6 10 (gst-launch-1.0:26827): GLib-GIO-CRITICAL **: g_socket_multicast_group_operation: assertion `g_inet_address_get_family (group) == socket->priv->family' failed 0:00:00.112532296 26827 0x1b15750 WARN multiudpsink gstmultiudpsink.c:860:gst_multiudpsink_configure_client:<udpsink0> error: Could not join multicast group: unknown reason 0:00:00.112742588 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:952:gst_multiudpsink_start:<udpsink0> final have socket 0x1b348f0 0:00:00.135410647 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:775:gst_multiudpsink_get_property:<udpsink0> Get used-socket 0x1b348f0 Pipeline is PREROLLING ... 0:00:00.138430936 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:775:gst_multiudpsink_get_property:<udpsink0> Get used-socket 0x1b348f0 ERROR: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Could not get/set settings from/on resource. Additional debug info: gstmultiudpsink.c(860): gst_multiudpsink_configure_client (): /GstPipeline:pipeline0/GstUDPSink:udpsink0: Could not join multicast group: unknown reason ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... 0:00:00.160181487 26827 0x1b34940 DEBUG multiudpsink gstmultiudpsink.c:775:gst_multiudpsink_get_property:<udpsink0> Get used-socket 0x1b348f0 0:00:00.162071465 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:775:gst_multiudpsink_get_property:<udpsink0> Get used-socket 0x1b348f0 0:00:00.163044565 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:983:gst_multiudpsink_stop:<udpsink0> Setting socket back to 0 Freeing pipeline ... 0:00:00.163726147 26827 0x1b15750 DEBUG multiudpsink gstmultiudpsink.c:460:gst_multiudpsink_finalize:<udpsink0> Setting socket back to 0
Same for ArchLinux on Git
Created attachment 227515 [details] [review] ups IPv4 socket handling when MC is IPv6
I submitted the patch on GLib https://bugzilla.gnome.org/show_bug.cgi?id=687092 I am just adding it here for review purposes.
So gst_multiudpsink_start() appears to always try to create an IPv6 socket, and then expects IPv4-mapping magic to happen if it tries to connect to an IPv4 address on it. Note that this essentially makes the code Linux-specific, since the IPv4-mapping magic is turned off by default on most other OSes (and doesn't exist at all on OpenBSD).
Created attachment 227540 [details] [review] check the destination and set force ipv4 if dest is ipv4 This is an alternative for implementing a catch of the errors in GSocket when setting the options
Created attachment 227541 [details] [review] Verbose socket creation
btw, Verified that the ttl-mc is no longer being set.
(In reply to comment #7) > btw, Verified that the ttl-mc is no longer being set. Can you clarify that? Is that with your first (glib) patch or with your second (gstreamer) patch? If ttl and other properties are being correctly set with the gstreamer patch here, then I think you should commit it, since it seems generally correct (and more cross-platform compatible than the current code).
With the GLib patch, ttl and ttl-mc are not set correctly. The GStreamer patch seems to behave correctly. There has been a suggestion to duplcate all the internal socket work in GStreamer to both IPv4 and IPv6; but I am not really in favour of that since it would break the existing API and it has repercussions throughout the code base. I think the current two GStreamer patches are relatively isolated and correct the input towards GLib. The alternative is to provide the cascade (try6-catch-try4) everywhere in the GLib code base.
I think this is fixed in git master now, separate sockets are used for v4 and v6. Is there still a problem?
Marc?
I must have missed the question, I removed the force-ipv4 in our code since some time and all seems to be fine at the moment.
Ok, so I take it the separate sockets for IPv4 and IPv6 work then. Thanks for confirming.