Forums Bug Reports Support for UPnP routers

It's a wonderful thing that Mr. Mardam-Bey has finally implemented UPnP into mIRC. I just checked out v7.1 the other night, and was positively surprised. However, some things still seem a bit confusing. Now check this out, when I eg. CHAT/SEND to another user, as he or she accepts eg. a CHAT request, the CHAT window is indeed established. However, the very instant I type the send my first line of chat through it, the connection suddenly drops. At DCC/SEND, same thing. At one time, I managed to send a couple of kilobytes, but then it got terminated. Weird thing, huh?! It's not an issue with my locally resolved ip/host, because they are correct. Also, I tried disabling UPnP and insetad enter a couple of manually forwarded ports. Now DCC worked correctly. So, there's obviously something. For the record, I'm on a D-Link DIR-615 router. UPnP works fine with other applications. Too bad there isn't much of "debug mode" in mIRC, or I could have sent more specific logs.

Regards~

Revisiting the subject with some additional details, that may or may not be of value to Mr. Mardam-Bey. First off, I think the UPnP implementation has a good ground to stand on. I.e. I know lots of applications that has tried implementing UPnP, where their attempts to bind ports (eg. ncpa.cpl / Internet Gateway / Internet Connection @ Windows XP) has been somewhat a "semi-manufactured article". The ports has indeed been forwarded, but they'd been forwarded to loopback address (127.0.0.1) instead of the actual LAN IP of the desired machine. This "method" for UPnP of fetching local IP seems to affect pre-Vista versions only, 'cuz the very same apps seem bind IP correctly in eg. Vista/W7, but not in XP. However, like I said, roses for using a method for local IP lookup that doesn't return 127.0.0.1, but the correct IP. As far as I can see, the mIRC UPnP implementation is standing on the finish line, very few inches from complete.

So, paragraph above just private concern really, not for your real interest. So, back to real report.

Like I said, connections drop the ~second after establishment. However(!), it seems to affect the DCC ports only. I tried switching IDENTD default setting of killing ident daemon after successful connect to having it always enabled. The UPnP mappings stayed correct.

So, what's the difference? Here is where I think the answer lies. The UPnP mapping for IDENT remains in earlier mentioned 'ncpa.cpl / Internet Gateway / Internet Connection' listings until i shutdown mIRC. However, when it comes to DCC, when I request a DCC CHAT/SEND, the port is indeed added to the listings, but the very instant the other part is accepting, the port mapping is revoked from the listings, thus [assumably] why it disconnects.

Hope this'll be of any help!
Good luck!

Thanks for the feedback. mIRC does indeed close the UPnP port right after it has accepted the incoming connection. This seems to work fine for me under the two different routers that I own and for other users who have tested out the UPnP support.

That said, different routers implement UPnP support slightly differently. Perhaps some routers require an application to wait a few seconds after the incoming connection has been accepted before closing the UPnP port. Or it may be that they require the UPnP port to remain open for the lifetime of the socket connection.

mIRC closes the UPnP port for security reasons ie. to make sure the port is not left open on your system any longer that it needs to be. However, I can change this so that mIRC waits a few seconds before closing the port, after accepting the incoming connection. This should be in the next version.

Hi!

First, sorry for 're-bumping' this thread, but I was just so glad. Just fifteen minutes ago I got news that mIRC v7.14 was out, so I (of course) downloaded and installed it immediately.

To my great delight, UPnP now works _flawlessly_. Bindings are suddenly working like a charm on both my D-Link DIR-615 and my D-Link DIR-635. I can only assume this would go for the well known DIR-655 as well, even though I haven't had a chance to try that one out. Like you said Khaled, it was probably something these routers requiring some extra up time for the connection to not get lost.

Anyways, just wanted to say thanks!
Good luck on further development of this brilliant IRC client!