Opened 7 years ago

Closed 4 years ago

#661 closed defect (fixed)

I2P doesn't reopen UPnP ports after UPnP router restart

Reported by: zzz Owned by: zzz
Priority: minor Milestone: 0.9.18
Component: router/transport Version: 0.9
Keywords: firewall Cc:
Parent Tickets:

Description

If your UPnP router restarts, I2P will switch to "firewalled" but won't then try to reopen the ports to recover.

I think it would do it if the IP changes but not if it stays the same. There's a state mismatch in that UPnP thinks the ports are still forwarded? Been like this forever. Need to force a reopen of the ports. Right now the only recovery is to restart I2P. We open the ports "forever" and don't periodically reopen them or query the UPnP state to ensure state consistency. For further research.

Subtickets

Change History (5)

comment:1 Changed 6 years ago by zzz

  • Milestone changed from 0.9.3 to 0.9.7

Related issue: UPnP fails to start if the computer has no non-loopback IP address as it can't open the HTTP listen port. When the network is later connected, UPnP doesn't start.

In UPnPManager we can retry UPnP.startPlugin() periodically, but that can take a while so it really needs to be threaded. But not too often. See some comments in there near the top.

comment:2 Changed 5 years ago by zzz

  • Milestone changed from 0.9.7 to 0.9.12

comment:3 Changed 4 years ago by str4d

  • Keywords firewall added
  • Milestone 0.9.12 deleted

comment:4 Changed 4 years ago by zzz

  • Milestone set to 0.9.18

Will rescan for UPnP devices periodically, and when reachability changes.

comment:5 Changed 4 years ago by zzz

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

5ae8608c7d44057491f222571cf66ae1679b6579 in 0.9.17-11

Fixed a bug, mapping wasn't getting removed when device went away, and added a periodic rescan task. Not clear that this fixes all cases but should be an improvement.

See also #959

Optimistically closing both.

Note: See TracTickets for help on using tickets.