Forums Bug Reports upnp localinfo -p

So I have been experimenting with upnp on mirc 7.25 on a windows 7 machine. I have confirmed upnp is working normally by using the microsoft upnp test web page.

I cannot confirm through router logs or otherwise that upnp is working for mirc though.

/localinfo -p returns an error

Is anyone else getting upnp to work correctly?

What error does it return?

I also have that problem, the error returned is "* /localinfo: unable to resolve local host" for me.
I can confirm that upnp is working too though with /socklisten -p or dcc for example

Same here, "* /localinfo: unable to resolve local host"

Sorry for the long response wait, I'd had to run out of state on an emergency trip and only got back.

I am getting the same error as the other guys above. Do we have any ideas?

So upnp isn't working, does anybody have a solution?

I have just tested this on a Windows 7 64bit machine and /localhost -p returns the correct local host and IP address. If you are using a security/anti-virus/firewall application, try disabling it first, then disable and re-enable your internet connection. That may resolve the issue.

I just tried it on window xp 32bits, with no anti-virus software and no firewall running, I still get the same message

I also tested it on Windows XP 32bit, fully updated, and it worked fine. You will need to make sure that you have UPnP installed in Windows, SSDP and UPnP services enabled, UPnP enabled on the router, and so on. If it does not work, this usually indicates that something is not configured correctly. You may want to try the PortForward tool, which is what I use to ensure that UPnP is configured and working correctly.

I did say in my first post that upnp is working since /socklisten -p and/or dccs are working correctly.
Unless it's possible for /socklisten -p to work and still have some misconfigured upnp settings that could cause /localinfo -p to fail, I think that everything is set up correctly (this is true for either winXP or win7 pro 64bits).
I asked people around me, I couldn't find anyone who can get this to work.
I tried the Portforward tool, the only thing it does is showing the ports forwarded, either manually or the one(s) opened with upnp, there is also this button "more informations about this device" which shows some informations, I can provide them if needed.
I confirm that the two services are enabled and that upnp is enabled on the router.

Unfortunately I am unable to reproduce this issue here. I have tested under Windows XP and 7 with both a LinkSys and a NetGear router and mIRC returns the correct results in all cases.

It is not clear whether the user reporting this issue is not able to get any UPnP features at all to work in mIRC or whether their issue is limited to /localinfo.

If you enable all of the UPnP options in the mIRC Options/Connect/Options/Port dialog and then enable Identd (turn off "enable only when connecting") and then use PortForward to check the UPnP settings on the router, does port 113 appear in the UPnP ports list? Is your External IP (as displayed by PortForward) correct?

No, the port 113 doesn't appear in the list, and I even tried rebooting mIRC.
Yes the external IP displayed is correct.
Note that I tried to /socklisten -p test 8002 right after, and it correctly appeared in the list.

This is on win7 pro 64bits, the test on winXP was wrong, the router used doesn't have upnp.

Did you turn off "enable only when connecting" in the Identd dialog? If you run a program like TcpView does it show that mIRC is listening on identd port 113?


That is very odd - /socklisten uses the same method as identd.


When you say it is correct, do you mean the "External IP" displayed in the left hand column for an entry in PortForward? Ideally, you will need to confirm this for the port 113 that mIRC creates, however since you are not seeing port 113 in PortForward, something else seems to be going on.

Yes, that option was already disabled. Here is a screenshot from the TcpView program:

which doesn't show that the port 113 is used by mIRC (or by any others program, I checked) but using /run cmd /k netstat -a, it shows that the port 113 is listened:


Yeah.

The identd port is being identified as "auth" by TcpView, so that looks fine. mIRC is creating both an IPv4 and IPv6 port for identd. So the issue now is why port 113 is not appearing in your router UPnP list. Do you have port 113 set up for port forwaring in your router? That may be interfering with UPnP. Since /socklisten -p is working, I cannot think of another reason why identd would not work in this case, other than router or windows configuration.

I don't have the port 113 forwarded in my router.
Investigating a bit:
-the identd server feature isn't working, even if I change the port number, I don't use that feature but I'm almost certain it worked in the past, perhaps in a different (recent, 7.2x) version of mIRC.
-typing /socklisten -p test 8002, the 'upnp port forwarded' program automatically detect the change whereas is doesn't find anything when using the identd server feature, so there seems to be a difference in how the identd server feature handles upnp, compared to /socklisten -p.
The problem seems to be ipv6 related, that's the only difference there is betweeen /socklisten -p and identd, enabling the identd server results in this in netstat:

When using /socklisten -p, obviously the ipv6 line ([::]:113) doesn't appear.

The IPv6 is not a problem, that is by design. There have not been any changes to UPnP support in recent versions, other than a minor change in v7.12 relating to how UPnP sockets are closed. Was the UPnP identd feature working for you in mIRC v7.1?

I don't really know/remember if it was working at all, I just have a feeling I tested it for some reason and it worked.
I downloaded a copy of mIRC 7.1 from mirc.net and it's not working. But note that the router was a different one at that time so it might be a router, but it's very very unlikely.

Unfortunately I have not been able to reproduce this issue at all. I have just tested it on three other computers, using XP and 7, using both of my routers, over a wireless and cable connection, and it worked fine in all cases. My guess is that it is an mIRC/windows/router configuration issue at your end.

I'm not using any special setting on windows, and I'm using the settings you me to use in mIRC, the router only have a checkbox 'enable upnp', and I turned off its firewall, the really odd thing is that upnp does work for socket and dcc. I do remember that, when I tried /localinfo -p with my old router, mirc was freezing for ~7 seconds before displaying the error message.

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.

UPnP can be a little erratic, so I am not too surprised to hear this. That said, even though it is now working for you, using the local interface address for /localinfo -p is probably a good idea, so I will go ahead and include that change in the next version.

Some feedbacks about this..

I couldn't get /localinfo -p to work (7.39) so I started investigating again with wireshark to find some clues (still on win7 pro 64 bit, router is still the same, upnp is enabled and works for socklisten -p, or dcc, or identd server on port 113 (the same port which wouldn't work before on this same report))

While I was trying to see with wireshark if anything was sent from mIRC it somehow magically started to work (first time ever for me, for /localinfo -p).
I tried to reboot mIRC, still working, I tried to reboot Windows, still working..
So I just let it go, but one hour later here I am trying it again, it doesn't work.

When it fails, I just don't see any request or anything sent from mIRC to the router with wireshark, it seems mIRC fails automatically without actually trying anything upnp related because of a prior check that would fail.
Is there a way for mIRC to report "/localinfo: unable to resolve local host" without actually trying to do anything upnp related?

There was a similar post discussing the same issue recently, where UPnP was behaving intermittently. In my tests, described in the above post, I experienced the same intermittent behaviour when using both mIRC and a UPnP monitoring tool, which was designed to monitor UPnP activity. It would work fine most of the time and then suddenly, it would stop working. I eventually tracked it down to my firewall, which when disabled allowed mIRC and the UPnP tool to work all the time without any issues. Beyond that, I am afraid I have no explanation. It may just be that UPnP is unreliable.

Indeed, I just downloaded PortForward, before running it I tried /localinfo -p, didn't work, right after running PortForward, it worked. I have disabled all firewalls from windows and from my router, no AV software running.
I tried /socklisten -p test 8009, PortForward correctly reports the port 8009 being forwarded, I close that socket and it correctly reports it not being forwarded anymore.
Well I don't think Upnp is unreliable, rather my/our router

More informations about this...

This script http://www.xise.nl/mirc/upnp.mrc works just as good as mIRC.
As in, whenever I try /localinfo -p and it doesn't work, this script doesn't work. Specifically:
The $com call works, but the dispatch doesn't work.
Now the strange thing is that whenever I run the PortForward executable, both mIRC and this COM script works flawlessly.

Edit: I reboot windows to try to get it to fail again and reproduce the test, it would still work, eventually I waited 15-20 mins and /localinfo -p failed again, I opened PortForward and it worked, so it seems consistent.