Can't start Raiden without internet connection

[ulope]

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]

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]

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]

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.

[andrevmatos]

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]

@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.