Opened 14 years ago

Closed 13 years ago

#973 closed bug (Fixed)

Upnp forwards are closed immediately

Reported by: Nick Owned by: andar
Priority: major Milestone:
Component: Core Version: other (please specify)
Keywords: upnp Cc:

Description

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.

Attachments (4)

Upnp-capture (38.7 KB) - added by Nick 14 years ago.
upnp.log (2.3 KB) - added by rasa@… 14 years ago.
Output of a deluge session with TORRENT_UPNP_LOGGING enabled. I had to remove the external links due to a Trac spam warning.
Transmission-upnp (52.1 KB) - added by Nick 14 years ago.
upnp-transmission-dd-wrt-24.log (12.4 KB) - added by rasa@… 14 years ago.
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.

Download all attachments as: .zip

Change History (20)

Changed 14 years ago by Nick

comment:1 Changed 14 years ago by andar

What version of libtorrent are you running?

comment:2 Changed 14 years ago by 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.

comment:3 Changed 14 years ago by arvid@…

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.

comment:4 Changed 14 years ago by rasa@…

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.

Changed 14 years ago by rasa@…

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

comment:5 Changed 14 years ago by arvid@…

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

Changed 14 years ago by Nick

comment:6 Changed 14 years ago by Nick

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

Changed 14 years ago by rasa@…

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.

comment:7 Changed 14 years ago by arvid@…

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?

comment:8 Changed 14 years ago by arvid@…

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)

comment:9 Changed 14 years ago by rasa@…

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?>

comment:10 follow-up: Changed 14 years ago by 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?

comment:11 Changed 14 years ago by rasa@…

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.

comment:12 in reply to: ↑ 10 Changed 14 years ago by 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.

comment:13 Changed 14 years ago by arvid@…

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!

comment:14 Changed 14 years ago by rasa@…

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?

comment:15 Changed 14 years ago by 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.

comment:16 Changed 13 years ago by Cas

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.