Skip to content
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

Can't start Raiden without internet connection #870

Closed
3 tasks done
ulope opened this issue Aug 8, 2017 · 5 comments · Fixed by #1029
Closed
3 tasks done

Can't start Raiden without internet connection #870

ulope opened this issue Aug 8, 2017 · 5 comments · Fixed by #1029
Assignees

Comments

@ulope
Copy link
Collaborator

ulope commented Aug 8, 2017

Problem Definition

Upon start Raiden tries to gain external connectivity via UPNP or STUN. If no internet connection is available both methods fail and Raiden crashes with STUNUnavailableException.

In normal use this would only be a cosmetic issue (exception instead of a more user friendly error messge) since the public chain isn't accessible w/o internet anyway. However usage scenarios in isolated networks on a private chain are certainly imaginable and should be supported.

Solution

Don't crash if both UPNP and STUN are unavailable but instead print a warning and fall back to using the local ip / port.

Tasklist

  • Implement --nat option (see comment below)
  • Warn user about likely connection problems if no nat traversal is possible
  • Add changelog
@hackaugusto
Copy link
Contributor

However usage scenarios in isolated networks on a private chain are certainly imaginable and should be supported.

Can't we assume that UPNP is required to work on private networks?

If we can't, an approach is to re-add the --external-listen-address option and if the user provide it skip nat punching.

@LefterisJP
Copy link
Contributor

Yes re-adding the listen address and providing an option to skip nat punching via a special argument sounds like the right way to go here.

@ulope
Copy link
Collaborator Author

ulope commented Aug 9, 2017

Can't we assume that UPNP is required to work on private networks?

if we're talking about an isolated network there isn't anything it could do and in "enterprise" environments UPNP is an absolute no-go.

Yes re-adding the listen address and providing an option to skip nat punching via a special argument sounds like the right way to go here.

If we want to provide an option to the user I think we should borrow some ideas from parity's --nat option.

Its help says:

  --nat METHOD                   Specify method to use for determining public
                                 address. Must be one of: any, none, upnp,
                                 extip:<IP> (default: any).

Since we support more than UPNP I'd suggest to use the following "methods":

  • auto - Try UPNP, then STUN finally fall back to None (basically what we do now but with the "None" case fixed)
  • upnp - Only try UPNP, fall back to None
  • stun - Only try STUN, fall back to None
  • none - Don't try to perform external port mapping - use address & port from --listen-address (or its default)
  • ext:<IP>[:<PORT>] - Assume <IP>[:<PORT>] is mapped to --listen-address. If the <PORT> portion is not given use the port from --listen-address

Another approach would be not automatically fall back to None in any of the cases but rather fail with an error message and require the user to explicitly specify --nat none if they chose so. That feels a bit user hostile though.

@LefterisJP LefterisJP added this to the Next minor release milestone Sep 14, 2017
@LefterisJP LefterisJP added the 1 label Sep 14, 2017
@andrevmatos
Copy link
Contributor

Related to this, as we're handling startup connection issues, I'd like to request handling this exception too, which happens when Eth node and Raiden are started together, as Raiden tries to connect too soon to the Eth node, while geth only starts accepting RPC connections a few seconds later:

Welcome to Raiden, version 0.1.0!
Traceback (most recent call last):
  File "/usr/local/bin/raiden", line 11, in <module>
    load_entry_point('raiden', 'console_scripts', 'raiden')()
  File "/apps/raiden/raiden/__main__.py", line 11, in main
    run(auto_envvar_prefix='RAIDEN')
...
  File "/apps/raiden/raiden/ui/cli.py", line 470, in run
    app_ = ctx.invoke(app, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/apps/raiden/raiden/ui/cli.py", line 328, in app
    rpc_client,
  File "/apps/raiden/raiden/network/rpc/client.py", line 314, in __init__
    self.default_registry = self.registry(registry_address)
  File "/apps/raiden/raiden/network/rpc/client.py", line 455, in registry
    poll_timeout=self.poll_timeout,
  File "/apps/raiden/raiden/network/rpc/client.py", line 713, in __init__
    'latest',
  File "/usr/local/lib/python2.7/dist-packages/pyethapp/rpc_client.py", line 404, in call
    reply = self.transport.send_message(request.serialize())
  File "/apps/raiden/raiden/network/rpc/client.py", line 188, in send_message
    **client.transport.request_kwargs
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 555, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 508, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='web3', port=8545): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f48e90a8b10>: Failed to establish a new connection: [Errno 111] Connection refused',))

Raiden then exit after this exception.
PS: if it's this comment is ruled out of the scope of this issue, please, ignore it.

@ulope
Copy link
Collaborator Author

ulope commented Sep 16, 2017

@andrevmatos We should definitely handle this case but I don't think this is the right issue for it. IMO #670 is more appropriate to add this to.

ulope added a commit to ulope/raiden that referenced this issue Sep 16, 2017
ulope added a commit to ulope/raiden that referenced this issue Sep 16, 2017
ulope added a commit to ulope/raiden that referenced this issue Sep 18, 2017
ulope added a commit to ulope/raiden that referenced this issue Sep 18, 2017
hackaugusto pushed a commit that referenced this issue Sep 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants