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 724030 - Recover from lost bye bye packets
Recover from lost bye bye packets
Status: RESOLVED FIXED
Product: gssdp
Classification: Other
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-10 13:00 UTC by Branislav Katreniak
Modified: 2019-02-22 09:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed fix with a test. (8.11 KB, patch)
2014-02-10 13:02 UTC, Branislav Katreniak
none Details | Review
Patch from git (8.84 KB, patch)
2014-02-10 13:06 UTC, Branislav Katreniak
none Details | Review
Patch v2 (12.87 KB, patch)
2014-02-14 11:28 UTC, Branislav Katreniak
committed Details | Review

Description Branislav Katreniak 2014-02-10 13:00:54 UTC
When ssdp server is forcefully stopped and started again, it sends BYE BYE packets at its start. But if server does not follow SSDP specification or if we miss the BYE BYE packets for any other reason, gssdp_resource_browser believes that the server was never restarted. If location changed after server restart, we are not able to talk to the server any more.
    
This patch checks whether location matches previous location. If not, BYE BYE packets is simulated.
Comment 1 Branislav Katreniak 2014-02-10 13:02:28 UTC
Created attachment 268668 [details] [review]
Proposed fix with a test.
Comment 2 Branislav Katreniak 2014-02-10 13:06:41 UTC
Created attachment 268669 [details] [review]
Patch from git
Comment 3 Jussi Kukkonen 2014-02-11 12:16:19 UTC
Review of attachment 268669 [details] [review]:

Looks like a decent idea to me if there's a real problem (I'm assuming this is based on testing with an actual broken server). The downside is everyone using even more memory based on messages that are really cheap for malicious senders to send... Scary but I guess that's just the name of the game with upnp.

There's one area where I'm not sure if this works 100%: the "AL" (alternative locations) header users. I never see that header and I don't even know where it's specced... but we seem to support it.

::: libgssdp/gssdp-resource-browser.c
@@ +675,3 @@
         if (!usn)
                 return; /* No USN specified */
+        location = soup_message_headers_get_one (headers, "Location");

We don't currently bail out if Location is not present, but I believe we should. Maybe that should be in a separate patch though...

In any case you should reuse this header later in the function, where the same header is looked up again.

@@ +697,3 @@
 
+        /* If location does not match, expect that we missed bye bye packet */
+        if (resource && strcmp(resource->location, location) != 0) {

With the current implementation, both locations can be null here. Maybe we really should bail out on missing Location header early...

::: tests/gtest/test-regression.c
@@ +380,3 @@
                g_test_add_func ("/bugs/gnome/673150", test_bgo673150);
                g_test_add_func ("/bugs/gnome/682099", test_bgo682099);
+               g_test_add_func ("/missed_bye_bye", test_missed_bye_bye);

I don't personally mind the function names, but I think it's a good practice to keep the bug number somewhere and test path seems like a good place: "/bugs/gnome/724030"
Comment 4 Branislav Katreniak 2014-02-11 13:49:07 UTC
>location

You are right.

>"AL"

I never saw AL and I don't understand what it is used for. Should I compare also AL?

> /missed_bye_bye

I did not have bug at the time the patch was written. I will fix this. But what is the right place for this test? test-regression or test-functional?

I will prepare another patch to fix the issue when I have replies to my questions.
Comment 5 Jens Georg 2014-02-11 14:48:00 UTC
I once had looked up where that AL stuff comes from and there was a reason for it but I've forgotten what and where and why.
Comment 6 Jussi Kukkonen 2014-02-12 18:59:38 UTC
I took a look at the SSDP ietf draft on a hunch and that's where AL (and missing location) comes from. This phrase is in pretty much every request, including the notifys:

> SHOULD include the service's location expressed through the
> Location and/or AL header.

So according to the ietf draft, it's fine to not have a location at all if you have something in AL... The UPnP spec on the other hand does not even mention AL and explicitly states that location header is required.

I really doubt anyone is using AL with GSSDP and the UPnP spec is certainly the important one here but ...  maybe you could make sure the patch copes with no location headers set (basically, don't mind about AL and use g_strcmp0() in the comparison)? That way functionality stays same just in case someone does use it.

(In reply to comment #4)
> > /missed_bye_bye
> 
> I did not have bug at the time the patch was written. I will fix this. But
> what is the right place for this test? test-regression or test-functional?

At least I don't care about that. As long as we run it I'm happy.
Comment 7 Branislav Katreniak 2014-02-14 11:28:49 UTC
Created attachment 269113 [details] [review]
Patch v2

New patch addressing the comments
Changes:
* compare location + AL, not only location. Parse locations only once.
* discard ssdp:alive packets with no location + AL
* rename test to match bug number
Comment 8 Branislav Katreniak 2014-03-11 13:23:23 UTC
Any chance to get this patch reviewed / merged?

I believe it is useful in general. 
For us it fixed discovery issues that are not possible to reproduce.
Comment 9 Jens Georg 2014-03-15 08:00:54 UTC
Pushed with minor style fixes