New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UPNP port mapping fails on routers that only support permanent lease #16732
Comments
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: 784aa83
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.10.2
Operating System: linux
GOPATH=
GOROOT=/usr/lib/go
OS & Version: Windows/Linux/OSX
Linux
Commit hash : (if
develop
)Git Commit: 784aa83
Expected 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
The text was updated successfully, but these errors were encountered: