After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 696057 - udpsink does not work with IPv4 addresses on MacOSX
udpsink does not work with IPv4 addresses on MacOSX
Status: RESOLVED DUPLICATE of bug 534243
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.x
Other Mac OS
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-03-18 14:11 UTC by Jack Jansen
Modified: 2013-04-25 10:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jack Jansen 2013-03-18 14:11:49 UTC
udpsink does not work with IPv4 destination addresses on MacOSX. Tried on both 10.7 and 10.8. All systems were multihomed and IPv6 configured to "automatic", in case that matters.

The easiest way to see the problem is as follows:
   $ gst-launch-1.0 -v audiotestsrc  ! mulawenc ! rtppcmupay  ! udpsink host="localhost" port="13002"
works fine.
   $ gst-launch-1.0 -v audiotestsrc  ! mulawenc ! rtppcmupay  ! udpsink host="127.0.0.1" port="13002"
fails, with errors
   WARNING: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Error sending UDP packet
   Additional debug info:
   gstmultiudpsink.c(545): gst_multiudpsink_render (): /GstPipeline:pipeline0/GstUDPSink:udpsink0:
   Reason: Error sending message: Invalid argument

The problem turns out to be (after an incredible amount of debugging:-) that gstmultiudpsink opens an IPv6 socket, and then does a sendmsg() to an IPv4 address.

Apparently this works on Linux, but not on BSD systems, see for example <http://stackoverflow.com/questions/8087478/using-sendto-on-a-ipv6-socket-to-send-to-a-ipv4-address>.

The workaround is to use force-ipv4=true on udpsink, obviously. However, I think that at the very least a better error message would be in place. Even better would be converting the IPv4 address to its ::ffff: form.
Comment 1 Sebastian Dröge (slomo) 2013-03-25 09:25:20 UTC
It should use two separate sockets, one for only IPv4 and one for only IPv6. This would also fix it on systems that don't allow both protocols to be used with the same socket.
Comment 2 Sebastian Dröge (slomo) 2013-04-25 10:30:04 UTC
Thanks for taking the time to report this bug.
This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade.

*** This bug has been marked as a duplicate of bug 534243 ***