MSEARCH sometime failing

[AlexDmr]

Hello, first thanks for this module wich is very helpful to me! :)
However I encounter some problems during the MSEARCH. Sometime it goes right, I can detect every UPnP device that is present on the network, but many times I get stuck : the only device that is detected is my local computer, its adress is 127.0.0.1, if I launch XBMC then it is also detected but the adress is 127.0.0.1:... Every other UPnP device that is not on my computer just never appears, whatever how long I wait for it.
Those times I have to restart the msearch (and actually my whole programm) some times before everything get detected.
My OS is windows 7. I suspect that the UDP socket is sometimes only listening to my computer but I don't know how to properly configure it.
I implemented a UPnP stack on TCL language few years ago and I encountered the very same problem as long as I was using my own multicast UDP sockets, so I had to include into my code the intel UPnP library (well, the part of it that was related to SSDP actually) to make it works properly, that's why I suspect here a socket configuration problem.

[stormboy]

I guess you are ensuring that the NIC has a proper IP address on the network when the search function is called.
The relevant lines of code are in upnp.js:

var client = dgram.createSocket("udp4");
client.bind(); // So that we get a port so we can listen before sending
// Broadcast request
client.send(message, 0, message.length, SSDP_PORT, BROADCAST_ADDR);

This uses a core NodeJS API. There is a note at http://nodejs.org/api/dgram.html that says behaviour of bind() has changed and is now always asynchronous. Perhaps the client.send(...) needs to occur in a callback function in the bind call. Are you able to try this or do you need me to make a code change for you to test out?

[stormboy]

I've made a change in when the MSEARCH message is sent. It is now done via a callback from the bind() function. Please try this out.

[AlexDmr]

Hello and thanks for the help.
Unfortunally the problem is still there. I added some console log in ControlPoint.prototype.onRequestMessage = function(msg, rinfo) {

What happen is that sometime rinfo only contains adress 127.0.0.1

Also, after the MSEARCH has ended and when rinfo contains the "right adresses" the this.requestParser.execute(msg, 0, msg.length) returns an error when I launch on my PC XBMC (a lot of messages arrive but each of them trigger an error when parsed).

Hope this can help...

[AlexDmr]

If it can help, when there is an error, the message displayed in the cosole looks like :

ret is displayed like that :
ERROR { [Error: Parse Error] bytesParsed: 0, code: 'HPE_INVALID_METHOD' }

The message is displayed like that:
<Buffer 4e 4f 54 49 46 59 20 2a 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 32 33 39 2e 32 35 35 2e 32 35 35 2e 32 35 30 3a 31 39 30 30 0d 0a
4c 6f 63 61 ...>

[AlexDmr]

Warren Bloomer notifications@github.com a écrit :

I've made a change in when the MSEARCH message is sent. It is now done
via a callback from the bind() function. Please try this out.

---

Reply to this email directly or view it on GitHub:
#3 (comment)

Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

[AlexDmr]

Hello, I'm back with this code. Using windows 8.1, it almost works everytime (yeahhh!) but I still encounter from time to time the same disagreament. After investigation it turns out that the problem is clearly located with the dgram module. I mean that both the UDP server and client socket may not always bind to the right network interface.
After carefully reading the drgam documentation, I did not found any wrong use of it in node-upnp code. As a consequence, I added some debug information using the network package and am waiting for next bug to see what happens.

[stormboy]

Great. Hopefully you'll get to the bottom of the issue.