Title: SSLContext.wrap_socket() throws OSError with errno == 0
Type: behavior Stage:
Components: SSL Versions: Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: christian.heimes, martin.panter, nikratio, xgdomingo
Priority: normal Keywords:

Created on 2017-08-04 19:16 by nikratio, last changed 2018-01-22 20:19 by xgdomingo.

Messages (3)
msg299759 - (view) Author: Nikolaus Rath (nikratio) * Date: 2017-08-04 19:16
With a particularly atrocious network connection, I often get the following exception:

  File "/usr/lib/python3/dist-packages/dugong/", line 503, in connect
    self._sock = self.ssl_context.wrap_socket(self._sock, server_hostname=server_hostname)
  File "/usr/lib/python3.5/", line 385, in wrap_socket
  File "/usr/lib/python3.5/", line 760, in __init__
  File "/usr/lib/python3.5/", line 996, in do_handshake
  File "/usr/lib/python3.5/", line 641, in do_handshake
OSError: [Errno 0] Error

I don't think an error with errno == 0 should ever be raised by Python.
msg299766 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-08-05 01:49
It might help if you explained what “atrocities” are happening on your network. Is there a proxy or man-in-the-middle (or the remote peer) that shuts down TCP connections?

If so, perhaps this is similar to Issue 10808. From my memory, in that case an OS “recv” or “read” call returns zero to indicate a connection was shut down. Python and/or Open SSL correctly treats this as an error, but then assumes “errno” is valid. Perhaps Python should be raising SSLEOFError in this situation.

Maybe also check the “suppress_ragged_eofs” setting, but I think that only affects later stages, after the handshake succeeds.
msg299793 - (view) Author: Nikolaus Rath (nikratio) * Date: 2017-08-05 20:07
Regarding "atrocious connection": I wish I knew, but I have no control of the connection. All I can tell is that there are frequent disconnects, occasional latency spikes, my remote ip address seems to change frequently (while the apparent local one stays as-is, so presumably some NAT in between), temporary bandwidth drops, etc.
Date User Action Args
2018-01-22 20:19:49xgdomingosetnosy: + xgdomingo
2017-08-05 20:07:04nikratiosetmessages: + msg299793
2017-08-05 01:49:39martin.pantersetnosy: + martin.panter
messages: + msg299766
2017-08-04 19:16:41nikratiocreate