Without initializing async_cb to NULL it might be a value != NULL,
which leads to sock->async_cb.gen() being called mistakenly in _netconn_cb.
gnrc_sock already does it with "reg->async_cb.generic = NULL;"
Otherwise if the cable is connected at boot the immediate NETDEV_EVENT_ISR
event signaling connection will not trigger the isr, and the netdev will not
clear its pending event.
This explains why the connect/rx event clash seen in "esp32/eth: Don't
overwrite queued event with RX packet" (95196fb7e4) only happened
with lwIP.
Now on my ESP32 board with Ethernet the issue was the opposite (since IDF
upgrade), the stuck connected event blocked receive from working. After
this change 95196fb7e4 can be reverted since even early events are
consumed properly.
This mostly converts switch statements from double indent style to
Linux kernel style, as required per the coding convention.
From the C compiler perspective, this is a whitespace only change.
If DEVELHELP is not set `LOCK_TCPIP_CORE()`/`UNLOCK_TCPIP_CORE()`
are not defined, leading to a build failure.
Defining them to no-op leads to a run-time segmentation fault, so
better always use those functions.
When reading from the socket with `sock_tcp_read()` it would only return
data from at most one internal connection buffer, even if the buffer
passed to `sock_tcp_read()` is larger and there is more data available
in the connection. This patch makes `sock_tcp_read` process all the
available data so long as there's more data to read available
immediately.
lwip receives network buffers that are made available to lwip_sock_tcp
calling `netconn_recv_tcp_pbuf`. The size of these buffers depends on
the size of the network packets. An application calling `sock_tcp_read`
can pass any arbitrary buffer size to read (copy) from these internal
network buffers, which may be smaller. lwip_sock_tcp keeps around the
last network buffer (`struct pbuf last_buf`) and the offset into this
buffer already consumed by the application (`last_offset`).
However, when multiple application reads from the same `pbuf` buffer
occur, the `last_offset` must be updated incrementing it. The code had
a bug that would work only when `last_offset` was either 0 (no previous
partial read) or when the current read was consuming all the remaining
data (when `buf_len == copylen`).
This patch fixes the issue an allows multiple reads from the same
buffer.
Netifs without link status support will keep sending discover
messages with increasing time between.
Netifs that support link status will wait for the link to be up,
and then start sending.
Netifs that support link status but send no link status events
will continue to not work (unless link status is up from the
first check when setting it up).
