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
ulope opened this Issue Aug 8, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@ulope
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

This comment has been minimized.

Collaborator

hackaugusto commented Aug 8, 2017

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

This comment has been minimized.

Collaborator

LefterisJP commented Aug 8, 2017

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Collaborator

andrevmatos commented Sep 15, 2017

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

This comment has been minimized.

Collaborator

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 added 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