Discovery via UPnP

I’m using the deCONZ REST-API on a Raspberry PI 3+ with my own Python program.
Now I would like to perform a “Discovery” offline.
Everybody seems to be familiar with the UPnP method.
I’m not!
The official description
image
is not very helpful.
Can anybody tell me what to do?

I never used it, but why you need it ? you don’t know the deconz gateway ip ?

Try that https://github.com/tenable/upnp_info it seem it scan all your UPnP device

Thank you for your reply.
Of course I know the IP adress as well as the port of my gateway.
But I would like to code my program to deal with all possible configurations.
I have checked “upnp_info.py” but it doesn’t seem to work without an active network connection.

        sock.sendto(ssdpDiscover.encode('ASCII'), ("239.255.255.250", 1900))
OSError: [Errno 101] Network is unreachable

Ha yes …
Strange the scan need to work in local mode. I don’t understand how this code need to work.
But I think you can find this kind of code on google, was just the first result I have found. And yes It need to work offline

Edit:
After some search on the net it seem the adress 239.255.255.250 is an adress that can work offline.

(Google translate)

your computer is contacting 239.255.255.250 (IANA server group, important name resolution servers on the Internet) via port 1900 using Simple Service Discovery Protocol (SSDP) to locate all machines" → Definition IANA: The IANA allocates IP addresses and AS number blocks to RIRs

And the address 239.255.255.250 is a multicast @IP not routed on the Internet and reserved for the SSDP protocol. Clearly, if you launch a ping on this IP, the machine that will answer you will be a machine on your local network and nothing else.

UPNP will work over any network, there are security implications, not highly recommendable. if your PC/workstation can ping the gateway, and multicast are not blocked - should find the gateway.

Such multicasts will not traverse an IP router. (other mechanisms required to proxy or forward)

UPNP - the deCONZ server sends out UPNP multicast every few minutes.
$ sudo netstat -tulpn | grep 1900
udp 0 0 0.0.0.0:1900 0.0.0.0:* 17766/deCONZ

#Here is a sample of the packets - destination is always 239.255.255.250 port 1900

$ sudo tcpdump -i eth0 udp port 1900
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:22:39.856997 IP pi-6.lab.no-ip.org.1900 > 239.255.255.250.1900: UDP, length 343
23:22:39.857397 IP pi-6.lab.no-ip.org.1900 > 239.255.255.250.1900: UDP, length 352

So a node on the same IPv4 broadcast domain (vlan) sees this:

$ python3 upnp_info.py
[+] Discovering UPnP locations
[+] Discovery complete
[+] 1 locations found:
http://1.1.1.1:80/description.xml
[+] Loading http://1.1.1.1:80/description.xml
→ No server string
==== XML Attributes ===
→ Device Type: urn:schemas-upnp-org:device:Basic:1
→ Friendly Name: GATEWAY (1.1.1.1)
→ Manufacturer: Royal Philips Electronics
→ Manufacturer URL: http://www.dresden-elektronik.de
→ Model Description: Philips hue compatible Personal Wireless Lighting
→ Model Name: Philips hue bridge 2015
→ Model Number: BSB002
→ Services:
[+] Fin.

Hope this helps

1 Like