Forums Bug Reports upnp localinfo -p

Are you sure that you have "Identd server" enabled in the "UPnP support" section of the Ports dialog?

Yes

Which make of router are you using? Is it updated to the latest firmware?

It's not a router itself, it's a 'box' given by my ISP that includes a router feature, I don't know for the firmware, but I do have another box, which is a newer version, that I'm not using for some reasons, I'll eventually try it.

If you do /socklisten -p test 113, does the port forward work properly? It may just be that your router blocks UPnP forward requests on certain ports but not others.

That seems to be right, it doesn't work.

The /localinfo -p command works by creating a UPnP port 113, if it does not already exist, getting your external IP address from that UPnP entry on your router and then removing that port, if it is not in use by your identd server. If the router is blocking port 113, this will prevent mIRC from doing this. Unfortunately there is no way for mIRC to know which ports your router blocks. It is probable that the router blocks a number of standard incoming ports, most likely for security. One solution would be for /localinfo -p to use a random port outside the first 1056 services port range. This change will be in the next version.

Maybe that will fix our problem. Is it in the 7.28 beta? I didn't notice a note in the list.

This change was included in v7.26 onwards. A full list of changes can be found in the versions.txt file that comes with mIRC.

mIRC's UPnP support does not work at all for me, and I too have the error "* /localinfo: unable to resolve local host" upon entering "/localinfo -p".

I have figured out why this is happening. mIRC is calling CStaticPortMappingCollection::Add() with L"127.0.0.1" as the fourth parameter, when it should be calling it with the local IP address of the interface the router is connected to (usually 192.168.x.x). Calling it with 127.0.0.1 is causing Windows to put the Computer Name (i.e., the thing set in Control Panel -> System -> Computer Name) between the tags <NewInternalClient> and </NewInternalClient> in the UPnP command sent to the router, instead of the local IP address which is what should be in there. As a result, my router is replying with "HTTP/1.1 500 Internal Server Error" instead of "HTTP/1.1 200 OK" as it should be. And my router's log gets the entry "miniupnpd[___]: Failed to convert hostname '________' to ip address" added to it, where '________' is my Computer Name and "[___]" is the process ID of miniupnpd on the router.

Other applications work fine with UPnP on my setup, and I have verified that the only difference between the ones that work and mIRC, which doesn't, is mIRC's use of "127.0.0.1" as the address instead of the proper local IP address of the interface the router is connected to.

I would speculate that only routers with a broken UPnP implementation are working with mIRC's UPnP support.

That would explain why using another port, different from 113 and outside of reserved ports didn't resolve the problem for me.

Yep, that was only half of the problem. But it was a problem. My router refuses to forward 113 by UPnP, with <errorDescription>ConflictInMappingEntry</errorDescription>. I still have to forward that port manually.

The "127.0.0.1" problem was preventing it from even getting to the point of showing the ConflictInMappingEntry error. It was doing a <errorDescription>Invalid Args</errorDescription> error instead.

Thanks for looking into this. Unfortunately, I have not been able to reproduce this issue yet. When I run mIRC v7.32 here, under Windows 7/8, it uses the correct 192.168.x.x interface IP address when adding the UPnP entry. Which version of Windows are you using? Can you describe your network setup a little more? If you look in the mIRC Options/Connect/Options/Ports dialog and enable binding to a specific adapter, does that make a difference?

Hi Khaled, thanks for your reply.

I'm using Windows XP Professional SP2 64-bit and mIRC v7.32. Maybe Windows 7/8 handles a "127.0.0.1" fourth parameter to CStaticPortMappingCollection::Add() more gracefully, substituting your 192.168.x.x IP address, but Windows XP does not — instead, it substitutes the local Computer Name (which my router doesn't even know about) — at least, that's what my installation of Windows XP has been doing. I can send you a Wireshark log if you'd like.

And no, I tried lots of variations of options in in Options/Connect/Options/Ports, including binding to the adapter, and that made no difference.

I made a tiny DLL that intercepts mIRC's call to CStaticPortMappingCollection::Add() and substitutes my interface IP address in place of "127.0.0.1", and this fixes the problem (makes mIRC's UPnP work perfectly).


Come to think of this, this might actually be a bug in Windows XP. It makes no sense for it to substitute the Computer Name. But that doesn't mean mIRC shouldn't work around the bug ;-)   (if it is a bug)

I tested again under Windows 7/8 and XP SP3. I looked into the CStaticPortMappingCollection::Add() call in the code and mIRC v7.32 is passing 192.168.x.x to that routine under all three Windows versions. So the cause of the issue in your situation seems to be the routine that retrieves the interface IP address, which is being returned as 127.0.0.1 for you, however as far as I can tell it is working correctly here.

If you are using Windows XP SP2, that may be the cause of the issue, as SP3 included a wide range of networking fixes. Unfortunately I no longer have XP SP2 installed, so I cannot test this.

No routine to retrieve the interface IP address is being called. mIRC is passing a copy of the hard-coded Unicode string "127.0.0.1" to CStaticPortMappingCollection::Add(). I've sent a PM with more details.

Also, there is apparently no Service Pack 3 for XP 64-bit. It's 32-bit only. This is strange, because I could have sworn I installed SP3 even though Control Panel->System->General was for some reason still saying "Service Pack 2"; I assumed this was just because the the disc I installed was SP2c.

I use Windows 7 pro 64 bits and I have the exact same problem.
I'm not exactly sure how he is checking which call is made to CStaticPortMappingCollection::Add() but by checking with wireshark, I can see an http request (POST) being made to my router, with an xml format sent as 'data'. But that 'data' does not contain or specify any ip address parameter when /localinfo -p is used, only a port number, whereas when using /socklisten -p, it's the exact same request, with an additional <tag> in the request to specify the (correct) ip address.
Router replies with 500 internal error when /localinfo -p is used, 200 OK when /socklisten -p is used.

So clearly there is a difference in how both works, the http request is missing a parameter with /localinfo -p when the underlying code creates the socket connection

Right, I see what the issue is. The /localinfo -p feature uses its own optimized UPnP routine, with a hard-coded 127.0.0.1 IP address, to quickly add and remove the UPnP entry to retrieve the external IP address. Strangely, this works with the four different router brands that I use to test the UPnP implementation. I will change this to use the active interface address in the next version.

All other UPnP features should work for you though as they use your interface address. If you enable the identd UPnP option, does that work for you? Does it show the correct IP address in the routers UPnP list? You will need to disable the identd "enable when only connecting" option in order to make it persistent so you can see it in the list.

Thanks for tracking down this issue.

Yes, Identd works with upnp

I'm very confused now...

Before the changes I made a couple days ago, in my quest to get UPnP working in mIRC, my Windows XP UPnP configuration was in a state that I can't seem to restore it to now.

* UPnP was working in some apps, but not in mIRC.
* With all apps closed, Wireshark showed lack of a certain kind of activity that is now present, and had the presence of another kind of activity that is now absent.

I did not have the "Internet Connection" icon in Network Connections. I did not have any interface by which to view the list of UPnP ports being forwarded, and yet it was working anyway, in some apps.

Then I enabled "UPnP User Interface". Still, "/localinfo -p" in mIRC gave an error. Applying my DLL patch made it work, and it did not work before then.

Now something about my Windows XP network configuration is entirely different, because I cannot anymore get any UPnP in mIRC to fail while working in other apps, and that goes even for "/localinfo -p". And, there's a constant flurry of UPnP activity visible in Wireshark, presumably so that its status can be shown in the UPnP User Interface. But I can't disable that interface by doing the reverse of what I did to enable it. I can't seem to disable it in any way without disabling UPnP.

The strangest thing is that while I was testing "/localinfo -p" with and without my patch, Wireshark was not showing this constant flurry of UPnP activity (which is presumably for the UPnP User Interface to constantly query its status).


So what I'm basically saying is that I can no longer get mIRC's UPnP not to work.


EDIT: I did install three Windows Updates that aren't automatic updates, last night before going to bed. Maybe one of them did this.

Edit #2: The "constant flurry of UPnP activity" (one query every second) stops when I close all Control Panel related network windows, i.e. Network Connections, Internet Connection Status, etc., and disable the tray icon for Internet Connection. But yesterday, I was not seeing this one-query-every-second at all. Uninstalling the three updates has changed nothing; this anomalous difference persists.

Also, "/localinfo -p" now works even without my patch. My interface IP address, no longer the Computer Name, is now being substituted in now by Windows.