GNOME Bugzilla – Bug 733651
lot of device-(un)available spam since GSSDP started using pktinfo
Last modified: 2019-02-22 09:29:49 UTC
I see dozens of useless "device-proxy-unavailable"/"device-proxy-available" signals on GUPnPControlPoint startup: There is a SSDP packet and then the UDN goes unavailable and then immediately becomes available. it's even visible on gupnp-universal-cp UI: the devices appear and disappear rapidly for a second. This started happening after gssdp commit 878ab1d3 "Use pktinfo on Linux to determine source if" but I'm not sure which component is to blame yet.
mh. That's about the only commit I'd consider relevant for this.
Actually, it happens before that patch as well... It's just that before 878ab1d3 there was maybe one case of this per device whereas afterwards there's maybe 10-20 cases per device. Maybe some kind of a mixup with the interfaces: the "device-proxy-unavailable" and then "device-proxy-available" comes from GSSDPResourceBrowser:resource_available(): these locations obviously do not match so it assumes we've missed a byebye: http://192.168.100.1:49246/42c71703-af8f-4cf2-ab64-1c54d53c6b07.xml http://10.10.15.141:56994/42c71703-af8f-4cf2-ab64-1c54d53c6b07.xml
After g_socket_receive_message() the host address/interface filtering isn't run at all because num_messages == 0.
Maybe something odd with pktinfo availability detection?
Or with the registration of the PktInfo GType
The registration seems a bit off. The GType not listed if I enumerate the available SocketControlMessage types. Calling g_type_ensure() fixes that, but that wasn't the problem -- or at least it's not a problem I've reached yet: there just aren't any control messages to process in the first place.
Created attachment 281664 [details] [review] Fall back to comparing networks if no pktinfo is available This preliminary patch drops the number of useless unavailable/available signals on gupnp-universal-cp startup from ~35 to ~6 on my machine that has 3 network interfaces (plus loopback). The UPnP network contains 2 devices and 7 services. It would be interesting to know why I don't see any control messages on my box, but I don't think GSSDP can assume that they exist anyway so something like this probably makes sense... Anyway, I'll still look more closely to the remaining signals, maybe there's something relevant to see there as well.
Ok, the remaining signals are all interface mixups: I have a normal ethernet connection and 'virtbr1' that is probably virt-manager created one (?). Rygel responds over both of these and ResourceBrowser gets confused. This one is probably not going to be a common problem outside development as it only happens when same USN is available over several interfaces... but listing the problems for completeness: * we end up with random location for the USN -- whichever reply we received last * every time the location (interface) changes, there is a simulated bye bye (because https://bugzilla.gnome.org/show_bug.cgi?id=724030). This is pretty annoying.
Oh, now I got it. The original problem (no control messages at all) happens because the socket option IP_PKTINFO doesn't get set! I started looking further into the missing GType registration, and both of those things happen in gssdp_socket_enable_info(). HAVE_PKTINFO is _not_ defined in that function.
Created attachment 281680 [details] [review] Include config.h in gssdp-socket-functions.c PKTINFO socket option was not set because of missing HAVE_PKTINFO definition.
Created attachment 281681 [details] [review] Use int consistently for packet info interface index g_value_set_uint() with an int argument is not good: use int consistently (based on the kernel value being an int).
Review of attachment 281681 [details] [review]: +1
Review of attachment 281680 [details] [review]: ARGH.... +1 I'll do a release this evening.
mh. Why does this break make check
Created attachment 281719 [details] [review] Fix pkt-address property in PktInfoMessage Signed-off-by: Jens Georg <mail@jensge.org>
Attachment 281680 [details] pushed as e025867 - Include config.h in gssdp-socket-functions.c Attachment 281681 [details] pushed as 21a9e99 - Use int consistently for packet info interface index Attachment 281719 [details] pushed as 1c737f1 - Fix pkt-address property in PktInfoMessage
Ah, this was also the source of those weird "Invalid argument" errors