-
Notifications
You must be signed in to change notification settings - Fork 218
Guru Meditation Error during socket.connect() #204
Comments
(yes, I'll have a look at this but I'm adding it here so I don't forget) |
Well, that explains recent problems I've had with WLAN. Side Note, even |
It looks like the ctrl-C that you press during connect() is being buffered. Then the EHOSTUNREACH exception is being raised, but the ctrl-C is still pending. The ctrl-C is then raised in some strange location which leads to the crash. Apart from this being a bug (which may be difficult to track down the reason for), to fix connect() so that you can do ctrl-C to break out of it would require setting the socket to be non-blocking at the start, then do a loop polling for the connect() to complete. In that loop you can check for ctrl-C explicitly (by calling mp_handle_pending()). Note: this stuff is already handled in esp8266 because it uses extmod/modlwip.c which wraps the lwIP stack at a lower level. And I don't think it's possible to hook into the esp32 lwIP stack at such a level, because it's probably not exposed and also there are multi-core issues to consider. |
Same behaviour in v1.9.2-279-g090b6b80 @dpgeorge yeah, I was thinking that, we do similar things elsewhere in that library to "fake" timeouts. |
All of the other socket stuff implements blocking/timeout with a loop, for this same reason. I think connect doesn't do this, because it doesn't seem LWIP allows you to set the connect timeout. In #define SO_CONTIMEO 0x1009 /* Unimplemented: connect timeout */ ... and it's not implemented in the API, either. =( |
Looks like we should be able to do something along these lines:
https://github.com/dreamcat4/lwip/blob/master/contrib/apps/socket_examples/socket_examples.c
* Do a non-blocking connect
* Get an EINPROGRESS
* Loop, doing a select waiting for the socket to be writeable
* If we get a Ctrl-C, process it.
I'll try and get something in for this ASAP.
|
If you try to socket.connect() to an unreachable TCP/IP address it eventually (~15 seconds) returns with
OSError: [Errno 113] EHOSTUNREACH
However, if you Ctrl-C during this time, the exception is immediately followed by a crash:
This occurs with network.WLAN() or the new network.LAN() adaptor.
The text was updated successfully, but these errors were encountered: