GNOME Bugzilla – Bug 588245
TTL is never applied with udpsink/udpmultisink
Last modified: 2012-07-02 11:57:07 UTC
the "ttl" parameter of the udpsink and udpmultisink elements is never applied on the socket, and always have the same value: - 64 when the host parameter is an unicast address - 1 when the host parameter is a multicast address -----Examples-- --> The GST pipeline sending an unicast udp stream with TTL=100 # gst-launch videotestsrc ! x264enc bitrate=200 ! rtph264pay ! udpsink host=192.168.1.1 port=10101 ttl=100 --> The TCPDUMP capture showing packets with TTL=64 08:18:43.059112 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 947) 192.168.1.2.53651 > 192.168.1.1.10101: UDP, length 919 ----- --> The GST pipeline sending a multicast udp stream with TTL=100 # gst-launch videotestsrc ! x264enc bitrate=200 ! rtph264pay ! udpsink host=225.0.0.1 port=10101 auto-multicast=true ttl=100 --> The TCPDUMP capture showing multicast packets with TTL=1 08:20:37.919368 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 935) 192.168.1.2.53644 > 225.0.0.1.10101: UDP, length 907
for me it allocates an IPV6 socket and then whatever values I pass to setsockopt, the TTL remains unmodified. Don't know what to do, I even tried setting both the IP4 and IP6 options on the socket at the same time.
Multiple issues are contributing for this behavior with the given pipelines: a) TTL is always set with either IP_MULTICAST_TTL (IPV4) or IPV6_MULTICAST_HOPS (IPV6) optval. For unicast address, it should be IP_TTL or IPV6_UNICAST_HOPS. In udpmultisink.c, function gst_multiudpsink_add_internal() has a check for the address type, but I haven't found yet any way to actually enter that particular check. Thus, it sets TTL with wrong optval in case of unicast addresses. Interestingly, setsockopt() still returns success and getsockopt() returns the newly set value, but tcpdump shows that TTL is the recommended default value set by the TCP/IP stack implementation (IIRC, 64 for unicast and 1 for multicast). b) By default, IPV6 sockets are used when available. When sending to IPV4 address, setting of TTL seems to work correctly only when both IP4 and IP6 options are set on the socket at the same time. In contrast to Wim's test (comment #1), I was able to change the actual TTL value for multicast addresses. For unicast address, it will not have any effect (64 will be used). c) Finally, setting TTL for multicast address (224.0.0.0 - 239.255.255.255) when using IPV4 sockets works as expected. However, this cannot be tested unless commenting out the code which tries allocating IPV6 socket first: if ((sink->sock = socket (AF_INET6, SOCK_DGRAM, 0)) == -1)
There's a related bug 573115 which points out commit: e206f74bcea198673e6e64f04218d7c72a56efcd (gst/udp/: Joining a multicast group and setting the loop/ttl properties are totally unrelated tasks are must be separ...) Obviously there's more to fix than just the TTL. I will see what can be done and make a patch if things go well.
Created attachment 141736 [details] [review] Patch to set TTL correctly for unicast and multicast addresses
Created attachment 141754 [details] [review] Incremental patch to separate unicast and multicast TTLs This also fixes the issue described in bug 573115 comment 4. This patch should be posted on that report, but since it's an incremental patch and related to this bug, we could just mark the other one resolved, if this fix is accepted. This patch adds a new property 'ttl-mc' to the element. I don't consider that any existing code using udpsink would experience significant breaking since the TTL was never applied and networking stack used the same default values as this patch is using. So, in order to apply multicast TTL, you need to set 'ttl-mc' property. 'ttl' still applies for unicast addresses. The patch also add the copyright lines which I forgot in the first one.
commit 1f14f577d873711e3f4b026f1ab709af69883684 Author: Jarkko Palviainen <jarkko.palviainen at sesca.com> Date: Mon Aug 31 12:16:01 2009 +0200 udpsink: Add ttl multicast property Add a new ttl-mc property to control the TTL on multicast addresses. Fixes #588245 commit e2518fedbe8f6eb9cf1cf456381a5e350e2c4001 Author: Jarkko Palviainen <jarkko.palviainen at sesca.com> Date: Mon Aug 31 12:13:07 2009 +0200 udp: split out TTL and loop options Split setting the TTL and loop parameters in 2 methods as they are not related. Fix setting the TTL correctly for multicast streams. See #588245
*** Bug 573115 has been marked as a duplicate of this bug. ***
This patches doesn't seem to work on windows, see #604870
Doesn't seem to work on macosx either.
Should be fixed now in git master (0.11/1.0), from the looks of it: http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/udp/gstmultiudpsink.c#n753 Please re-open if this is still an issue in git maste.r