[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] lwip_recvfrom(sock == 0)
From: |
address@hidden |
Subject: |
Re: [lwip-devel] lwip_recvfrom(sock == 0) |
Date: |
Fri, 25 Sep 2020 09:30:03 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
Am 24.09.2020 um 18:05 schrieb Gisle Vanem:
> Hello list.
>
> I have patched MicroPython [1] with LwIP support on Windows.
> And running some tcp/ip related test shows a funny
> behaviour in LwIP. E.g. from:
>
> https://github.com/micropython/micropython/blob/master/tests/extmod/usocket_tcp_basic.py
>
> # recv() on a fresh socket should raise ENOTCONN
> s = socket.socket()
> try:
> s.recv(1)
> except OSError as er:
>
> print("ENOTCONN:", er.args[0] == errno.ENOTCONN)
>
> The trace in LwIP shows:
> src/api/sockets.c(1754): lwip_socket(PF_INET, SOCK_STREAM, 0) = 0
> src/api/sockets.c(1243): lwip_recvfrom(0, 0E88A030, 1, 0x0, ..)
> src/api/sockets.c(976): lwip_recv_tcp: top while sock->lastdata=00000000
>
> Now the MicroPython test hangs forever. Nothing happens
> with this socket 0. It's unconnected, so how could this socket
> ever receive a single byte?
It should indeed not wait here, but return an error. Would you mind
adding a bug in our savannah bugtracker to ensure this does not get
forgotten?
>
> Using the same .py-test in the real CPython 3.6, it immediately
> returns the expected:
> py -3 extmod\usocket_tcp_basic.py
> ENOTCONN: True
>
> Could it be some of my 'LWIP_x' options are messed up?
Hmm, while this could change with options, it still should not behave
like you saw.
Regards,
Simon
>
> [1] https://github.com/micropython/micropython