Opened 9 years ago
Closed 7 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: | Sensitive: | no |
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 9 years ago by
| Milestone: | 0.9.3 → 0.9.7 |
|---|
comment:2 Changed 8 years ago by
| Milestone: | 0.9.7 → 0.9.12 |
|---|
comment:3 Changed 7 years ago by
| Keywords: | firewall added |
|---|---|
| Milestone: | 0.9.12 |
comment:4 Changed 7 years ago by
| Milestone: | → 0.9.18 |
|---|
Will rescan for UPnP devices periodically, and when reachability changes.
comment:5 Changed 7 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → 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.
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.