Open abdes opened 6 years ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is still a bug
In Mysterium we solved this issue by retrying with 0 lifetime https://github.com/mysteriumnetwork/node/blob/master/nat/mapping/port_mapping.go#L113
Probably a good idea for us too.
There is also #2380 which could be tackled at the same time.
Hi there,
please note that this is an issue tracker reserved for bug reports and feature requests.
For general questions please use the gitter channel or the Ethereum stack exchange at https://ethereum.stackexchange.com.
System information
Geth version:
geth version
Geth Version: 1.8.8-unstable Git Commit: 784aa83942e3dbc9bab0385475dbf3755a9892ac Architecture: amd64 Protocol Versions: [63 62] Network Id: 1 Go Version: go1.10.2 Operating System: linux GOPATH= GOROOT=/usr/lib/goOS & Version: Windows/Linux/OSX Linux
Commit hash : (if
develop
) Git Commit: 784aa83942e3dbc9bab0385475dbf3755a9892acExpected behaviour
At startup geth attempts to add a port mapping using UPNP. Some routers only support permanent leases (i.e. lifetime = 0). In such scenario, it is expected that geth understands the returned HTTP response and the error in the SOAP message and re-attempts the port mapping with a permanent lease.
Actual behaviour
If the router only supports permanent leases (i.e. lifetime = 0), geth fails to handle the HTTP error response and just abandons the port mapping.
Steps to reproduce the behaviour
Start get behind a NAT using NetGear router R8000 or R6300 or any other router that only supports permanent lease for UPNP port mapping.
Changing p2p/nat.go mapTimeout to 0 results in the UPNP request succeeding.
Backtrace