[pupnp-tracker] [ pupnp-Bugs-3007407 ] Service traversal issue in AdvertiseAndReply()

[Tracker i. u. n. <pup...@li...>]

Bugs item #3007407, was opened at 2010-05-26 11:07
Message generated for change (Tracker Item Submitted) made by cyt4
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3007407&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chuck Thomason (cyt4)
Assigned to: Nobody/Anonymous (nobody)
Summary: Service traversal issue in AdvertiseAndReply()

Initial Comment:
Hello,

When the UPnP server is started, one alive message is broadcast for each service in each device.  It appears that libupnp's implementation of the alive message generation does not correctly navigate the XML description document when locating the services.  This can result in the wrong UDN being used in the alive message sent for a service.

In my specific case (see attached XML), the root EchoSTB device contains no services, but its embedded MediaServer device contains 2 services.  When the existing libupnp code traverses the EchoSTB device in the XML, it searches the global list of serviceLists within the document instead of searching for a serviceList that is its direct child node.  The ContentDirectory and ConnectionManager services are then announced with the UDN of EchoSTB1 (the root device) instead of with the UDN of MediaServer, which is actually their parent device.

I discovered this behavior using libupnp-1.6.6.  I have generated a patch against branch-1.6.x that corrects the XML navigation such that all services are traversed from their parent device, which results in the correct UDN being sent in the alive message for each service.  I built from branch-1.6.x without this patch, tested, and confirmed that the issue still exists as I observed it in libupnp-1.6.6.  I then built from branch-1.6.x with this patch, tested, and confirmed that the issue was resolved.

Thanks,

Chuck Thomason

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3007407&group_id=166957