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!
