-
-
Notifications
You must be signed in to change notification settings - Fork 7.7k
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
esp32/modsocket: Handle poll of a closed socket. #5788
Conversation
This gets tests/extmod/uselect_poll_basic.py working on the esp32.
Merged in bf4fb16 |
This PR has changed the error code returned when connecting to a port that has no listener from the correct 111/ECONNREFUSED to an incorrect 104/ERESET. I.e., connect to some random port on some server and now you get a 104, previously you got the correct 111. |
I'm not sure it was this commit that did that. Going back to the commit just before this one it looks like the same behaviour is there, that it raises The test I used was: # test that socket.connect() has correct behaviour connecting to a port that has no listener
try:
import usocket as socket, uselect as select, uerrno as errno
except:
import socket, select, errno
PORT_NO_LISTNER = 81
def test(peer_addr):
s = socket.socket()
try:
s.connect(peer_addr)
except OSError as er:
print("OSError ECONNREFUSED:", er.args[0] - errno.ECONNREFUSED)
if __name__ == "__main__":
test(socket.getaddrinfo('micropython.org', PORT_NO_LISTNER)[0][-1]) This works correctly on CPython and micropython unix. It doesn't work on stm32 or esp32 (an probably also esp8266), instead it returns 104 (not 111). It looks like this is due to how lwIP handles the refused connection. |
Yup, my bad. I know my test case passed but I obviously got mixed-up about where it passed :-(. My apologies for the wild goose chase. I did work on your test case a little more to test non-blocking sockets, since that's what uasyncio streams use:
Sample runs on CPython, linux MP, and esp32:
I realize you need a slightly different output format for the regression tests. |
Do you consider this something which should be fixed? It may not be possible to fix if lwip cannot distinguish between errno 104 and 111, but an option would be to convert the errno's for the situations where we know they should be converted. |
Thanks for asking. micropython/ports/esp32/lwip_err.c Lines 43 to 63 in 577659a
I don't see a "connection refused". For blocking sockets we could map reset->refused. For non-blocking we could keep track of bytes transferred and if zero do that mapping as well. Overall, I would say "got bigger fish to fry" and leave it as-is. I'll add a little comment to socket_connect for the future... |
What is the intention of the send test in the above script? On PYBD (using modlwip.c) the send actually goes through... (probably that's a bug but not sure if its' in lwip or elsewhere). |
I've evolved this test a lot further in one of the later PRs. The intention was to test that a send after a non-blocking connect return an appropriate error code. The new test is in #5825: https://github.com/micropython/micropython/blob/3c67ef8ea9a9e934be4e690d70d243688ebaa6db/tests/net_hosted/connect_nonblock.py |
I should note that I've resolved most of the error code issues in the PRs queued, at least on the platforms I've been able to test. It's not all 100% to standard but where it's not I don't think it's reasonably possible. |
Ok, then let's leave this issue here as-is, to be resolved later in those PRs. |
…n-main Translations update from Hosted Weblate
This gets tests/extmod/uselect_poll_basic.py working on the esp32.
@tve FYI, this should fix the issue you found with
uasyncio
and write after closing the connection.