[gstreamer-bugs] [Bug 588245] TTL is never applied with udpsink/udpmultisink

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Aug 20 23:25:56 PDT 2009


http://bugzilla.gnome.org/show_bug.cgi?id=588245


Jarkko Palviainen <jarkko.palviainen> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarkko.palviainen at sesca.com


--- Comment #2 from Jarkko Palviainen <jarkko.palviainen at sesca.com> 2009-08-21 06:25:50 UTC ---
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)

-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list