GNOME Bugzilla – Bug 764679
IPv6 UDP stream to site-local multicast address
Last modified: 2016-05-04 07:22:29 UTC
While trying to switch from gstreamer 0.10 to an 1.x version I noticed that the UDP stream that I'm trying to receive no longer works. The stream is sent to the IPv6 all-nodes local multicast address (ff02::1) which seems to be a problem for gstreamer 1.x. The old pipeline starts with "gst-launch-0.10 udpsrc port=4001 multicast-group=ff02::1%eth0 caps="${CAPS}" ! [..]". Trying a similar thing with 1.x fails with an error message: $ gst-launch-1.0 udpsrc port=4001 multicast-group=ff02::1%eth0 caps="${CAPS}" ! fakesink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: Could not get/set settings from/on resource. Additional debug info: /tmp/portage/media-libs/gst-plugins-good-1.6.3/work/gst-plugins-good-1.6.3/gst/udp/gstudpsrc.c(1119): gst_udpsrc_open (): +/GstPipeline:pipeline0/GstUDPSrc:udpsrc0: bind failed: Error binding to address: Invalid argument Setting pipeline to NULL ... Freeing pipeline ... After asking for advice on the mailing list I was pointed to an #ifdef which modifies the multicast group behaviour: https://lists.freedesktop.org/archives/gstreamer-devel/2016-April/057644.html Removing the "#ifdef G_OS_WIN32" on gstudpsrc.c:953 fixes the issue for me but will, I assume, break things for others.
The main question is if the assumption is correct that a) currently by binding to a multicast address on Linux, we would filter all packets that have a different destination b) when not binding to a multicast address but to ANY, we would receive all packets arriving on that specific port independent of destination In general it is probably better to always bind to ANY (and possibly add a bind-address property) and do the filtering when receiving packets if needed. That is probably needed for meaningful behaviour on Windows anyway.
Created attachment 325700 [details] [review] udpsrc: Always bind to ANY when address is a multicast address and not only on Windows For IPv6 addresses, binding to a multicast group does not work on Linux either. Always bind to ANY and then later join the multicast group.
Created attachment 325701 [details] [review] rtsp-stream: Always bind to ANY when address is a multicast address and not only on Windows For IPv6 addresses, binding to a multicast group does not work on Linux either. Always bind to ANY and then later join the multicast group.
Question is now just how to do the filtering... we only know the source address of packets, not the destinations. And the behaviour change here is now that we receive all packets that arrive on that port, while before we only received packets for the IPv4 multicast group.
Just a note, I'm not sure that this is a general problem with IPv6 multicast on Linux, it could just be an issue with this specific address (ff02::1), an address that a machine does not have to (and probably cannot) explicitly join.
Does it work to join any IPv6 multicast address without the patch? Are there others that don't work? :) What about on e.g. BSD? I think overall we should change something here, to keep the behaviour exactly the same on all OS.
This also causes unit test failures in gst-rtsp-server after fixing some code in there so it actually does test IPv6 multicast, see bug #764744 IMHO we should get this in. For getting the destination address via recvfrom/recvmsg there seems to be no platform independent solution. You can do it on Linux (what about the BSDs?) with IP_PKTINFO. Maybe we can ignore the filtering? :)
Comment on attachment 325700 [details] [review] udpsrc: Always bind to ANY when address is a multicast address and not only on Windows Attachment 325700 [details] pushed as 3b7df52 - udpsrc: Always bind to ANY when address is a multicast address and not only on Windows
Attachment 325701 [details] pushed as aa9a244 - rtsp-stream: Always bind to ANY when address is a multicast address and not only on Windows