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).
Set link state correctly in lwIP for interfaces that support
the NETOPT_LINK option. Interfaces that do not support it
(like tap for native arch) remain up all the time.
Netdevs that support NETOPT_LINK but do not send NETDEV_EVENT_LINK_UP/DOWN
events will end up with a mismatched link state - but DHCP would
already not start for them either.
Use netifapi to signal lwIP to do the work in its own thread.
Lists state, link type, v4/v6 addresses.
Currently read-only.
Using lwIP debug system to print addresses, to limit dependencies
and work with dual stack setup. Most other code seems to only
allow either v4 or v6 networking. For that to compile I
had to change the `SZT_F` format string due to this error:
```
error: format '%lu' expects argument of type 'long unsigned int',
but argument 2 has type 'size_t {aka unsigned int}'
```
Switching to the lwIP default format string here.
Outputs the following on my ESP32 board with Ethernet,
when both v4 and v6 are enabled in examples/paho-mqtt:
```
> ifconfig
Iface ET0 HWaddr: 24:0a:c4:e6:0e:9f Link: up State: up
Link type: wired
inet addr: 10.4.4.81 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9f scope: link
inet6 addr: 2001:db8:1000:0:260a:c4ff:fee6:e9f scope: global
Iface ET1 HWaddr: 24:0a:c4:e6:0e:9c Link: up State: up
Link type: wireless
inet addr: 10.4.4.82 mask: 255.255.254.0 gw: 10.4.4.1
inet6 addr: fe80:0:0:0:260a:c4ff:fee6:e9c scope: link
inet6 addr: 2001:db8:1000:0:260a:c4ff:fee6:e9c scope: global
>
```
With PR #14349 the double stack mode for lwIP was activated. The ATWINC15x0 driver was provided before the changes in PR #14349 but merged after that. Therefore, the changes for the driver were not taken into account anymore and have to be applied accordingly.
IP4_ADDR_ANY is a generic address of type IPv4 when lwIP is compiled
with both IPv4 and IPv6, so we need to extract the `ip4_addr_t`
component when using with `netif_add()` as that is the expected type.
