Not working in Windows 10

[m-altmeyer]

Hey,
first of all thank you for developing this great node package! Unfortunately, I am not able to use it under Windows 10. I get the following error message:

 Error: addMembership EHOSTUNREACH
    at exports._errnoException (util.js:1026:11)
    at Socket.addMembership (dgram.js:508:11)
    at addMembership ([***]\wemo-test\node_modules\node
-ssdp\lib\index.js:177:19)
    at Socket.onSocketListening ([***]\wemo-test\node_m
odules\node-ssdp\lib\index.js:173:5)
    at emitNone (events.js:91:20)
    at Socket.emit (events.js:185:7)
    at startListening (dgram.js:121:10)
    at dgram.js:228:7
    at _combinedTickCallback (internal/process/next_tick.js:77:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Is there anything I can do?

Thanks and all the best,
Max

[diversario]

Hey Max,

I haven't used this with Windows but judging by the error and the stack trace I'd say you should look into configuration of your network interface and whether or not multicast is enabled (or maybe it's on the system level).

[diversario]

@m-altmeyer have you tried disabling Windows Firewall and testing this? I think it's enabled by default.

[Matheus-Garbelini]

Hello, I have the same issue, but i think its not the fault of the network. I have an working ESP8266 device with ssdp in windows 10, but as a generic root device.
Here's the XML generated that works:

static const char* _ssdp_schema_template =
  "HTTP/1.1 200 OK\r\n"
  "Content-Type: text/xml\r\n"
  "Connection: close\r\n"
  "Access-Control-Allow-Origin: *\r\n"
  "\r\n"
  "<?xml version=\"1.0\"?>"
  "<root xmlns=\"urn:schemas-upnp-org:device-1-0\">"
    "<specVersion>"
      "<major>1</major>"
      "<minor>0</minor>"
    "</specVersion>"
    "<URLBase>http://%u.%u.%u.%u:%u/</URLBase>" // WiFi.localIP(), _port
    "<device>"
      "<deviceType>%s</deviceType>"
      "<friendlyName>%s</friendlyName>"
      "<presentationURL>%s</presentationURL>"
      "<serialNumber>%s</serialNumber>"
      "<modelName>%s</modelName>"
      "<modelNumber>%s</modelNumber>"
      "<modelURL>%s</modelURL>"
      "<manufacturer>%s</manufacturer>"
      "<manufacturerURL>%s</manufacturerURL>"
      "<UDN>uuid:%s</UDN>"	 
    "</device>"
  "</root>\r\n"
  "\r\n";

Where %u is specific device strings.
Can I start a simple server that generates a simple xml structure like this so I can test on Windows 10?
Thank you.

[diversario]

@Matheus-Garbelini So, if I understand your question correctly, what you'd need to do here is to start a server like so

var SSDP = require('../index').Server
  , server = new SSDP({
    location: `http://locationofthexmlfilehere`
  })

so that server would advertise to other devices where to look for this XML. You can some other HTTP server somewhere on the network that'll serve the XML.

[diversario]

Possibly similar to #72 (comment) – at the end of the comment there's a bit about disabling SSDPSRV.

[btsimonh]

I just had something a little similar:

6 Jul 02:03:23 - [warn] [function:BuildListOfDevices] Deleted { location: 'http://192.168.1.164:8080',
  diedate: 1499292232526 }
6 Jul 02:03:23 - [red] Uncaught Exception:
6 Jul 02:03:23 - ReferenceError: addMembership is not defined
    at Socket.onSocketListening (C:\Data\dev\yella\build\yellarednew\node_modules\node-ssdp\lib\index.js:245:22)
    at emitNone (events.js:91:20)
    at Socket.emit (events.js:185:7)
    at startListening (dgram.js:121:10)
    at dgram.js:228:7
    at _combinedTickCallback (internal/process/next_tick.js:77:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

this is an SSDP client being created every 30s with a timeout of 10s doing an ssdp-all search.
The dated logs above indicate to me that (in my application), it most likely died after returning from an on('response') callback, but this does not fit the actual exceptions which seems to be on socket creation.

I suspect that it is to do with the network changing, or the machine sleeping/hibernating. I was working until 11pm GMT, so it died ~3 hours after I left the machine. - the machine is set to sleep after 2 hours; so a little strange that it lasted 3 (log times right now definitely match my GMT clock).
Either way, we should check to see if it can be prevented from crashing out. It's worked fine - this is the first and only crash.
My network was USB connected when I left the machine, but it also has knowledge of local wifi point(s), so all sorts of networky changes may occur as it sleeps/hibernates/re-awakens... Maybe the socket was created for an interface, but before the listening code ran the interface was disabled/removed by windows (10)?