Trinity prints noisy error message when being port-scanned

[veox]

• py-evm Version: trinity-v0.1.0-alpha.20-71-g8841a698 (commit 8841a6980254b93294c80a889ed3901fd6baf9c6, slightly past release)
• OS: Arch Linux
• Python Version (python --version): 3.7.1
• Environment (output of pip freeze): MISSING

What is wrong?

Running trinity as

% nice ionice -c3 trinity --network-id=1 --sync-mode=light --discv5 $ETHSTATS_OPTIONS

and then checking if the port is accessible with

% nc -vz localhost 30303

results in this error message being printed:

   ERROR  12-20 17:58:10           LightServer  Unexpected error handling handshake
Traceback (most recent call last):
  File "/home/veox/src/py-evm/trinity/server.py", line 185, in receive_handshake
    await self._receive_handshake(reader, writer)
  File "/home/veox/src/py-evm/trinity/server.py", line 199, in _receive_handshake
    ip, socket, *_ = writer.get_extra_info("peername")
TypeError: cannot unpack non-iterable NoneType object

Not sure if fresh or regression.

How can it be fixed

Not sure.

Checking how "regular" sync mode reacts to this and handles it would be a good start.

[veox]

The "fast" sync variant has:

   ERROR  12-20 18:54:08            FullServer  Unexpected error handling handshake
Traceback (most recent call last):
  File "/home/veox/src/py-evm/trinity/server.py", line 185, in receive_handshake
    await self._receive_handshake(reader, writer)
  File "/home/veox/src/py-evm/trinity/server.py", line 199, in _receive_handshake
    ip, socket, *_ = writer.get_extra_info("peername")
TypeError: cannot unpack non-iterable NoneType object

(Same code path.)

[pipermerriam]

So we use this API:

https://docs.python.org/3/library/asyncio-protocol.html#asyncio.BaseTransport.get_extra_info

Which delegates to this API

https://docs.python.org/3/library/socket.html#socket.socket.getpeername

It looks like we just need to implement some error handling there for the case where that returns None and probably log some information about the connection for debug purposes.

[pipermerriam]

@veox I wasn't able to reproduce this locally, but I'm curious if you would pull #1661 and run it and tell me what happens with the new error handling code.

[veox]

@pipermerriam Works for me. ^_^ (Replied in PR.)

[carver]

Theoretically fixed by #104