miniupnpd error / feature request

Submitted by dgt on Mon, 03/19/2012 - 08:55
Forums: 
Soulseek General Discussion

So, my modem/router combo is locked down by my provider, but they do support upnp. (Vuze/Azureus, for example, works fine with it and passes a port forwarding test.) However, miniupnp seems to have a problem with it:


[Mon Mar 19 11:30:39 2012] Initializing UPnP
[Mon Mar 19 11:30:39 2012] Device list found
[Mon Mar 19 11:30:39 2012] http://192.168.1.50:56338/, upnp:rootdevice skipping
[Mon Mar 19 11:30:39 2012] Defaulting to first device found, upnp:rootdevice
[Mon Mar 19 11:30:39 2012] Device XML found.
[Mon Mar 19 11:30:39 2012] Found own address to be 192.168.1.50
[Mon Mar 19 11:30:39 2012] Port mapping failure, miniupnp error: -1
[Mon Mar 19 11:30:39 2012] Found own address to be 192.168.1.50
[Mon Mar 19 11:30:39 2012] Port mapping failure, miniupnp error: -1

192.168.1.50 is my workstation address, and I'm not sure if that log is telling me that miniupnp thinks that my workstation is the root device?

Could you maybe include functionality to translate the error code into something meaningful so that users can diagnose upnp errors? (Or, if you can tell me what function you're calling to get that return value I'll just go look it up in the source.)

Thanks so much! You're the bestest.

Submitted by Nir on Mon, 03/19/2012 - 16:54.

Hi dgt,

From what I can see you're right, it appears your own workstation is responding to the UPnP request. What appears to be happening is that the response preempts the router's response, at which point MiniUPnP stops looking. I was hoping there would be a way to make MiniUPnP not return immediately during discovery but haven't found one that's supported by the interface. In response to your question, the function returning the error code is UPNP_AddPortMapping, and -1 translates to UPNPCOMMAND_UNKNOWN_ERROR, which I think just means the device isn't responding to the port mapping request. I can look into modifying MiniUPnP not to return as soon as it gets a response, but that might not be so trivial, I'll see what I can do. Another thing you can try is see what application or service is responding to UPnP discovery requests on your machine. It appears the response is coming from port 56338, so that might be a good starting point. I tried searching for information about that port but couldn't find anything. If you find out what's responding let me know, I may be able set it up on my machine to test MiniUPnP modifications.

Thanks, Nir

Submitted by dgt on Tue, 03/20/2012 - 20:12.

Yeah, my workstation is running a DLNA server (Orb) so that makes some degree of sense.

I wasn't very familiar with upnp, but I'm a network guy & programmer so I just read up on it for about 2 minutes. Apparently a upnp "device" can contain other "devices". Each device advertises "services". You can query against a device to get the "root device" for that device, in case the device you're talking to is inside another device.

So in my case, I think Orb is the rootdevice and there are subdevices for video streaming, audio streaming, etc. But it sounds like miniupnp is just running with the first rootdevice it finds and assumes that it is the router, when it should be querying to see if that rootdevice supports the IGD service.

When I have a bit of time I'll plug my laptop into my router's ethernet port and run some wireshark port captures comparing Vuze to SoulseekQT to see what's actually going on. Just thought that my little bit of investigating might help.