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 681055 - gupnp-av-cp sends the wrong IP to the MediaRenderer
gupnp-av-cp sends the wrong IP to the MediaRenderer
Status: RESOLVED OBSOLETE
Product: gupnp-tools
Classification: Other
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-08-02 09:47 UTC by Nicholas Miell
Modified: 2021-05-17 17:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Nicholas Miell 2012-08-02 09:47:18 UTC 
If the MediaServer and gupnp-av-cp are running on the same host, the URLs that gupnp-av-cp sends to the MediaRenderer with SetAVTransportURI use 127.0.0.1 instead of the host's IP address.
Comment 1 Zeeshan Ali 2012-08-03 19:33:31 UTC 
Is 127.0.0.1 not the correct IP address on your loopback interface?
Comment 2 Nicholas Miell 2012-08-03 19:46:01 UTC 
The MediaRenderer is a distinct device from the machine running gupnp-av-cp and the MediaServer, so when the MediaRenderer attempts to connect to 127.0.0.1, it connects to itself instead of the MediaServer.
Comment 3 Zeeshan Ali 2012-08-03 19:51:38 UTC 
(In reply to comment #2)
> The MediaRenderer is a distinct device from the machine running gupnp-av-cp and
> the MediaServer, so when the MediaRenderer attempts to connect to 127.0.0.1, it
> connects to itself instead of the MediaServer.

Ah now I get it. Never thought of this scenerio TBH. If MediaServer is Rygel, an easy work around would be to ask it to bind itself to non-loopback network interface.
Comment 4 Nicholas Miell 2012-08-03 19:57:09 UTC 
OK, I'll try that, but shouldn't SSDP or whatever skip 127.0.0.1 when searching the network for UPnP devices?
Comment 5 Zeeshan Ali 2012-08-03 20:08:43 UTC 
(In reply to comment #4)
> OK, I'll try that, but shouldn't SSDP or whatever skip 127.0.0.1 when searching
> the network for UPnP devices?

No, its a perfectly valid usecase to have everything local (e.g for testing/development purposes).
Comment 6 Nicholas Miell 2012-08-03 20:09:40 UTC 
Yeah, but it will still show up on the non-loopback interfaces, won't it?
Comment 7 Zeeshan Ali 2012-08-03 20:16:47 UTC 
(In reply to comment #6)
> Yeah, but it will still show up on the non-loopback interfaces, won't it?

*If* there is a non-loopback interface that is enabled. I take it that you haven't yet had the pleasure of hacking on UPnP during a flight? :)
Comment 8 Zeeshan Ali 2012-08-04 00:39:09 UTC 
Confirming this as this really is an issue. What IMHO should happen is that if we see the same device on both loopback and non-loopback networks, we prefer the non-loopback one. Don't yet know where and how to fix it though.
Comment 9 Jens Georg 2012-08-04 08:42:06 UTC 
I think I'm doing sth like this in korva. I'll have a look.
Comment 10 GNOME Infrastructure Team 2021-05-17 17:05:15 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gupnp-tools/-/issues/8.