error:
--------------------------------------
netdev/netdev_lladdrsize.c: In function ‘netdev_lladdrsize’:
netdev/netdev_lladdrsize.c:148:7: error: duplicate case value
148 | case NET_LL_BLUETOOTH:
| ^~~~
netdev/netdev_lladdrsize.c:119:7: note: previously used here
119 | case NET_LL_BLUETOOTH:
| ^~~~
BLUETOOTH_HDRLEN has been removed by:
---------------------------------
|commit aae0d92598b14a6f760e7e7baf191b59387d539c
|Author: Gregory Nutt <gnutt@nuttx.org>
|Date: Sun Apr 1 15:21:58 2018 -0600
|
|wireless/bluetooth and net/bluetooth:
|
|Clean up some garbage left in Kconfig file that broke 'make menuconfig'.
|Clean up some craziness with Bluetooth frame length definitions.
Signed-off-by: chao.an <anchao@xiaomi.com>
sixlowpan/sixlowpan_input.c: In function ‘sixlowpan_dispatch’:
sixlowpan/sixlowpan_input.c:629:3: warning: implicit declaration of function ‘pkt_input’;
did you mean ‘ipv6_input’? [-Wimplicit-function-declaration]
629 | pkt_input(&radio->r_dev);
| ^~~~~~~~~
| ipv6_input
Signed-off-by: chao.an <anchao@xiaomi.com>
and removed two tcp_send_txnotify() calls from tcp_sendfile (they are not needed anymore).
As a result, the TX throughput of both the tcp_send_buffered and tcp_send_unbuffered
is significantly boosted in case of TUN/TAP network device.
According to RFC 5681 (3.2) the TCP Fast Retransmit algorithm should start
if the threshold of 3 duplicate ACKs is reached.
Thus the threshold should be a constant, not an integer option.
(conn->sndseq was updated in multiple places that was unreasonable and complicated).
This optimization is the same as it was done for tcp_send_unbuffered.
Wrong unackseq calculation locked conn->tx_unacked at non-zero values
even if all ACKs were received.
This issue is the same as it was with tcp_send_unbuffered.
Do not use pvconn argument to get the TCP connection pointer because pvconn is
normally NULL for some events like NETDEV_DOWN. Instead, the TCP connection pointer
can be reliably obtained from the corresponding TCP socket.
Both the snd_ackcb and snd_datacb callbacks were created and destroyed right after sending every packet.
Whenever TCP_REXMIT event occurred due to TCP send timeout, TCP_REXMIT was ignored because
snd_ackcb callback had been destroyed by the time.
The issue is fixed as follows:
- both the snd_ackcb and snd_datacb callbacks are combined into one snd_cb callback
(the same way as in tcp_send_unbuffered.c).
- the snd_cb callback lives until all requested data (via sendfile) is sent,
including all ACKs and possible retransmissions.
As a positive side effect of the code optimization / fix, sendfile TCP payload throughput is increased.
tcp_sendfile() reads data directly from a file and does not use NET_TCP_WRITE_BUFFERS data flow
even if CONFIG_NET_TCP_WRITE_BUFFERS option is enabled.
Despite this, tcp_sendfile relied on NET_TCP_WRITE_BUFFERS specific flow control variables that
were idle during sendfile operation. Thus it was a total inconsistency.
E.g. because of the issue, TCP socket used by sendfile() operation never issued
FIN packet on close() command, and the TCP connection hung up.
As a result of the fix, simultaneously enabled CONFIG_NET_TCP_WRITE_BUFFERS and
CONFIG_NET_SENDFILE options can coexist.
