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 595840 - setting udpsink's host property to "localhost" on ubuntu 9.04 (jaunty) does not work
setting udpsink's host property to "localhost" on ubuntu 9.04 (jaunty) does n...
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-09-21 15:20 UTC by Tristan Matthews
Modified: 2011-05-23 12:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch that sets default for "host" to 127.0.0.1 instead of localhost (366 bytes, patch)
2009-09-21 15:20 UTC, Tristan Matthews
none Details | Review
diff between server-VTS-H263p-ATS-PCMA.sh in release and version with hostnames set as 127.0.0.1 (872 bytes, text/plain)
2009-09-30 17:31 UTC, Tristan Matthews
  Details

Description Tristan Matthews 2009-09-21 15:20:14 UTC
Created attachment 143612 [details] [review]
patch that sets default for "host" to 127.0.0.1 instead of localhost

udpsink's behaviour differs between ubuntu 8.04 and 9.04 for the host property.
The default, "localhost" does not work as expected, i.e. rtp pipelines never
start streaming. Replacing it with 127.0.0.1 solves the issue.
Comment 1 Sebastian Dröge (slomo) 2009-09-22 06:23:24 UTC
The problem from the Ubuntu update is, that localhost now points to an IPv6 address (IIRC). So I'd say the current code is fine (udpsink handles IPv4 and IPv6) and your setup is broken in some way (or you connect to the IPv4 address although it listens to the IPv6 address).

Not sure if it makes sense to always point udpsink to an IPv4 localhost address...
Comment 2 Tristan Matthews 2009-09-23 17:54:08 UTC
You're right, it doesn't make sense to have it default to 127.0.0.1.

But do you have access to a jaunty install? Are you able to run

gst-plugins-good-0.10.16/tests/examples/rtp/server-VTS-H263p-ATS-PCMA.sh
and 
gst-plugins-good-0.10.16/tests/examples/rtp/client-H263p-PCMA.sh

on the same machine without setting the host property in the udpsinks to 127.0.0.1 (rather than the default of localhost)? I've tried this on my home machine and several work machines, and while the scripts are fine in hardy they fail in jaunty.
Comment 3 Sebastian Dröge (slomo) 2009-09-30 16:49:24 UTC
My /etc/hosts contains this:

127.0.0.1	localhost
::1     localhost ip6-localhost ip6-loopback

With this (or the other way around) the samples work just fine. Could you check which IP addresses are used in the examples?
Comment 4 Tristan Matthews 2009-09-30 17:31:15 UTC
Created attachment 144417 [details]
diff between server-VTS-H263p-ATS-PCMA.sh in release and version with hostnames set as 127.0.0.1
Comment 5 Tristan Matthews 2009-09-30 17:40:41 UTC
My /etc/hosts is:
127.0.0.1       localhost
127.0.1.1       posture02

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

The example's server-VTS-H263p-ATS-PCMA.sh uses localhost, the default, since no host property is explicitly specified. Video playback in client-H263p-PCMA.sh doesn't work until i explicitly set host=127.0.0.1 in the server.

Here's a diff of the shellscript from the last releast of plugins-good vs. my "fixed" version, let me know if you need more info, this is a very mysterious bug :(
Comment 6 Sebastian Dröge (slomo) 2009-10-02 13:00:25 UTC
Does it work with ::1 as host too? If not your system has a configuration problem
Comment 7 Tristan Matthews 2009-10-05 00:56:13 UTC
no it only works with 127.0.0.1. However, the commands
ping 127.0.0.1
ping localhost
ping6 ::1

all behave normally, and my network/install both at work and at home are pretty vanilla, but both (for Ubuntu 9.04 anyway) have this problem in gstreamer, whereas this bug doesn't show up in 8.04. Is there some issue with UDP in IPV6 that I'm missing?
Comment 8 Tristan Matthews 2009-10-05 01:43:19 UTC
I can also see when running iptraf with detailed interface statistics for the lo interface that no udp traffic is happening (i.e. outgoing rate is 0) when host is set to ::1 or localhost, but it goes up when it's set to 127.0.0.1
Comment 9 Tobias Mueller 2010-04-22 13:00:58 UTC
Reopening as the requested information has been provided, I guess.
Comment 10 Tristan Matthews 2010-04-22 14:12:53 UTC
This is also true for Ubuntu 9.10 (karmic)
Comment 11 Tristan Matthews 2011-03-25 20:05:32 UTC
To summarize, udpsink's "host" property defaults to localhost, which on Ubuntu 9.04 and later resolves to an IPv6 address first by default (note that gst_udp_get_addr in gstudpnetutils.c returns the first IPv4 OR IPv6 address that it finds for a given hostname).

udpsrc meanwhile has a default "multicast-group" property of "0.0.0.0", which is IPv4.

Therefore, on Ubuntu, udpsink will default to localhost over IPv6 and udpsrc will default to IPv4, meaning that running the server and client examples in gst-plugins-good, or doing any loopback tests with the defaults (i.e. not forcing either IPv4 or IPv6 addresses) will quietly fail. I'm not sure if there's a reasonable compromise for this, the workarounds being:

a)set host=127.0.0.1 on the udpsinks

OR

b)set host=localhost.localdomain on the udpsinks

OR

c)set multicast-group=:: on the udpsrcs


Here's my current /etc/hosts file:

10.10.10.203    tchip   # Added by NetworkManager
127.0.0.1       localhost.localdomain   localhost
::1     tchip   localhost6.localdomain6 localhost6
127.0.1.1       tchip

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
Comment 12 Sebastian Dröge (slomo) 2011-05-23 12:50:28 UTC
I don't think this is possible to fix in a way that works in all cases without manually setting properties. It's not optimal though...

If you have any ideas how it could be fixed properly, feel free to reopen this bug.