Persistent UPnP problems

[ianap]

Hi all,

(this may be a bit long-winded - sorry)

First of all, thank you all for your work on Shareaza and here on the forums. I've been using the software for years now.

For years now, I've noticed problems with UPnP, and I've seen a few reports on the forums that match my own problems. Basically, UPnP with Shareaza has never worked for me (I guess I've been really unlucky in my router choices ). However, as I've always been able to set PF manually, it wasn't much of a problem - it was only a nuisance. Recent UPnP code fixes or changes have nothing to do with it - I've first noticed these issues about 6 years ago.

But I noticed that a better UPnP support may not only help the network itself (more High IDs), but also make it quicker for newbies to set it up. Port forwarding is easy for us IT pros or PC/Network enthusiasts, but it's Aramaic for the average user.

Just to make sure: yup, I've disabled firewalls, security products, anything that might prevent the UPnP setup from working correctly. I've also successfully tested other software with *and* without firewalls/security products and the results were positive for the UPnP setup.

In short, I am pretty sure there are no issues with my setup+UPnP, which is:

Windows 7 64-bit;
Wireless Router TP-Link WR541G with UPnP Enabled;
All UPnP + SSDP services and dependencies enabled in Windows;
UPnP working for other applications (uTorrent, Skype, LogMeIn, etc).
Absolutely *no* extra security features (firewalls, filtering, etc) enabled on the Wireless Router;
Shareaza 2.7.2.0

This is the DEBUG Shareaza log when trying to use UPnP in my setup:


[16:55:00] Iniciando o núcleo de rede do Shareaza...
[16:55:00] Trying to setup port mappings using NAT UPnP...
[16:55:00] Trying to setup port mappings using Control Point UPnP...
[16:55:00] Aceitando conexões TCP de entrada na 0.0.0.0 porta 6346.
[16:55:00] Escutando por datagramas UDP em 0.0.0.0 porta 6346.
[16:55:00] Is Gnutella2 hub capable?
[16:55:00] NO: hub mode disabled
[16:55:00] Is Gnutella1 ultrapeer capable?
[16:55:00] NO: ultrapeer mode disabled
[16:55:09] Found UPnP service: urn:upnp-org:serviceId:L3Forwarding1
[16:55:19] Found UPnP service: urn:upnp-org:serviceId:WANCommonInterfaceConfig
[16:55:31] Traversing the service list of UPnP device failed.
[16:55:31] upnp: Invalid Document

The above gives me a lowid and failures on Shareaza's Connection Test.


But instead of only reporting my findings, I'd like to help, if possible. I'm not a programmer, but I do have a good Networking / Security background and I'm in full control of my own (very small) infrastructure, so I can provide a few non-working examples, a few working examples, network dumps (through Wireshark/Tcpdump/Netmon pcap files) and relevant TXT dumps of the main TCP/UDP conversations, including two working examples of different implementations. I believe they *may* be useful as an easy way to see how different approaches to UPnP result in a successful setup for us, unlucky owners of routers with which Shareaza does not chat nicely.

So, my tests were:

1) I used upnptest_0.9.4 for my first tests. I downloaded it years ago for my first tests, but couldn't follow through back then. In my case, the only successful UPnP setup using this software is the ACAT (xtreme) test, which consistently works. I'm attaching the network capture of the ACAT test and the ASCII "conversation" that took place. The network captures can be read by Wireshark/Tcpdump/Netmon and any other PCAP-compatible software. The ASCII text is the straightforward "conversation" contained in the capture (it's following the order of the packet sequence), which may be more useful... but I'm including everything, anyway;

2) The second "sniffed" test was performed with a nameless application, which has always worked in my setup. It might provide a few extra clues as to why it works and the methods accepted by my router. I've included the whole session's capture, which includes a few different ways that this app tried to set up PF (for example, trying to use Nat Port Mapping Protocol (probably through PCP) - which didn't work with my router. I'm also including the relevant TXT dumps of the main TCP/UDP conversations (as before, in the order of the packet sequence).

I'm sorry if this is overkill or if this information is actually redundant. Let me know and I will stop the harrassment.

If needed, I can perform other tests as well. I may be able to test a few other routers too, maybe 2 different models.

Thank you for your time.

[old_death]

This might be something for Ryo-oh-ki to investigate. Thank you for the work you've done.

As for solving your problems, have you ever tried to configure your router manually?

[ianap]

Hi, thanks for your reply. Yup, manually setting up port forwarding works fine. High IDs and the whole shebang. It's just UPnP itself that has never worked for me + Shareaza. Thanks for your concern.

P.S.: The eMule forums also have a few topics about UPnP and the ACAT UPnP code as well. Might be worth a peek.

[raspopov]

I planning to try MiniUPnPc library.

[old_death]

[ianap]

Their MiniUPnPc client works pretty well (the basic functions) with my router.
I just sent the project my results so it can be added to their Router Compatibility List.

The library sounds promising.

[raspopov]

You can try a new MiniUPnPc library here: Daily Builds (r9371 or later).

[ianap]

It's working. (r9371)

I tested it with both options - with a specific port (the default option) and with random ports. Both worked, and Shareaza successfully removes the port mapping when it's disconnected or closed (I checked the router's forwarding status).

I found a small bug, though, which shouldn't be too much trouble (I guess). The steps to reproduce it are:

1) Connect with UPnP using a specific port (it can be the default 6346);
2) After you're already connected, go to Settings and change it to random port mode;
3) It will successfully connect again, using a random port;
4) If you check your router, though, the previous port forwarding is not removed;
5) When you close Shareaza or manually disconnect, the previous port forwarding(s) will remain active in your router;
6) If you do it 3 or 4 times, you may end up with 8 or more inactive port redirections.

I will try to test it in a few different routers as well - it may take me a few days though. Thank you (all) for looking into this.

[raspopov]

Fixed here: Daily Builds (r9374 or later).

[ianap]

Cool, thank you.

My results with r9374, when changing the port forwarding settings (with UPnP enabled) are:

From a specific port to another specific port: Shareaza removes the old port mapping correctly;
From a specific port to a random port: Shareaza does not remove the old port mapping (old specific port), even when closing the program;
From a random port to another random port: Shareaza does not remove the old port mapping (old random port), even when closing the program.

[ianap]

I cannot reproduce the bugs any longer with r9383.

[old_death]

Nice! So this issue is finally fixed then?

[ianap]

Yup - and a few other bugs related to it as well.
I'd pay a round of the $PREFERRED_BEVERAGE to everyone, but the travel costs would be kinda prohibitive.

[old_death]

You could pack a few bottles into a packet and send it to Ryo. I'm sure shipping some few kilos of cargo to Russia shouldn't be that expensive.