Bug 10275 - UPnP M-Search implementation is wrong
: UPnP M-Search implementation is wrong
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: UPnP
: 7.4.0
: All All
: -- normal with 1 vote (vote)
: 8.0.1
Assigned To: Andy Grundman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-10 15:05 UTC by Graham Douglas
Modified: 2009-06-09 14:11 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Douglas 2008-12-10 15:05:38 UTC
UPnP control point M-Search requests are sent TO multicast address 239.255.255.250:1900, and the responses from devices responding to these requests is sent in UDP UNICAST back to the control point's sending port.

Multicast address 239.255.255.250:1900 on the control point is used for listening for UPnP NOTIFY multicasts from devices.

SC is attempting to use 239.255.255.250:1900 for both SENDING M-search requests and listening for NOTIFY's. As this socket is configured as a multicast listener it does not receive any of the M-Search responses from devices.

The M-Search request should be sent using some different port, which then listens for UNICAST UDP responses from devices.

The symptoms of this defect are that UPnP devices may take considerable time to be discovered as the M-Search responses are not received, so SC only becomes aware of them when they send a NOTIFY message (which typically occurs every 30 mins)

See http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf sect. 1.3.2 for details
Comment 1 Andy Grundman 2008-12-15 09:16:39 UTC
I think may already fixed in some UPnP work I have in a local branch.