Opened 12 years ago

Closed 11 years ago

#2275 closed Bug (worksforme)

UPnP / NAT-PMP doesn't update automatically when laptop changes networks

Reported by: mjpieters Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.72
Severity: Normal Keywords:
Cc:

Description

When Transmission starts up with the "Automatically map port" option enabled, it sends out a UPnP / NAT-PMP request for the configured port (randomized or otherwise).

However, when I then close my laptop and move from home to the office or vice versa, Transmission fails to re-request the port from the new network the laptop wakes up in. Moreover, setting a new port or randomizing the port doesn't result in a successful automatic port mapping; the NAT router never gets the UPnP / NAT-PMP request (I run Tomato on my home router and no UPnP port forwards are added).

Work-around: quit and re-start Transmission.

It appears Transmission caches the NAT router address. Disclaimer: I haven't looked into how UPnP or NAT-PMP works.

Change History (12)

comment:1 Changed 12 years ago by mjpieters

Better work-around: unchecking and rechecking the 'Automatically map port' option.

comment:2 Changed 12 years ago by charles

  • Summary changed from Laptop changing networks requires Transmission restart for NAT UPnP / NAT-PMP to work to UPnP / NAT-PMP doesn't update automatically when laptop changes networks

comment:3 Changed 12 years ago by KyleK

Transmission by default checks every 20 minutes if the port is still mapped. If not, it should be remapped automatically.

The port mapping is initiated via broadcast message, it therefore shouldn't matter if Transmission remembers the router address or not.

comment:4 Changed 12 years ago by mjpieters

I don't see evidence of Transmission remapping the port after 20 minutes. Even after hours in a new network the Peer listening port indicator remains red (Port is closed). Only unchecking then re-checking the 'Automatically map port' option unsticks the situation.

To reproduce:

1) disable your network connections (unplug ethernet, switch off airport) 2) start transmission, verify that the peer listening port is closed 3) re-enable your network 4) wait half an hour, verify that the peer listening port is still closed

comment:5 Changed 12 years ago by mjpieters

  • Resolution set to invalid
  • Status changed from new to closed

After my most recent laptop restart I now see transmission properly re-open the port on the new network router after re-awakening. In which case the problem was a local non-transmission-related issue, and this ticket can be closed.

comment:6 Changed 12 years ago by mipstian

  • Resolution invalid deleted
  • Status changed from closed to reopened

I'm seeing this again, in version 1.93 (latest stable at the time of writing). For example, I brought my laptop here yesterday evening, and it showed the port as being closed. Today (after approx. 20 hours) it's still closed. Quitting and restarting Transmission opened it. This is not the first time, it happened plenty of times before. I'm on MacOSX 10.6.3 on a Macbook Pro by the way.

comment:7 follow-up: Changed 11 years ago by oliver

I can confirm this bug using transmission 2.04 (11151) on OS X 10.6.4. I changed the network of my lan from 192.168.1.0/24 to 192.168.72.0/24 and now upnp ceased to work. A tcpdump shows that Transmission is still trying to connect to the old GW 192.168.1.1 on port 80.
None of the above workarounds worked for me. Deleting 'org.m0k.transmission.plist' did not work either.

comment:8 Changed 11 years ago by oliver

  • Cc oliver.stampfli@… added
  • Version changed from 1.72 to 2.04

comment:9 in reply to: ↑ 7 Changed 11 years ago by oliver

  • Cc oliver.stampfli@… removed
  • Version changed from 2.04 to 1.72

Replying to oliver:

I can confirm this bug using transmission 2.04 (11151) on OS X 10.6.4. I changed the network of my lan from 192.168.1.0/24 to 192.168.72.0/24 and now upnp ceased to work. A tcpdump shows that Transmission is still trying to connect to the old GW 192.168.1.1 on port 80.
None of the above workarounds worked for me. Deleting 'org.m0k.transmission.plist' did not work either.

Ha, long story short: Turns out my router (Zyxel P-660HN-F1) did respond with the old network IP to upnp broadcasts. After a restart of the router upnp works fine again. Sorry for the troubles.

comment:10 Changed 11 years ago by jordan

does this problem persist for anyone in 2.20 beta 1?

comment:11 Changed 11 years ago by mipstian

Not for me, I didn't get this in a long time now. Works like a charm!

comment:12 Changed 11 years ago by jordan

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