-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UPnP SSDP discovery not working using UDP multicast #3
Comments
Assumption is I have some problems in the use of the nim apis. If it helps I can post some C code that does the same thing. |
Yeah, please post the C code and also the output that this code gives. |
Will dig up the code and post that output. |
I have a bad example I put together in C here: The bad example doesn't use the query to do a sendto first before listening for a response. I noticed that regardless of my query, I will get a response from my network which I can easily filter out the key tell-tale signs this is a Hue Hub. Here are some responses from this code below. The giveaway that this is a HUE hub is the presence of a LOCATION value that ends with discovery.xml, for example: One of the approaches people take to find their hub(s) is to enumerate all ip addresses in the range of the local network, and try to hit port 80/description.xml. However that's sort of a waste. If the UPnP approach works, it should yield a narrow set of devices that will respond, and from those you filter based on the LOCATION. It's ugly either way, but the multicast approach should be more efficient.
|
In the Java version of this, it worked like a charm. The nim version I would never get a response. |
Hrm, all I can is guess, but this part is missing from your Nim code (isn't it?):
|
Thanks. I'll revisit this and try that, spent some time on different variations of the discover initially, and eventually switched to the nupnp implementation. UPnP has a bad rap because of security concerns, but this is still useful for a number of IoT type devices that are out there. |
@truedat101 if this is still relevant you could have a look at https://github.com/enthus1ast/nimMulticast |
@enthus1ast actually yeah, awesome. I spent a fair amount of time chasing down what I was doing wrong , so will have a look at your lib. |
Will have a look at this module nimMulticast. |
Finally have some time to look at this. |
just skimmed through your code: |
Good point. Need to get back into this. |
Hmm, tried socket.bindAddr(Port(1900)) , but still just get back empty response. I have to remember how I was snooping the network for UPnP discovery. I've been through the code several times and didn't find a solution. Need to try the suggestion #3 (comment) from Dominik. |
this principally is what multicast joinGroup does.
[david@eb ~]$ ncat -4 --udp 239.255.255.250 1900
this should be visible in your testprogram |
Something like this should work: bindAddr(socket, Port(1900))
let group = "239.255.255.250"
assert true == socket.joinGroup(group)
let res = socket.sendTo(group, Port(1900),cstring(upnpquery),upnpquery.len.cint)
# [...]
let bytesReceived = recvFrom(socket, data, recvlen, recvaddr, recvport)
|
Great, thank you for the tips. I'll jump onto this tonight. As mentioned, I have this all working reliably in my java code and also C code version, but really wanted to make this a no-brainer thing to work with UPnP w/ NIM, and eliminate the need to do discovery using the Hue's funky nupnp solution that requires a proper internet connection. |
So I've added 0.1.2 version of multicast to the project. Strange error when I compile. multicast-0.1.2/multicast.nim(54, 6) Error: undeclared identifier: 'IPv4' This should be present in IPAddressFamily. Anyway, is this something obvious I've missed, or should I file a ticket on multicast. |
@truedat101 strange that this works for me, since this is a pure enum mhh. |
@enthus1ast Thanks I'll give this a look. I guess the only thing I can think of that might be different is I'm on Mac OS X for this particular project and using num 0.17.0. |
i bet this issue is because of 0.17 but i see another issue comeing: it might be that IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP int values differs from posix (they differ from old windows to new windows and linux. |
Ahh,ok, that does make sense. I can continue testing on the mac. At least that can get resolved through testing. I can move to a later release as well. |
Great upgraded to multicast module 0.1.3. Build is fine. On the run, I get:
|
@truedat101 i've pushed a new branch of multicast: https://github.com/enthus1ast/nimMulticast/tree/freebsdAndMacos i still have no access to macos but i've installed a freebsd and tested the branch on it. Please report if macos works now, then i'll merge it into master :) |
Apologies for the delay. I am sad to report my mac died. Awaiting its return from the shop and then I'll jump back onto testing that. |
@enthus1ast mac is back. Going to give this a go. |
I've implemented this same logic in several other languages, but couldn't get it working in nim. I'm assuming it is my lack of understanding of the libraries or the low-level networking.
Method in question:
https://github.com/IoTone/huenim/blob/master/src/huenim.nim#L136
findHueHubsViaUPnP()
To reproduce:
Call findHueHubsViaUPnP()
It should return some response for any other devices on the network that match the criteria. However, no devices respond, not a single response. I can confirm that the request goes out (using network tools to monitor UDP multicast messages).
The text was updated successfully, but these errors were encountered: