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 711320 - Not possible to use rygel from routed local networks
Not possible to use rygel from routed local networks
Status: RESOLVED FIXED
Product: gssdp
Classification: Other
Component: General
0.20.x
Other Linux
: High normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-03 10:02 UTC by Håvard Moen
Modified: 2019-02-22 09:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use pktinfo to determine destination client. (14.84 KB, patch)
2014-03-15 09:35 UTC, Jens Georg
committed Details | Review

Description Håvard Moen 2013-11-03 10:02:14 UTC
Rygel seems to do autodetection of local networks based on the IP and netmask set on the interfaces on the box rygel is running on and then only answering DLNA queries from those networks. This means that routed local networks is not able to get response from Rygel.

To reproduce:

In my local network I have the following setup

local lan  (192.168.0.0/24) - (.1) router - internet
local wlan (192.168.1.0/24) /

Running rygel on my machine on the local lan (192.168.0.199) it receives multicast packages from my phone on the wlan, but will not respond to it. If I however trick rygel by running

  ip addr add 192.168.0.199/23 dev eth0
  ip route del 192.168.0.0/23 dev eth0  proto kernel  scope link  src 192.168.0.199

I can reach rygel just fine from my phone.

Either rygel should not figure out on its own what networks is allowed and leave this up the the local router or an option to list local networks should be added.
Comment 1 Jens Georg 2013-11-03 15:11:01 UTC
This is handled in GSSDP
Comment 2 Jens Georg 2013-12-17 08:01:52 UTC
Basically this needs changing recvfrom to recvmsg and process the information in the msg structure (and setting the proper socket options, IP_PKTINFO on linux and whatever it is on BSD/Win32) instead of doing netmask matching for the source packages to determine the network interface the packet was received on.
Comment 3 Jens Georg 2014-02-02 10:39:11 UTC
meh, if we were to use g_socket_receive_message, we'd also need to implement a subclass of GSocketControlMessage, otherwise we don't get any message back :-/
Comment 4 Jens Georg 2014-03-15 09:35:17 UTC
Created attachment 271991 [details] [review]
Use pktinfo to determine destination client.

Does this patch help you?
Comment 5 Håvard Moen 2014-03-15 12:09:17 UTC
Yes, this patch solved the problem, thank you.
Comment 6 Jens Georg 2014-03-15 18:16:22 UTC
Thanks. so we now "just" make that a nice, portable implementation... ;)