Upnp forwards are closed immediately

[Nick]

I've noticed that Deluge will open a upnp forward but then it immediately closes it. I'm using Deluge 1.1.9 on Ubuntu 9.04 and my router is running dd-wrt. I've got a capture from Wireshark if it helps any.

[andar]

What version of libtorrent are you running?

[Nick]

libtorrent11:

Installed: 0.12.2-0ubuntu1 Candidate: 0.12.2-0ubuntu1 Version table:

* 0.12.2-0ubuntu1 0

500 ​http://us.archive.ubuntu.com jaunty/universe Packages 100 /var/lib/dpkg/status

libtorrent-rasterbar4:

Installed: 0.14.4-2~jaunty~ppa2 Candidate: 0.14.4-2~jaunty~ppa2 Version table:

* 0.14.4-2~jaunty~ppa2 0

500 ​http://ppa.launchpad.net jaunty/main Packages 100 /var/lib/dpkg/status

libtorrent-rasterbar4 is from the Deluge PPA on Launchpad.

[arvid@cs.umu.se]

Looking at the wireshark log, deluge is adding mappings for TCP and UDP, and that's it. If they are removed, it's not captured by that log.

[rasa@gmx.ch]

I am experiencing the same problem here, also using dd-wrt (v24-sp2).

I compiled deluge from SVN 1.1 branch using deluge rev 5472 which pulled libtorrent rev 3717 with TORRENT_UPNP_LOGGING enabled.

Looking at upnp.log (posted below) i also do not see any removal but the forwarding rule is not captured by the router. Any other upnp aware software worked so far.

[rasa@gmx.ch]

Output of a deluge session with TORRENT_UPNP_LOGGING enabled. I had to remove the external links due to a Trac spam warning.

[arvid@cs.umu.se]

could you post a wireshark dump of a successful upnp mapping? (by one of the other upnp aware software you mention)

[Nick]

I've attached a Wireshark capture of a successful upnp mapping and unmapping by Transmission.

[rasa@gmx.ch]

Log of a successful upnp session of "transmission" with my router (beeing the 192.168.20.1 host). Only communication between by PC and the router is captured and it should be relatively noise free.

[arvid@cs.umu.se]

Thank you!

The transmission (libminiupnp) and libtorrent are close to identical, and the responses from the router are identical. Which suggests that adding the port mapping is not the problem. Both responses indicate that it was successful. Are you running multiple instances of deluge behind this NAT?

Maybe the router has problems with different portmaps with the same description, and they overwrite each other. Is there a way for me to test that theory on you somehow? Would you be able to rebuild libtorrent from subversion if I check in a potential fix?

[arvid@cs.umu.se]

I have checked in a change that potentially could make a difference to RC_0_14 and trunk of libtorrent. If you're able to update deluge from svn, please test this change. (or apply it manually to your local copy). ​http://code.rasterbar.com/libtorrent/changeset/3727

The first file is the one that applies to you (in the RC_0_14 branch)

[rasa@gmx.ch]

No I am the only one here to use deluge atm. But i don't think that's the problem: utorrent for example addds its mapping only with the string "utorrent" and several mappings through upnp are possible.

I updated my deluge 1.1 source tree which pulled revision 3729 from libtorrent. It did not solve the problem. The new soap message was sent with: <NewPortMappingDescription>Deluge 1.1.9 at 192.168.20.104:61130</NewPortMappingDescription>

[arvid@cs.umu.se]

Ok.

So, the first wireshark dump, the one for Deluge, doesn't actually indicate that anything went wrong. What are the symptoms you see exactly?

Are you sure that initial wireshark was complete?

[rasa@gmx.ch]

My symptoms are easy to describe: When looking at the upnp mapping dialog in dd-wrt i do not see the deluge mapping and the port test within the deluge network config dialog fails. There are no further error messages on any side.

The wireshark session i submittet covers the part where deluge ist not running, then is started and afterwards terminated again. The same procedure with transmission leads to the result that the mapping is added and afterwards, when i close transmission, is removed again. I had no filter acive but the network interface filter.

[Nick]

Replying to arvid@…:

Ok.

So, the first wireshark dump, the one for Deluge, doesn't actually indicate that anything went wrong. What are the symptoms you see exactly?

Are you sure that initial wireshark was complete?

The initial Wireshark dump was complete. I even double checked with a second one and it is indeed only showing the upnp mapping and nothing about an unmapping.

Here is what I see: I start Deluge and I see the forwards appear in the router's web interface for about 1 second. Then they just disappear from the list. Deluge reports the the port is closed and checking with nmap also shows the port as closed.

[arvid@cs.umu.se]

ok. My next theory is that your router is buggy, and even though it doesn't support lease timeouts, it returns OK (there is a specific error code to return in that case, but your router doesn't seem to do that). That's one major difference between the working request and the failing one.

I've checked in a change to use lease duration 0 by default to RC_0_14 and trunk. Could you please try?

thanks!

[rasa@gmx.ch]

The latest change does not change the symptom. The forward rule is still deleted after a second at most.

Do you need any more data?

[Nick]

I just got an update to libtorrent-rasterbar5 and it seems to have fixed this bug. If anyone else can confirm this I think this bug can be closed.