When do socket bind, if the connection domain is not equal to the bound address type, this will cause the stack-buffer-overflow.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
- NewReno congestion control algorithm is used to solve the problem
of network congestion breakdown. NewReno congestion control includes
slow start, collision avoidance, fast retransmission, and fast
recovery. The implementation refers to RFC6582 and RFC5681.
- In addition, we optimize the congestion algorithm. In the conflict
avoidance stage, the maximum congestion window max_cwnd is used to
limit the excessive growth of cwnd and prevent network jitter
caused by congestion. Maximum congestion window max_cwnd is updated
with the current congestion window cwnd and the update weight is
0.875 when an RTO timeout occurs.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
If TCP_FIN is received before the user calls accept, the later accept will
report an error, then the previously received data cannot be read.
operation flow:
tcp_server_listen -> tcp_client_connect -> tcp_client_send ->
tcp_client_close -> tcp_server_accept(fix this error) -> tcp_server_recv
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
We have a case that an http server gives out-of-ordered ACKs, and NuttX client makes `ofoseg`s with length 0, trying to rebuild / put them into `ofosegs` array, which is not intended (no available data and should be skipped). This breaks later logic and finally crashed in `tcp_ofoseg_bufsize` (`ofosegs[i].data` is `NULL`, which should never happen in normal logic).
Note:
- `iob_trimhead` won't return `NULL` when it's applying on normal IOB.
- Keep `dev->d_iob == NULL` to avoid `iob_trimhead` changed.
- `iob_free_chain` will do nothing when applied to `NULL`.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
According to RFC 2525, Section 2.17:
"When an application closes a connection in such a way that it can no longer read any received data, the TCP SHOULD, per section 4.2.2.13 of RFC 1122, send a RST if there is any unread received data, or if any new data is received."
When our TCP socket is closed (even when the thread has exited), the peer can keep sending data and NuttX keeps replying ACK (we've tried for ~12h). This is not a good behavior (also different from Linux), so send RST instead of ACK for data receiving in FIN_WAIT.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
The priorities for finding a network adapter are as follows:
1. if laddr is not ANY, use laddr to find device;
2. if laddr is ANY, and bound index is not 0, use bound index
to find device;
3. if laddr is ANY and no device is bound, use raddr to find
device.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
Receiving an ACK indicating TCP Window Update will not set ACKDATA flag (because tx_unacked is 0) in our TCP stack. Then this ACK won't let us send anything after receiving it, even if it updates snd_wnd. So we need to check whether we can send data immediately when our snd_wnd is updated (especially from 0), otherwise we will only send next data after timer expiry.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
NuttX kernel should not use the syscall functions, especially after
enabling CONFIG_SCHED_INSTRUMENTATION_SYSCALL, all system functions
will be traced to backend, which will impact system performance.
Signed-off-by: chao an <anchao@xiaomi.com>
Issue:
TCP rx buffer is freed after 4-way handshake with current design.
3 socket's rx buffer might be consumed during ffmpeg switch music procedure,
and this might cause IOB exhausted.
Solution:
free TCP rx buffer immediately in tcp_close to make sure IOB won't be
exhausted.
Signed-off-by: 梁超众 <liangchaozhong@xiaomi.com>
Signed-off-by: chao an <anchao@xiaomi.com>
This reverts commit fbe641a916.
This issue already fixed by below change:
| commit 715785245c
| Author: chao an <anchao@xiaomi.com>
| Date: Mon Jan 16 12:37:44 2023 +0800
|
| net/tcp: fix potential busy loop in tcp_send_buffered.c
|
| if the wrbuffer does not have enough space to send the rest of
| the data, then the send function will loop infinitely in nonblock
| mode, add send timeout check to avoid this issue.
|
| Signed-off-by: chao an <anchao@xiaomi.com>
Signed-off-by: chao an <anchao@xiaomi.com>
tcp_input:
If we didn't find an active connection that expected the packet,
If the SYN flag isn't set,
It is an old packet and we send a RST.
conn is NULL when this case
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
psock_tcp_send will enter busyloop state when no IOB keeps at unavailable state
when the socket is blocking socket and this will cause WDT.
According to socket's manpage, -1 should be returned while errno set to EAGAIN
if send/recv timeout was set.
Here's the description:
SO_RCVTIMEO and SO_SNDTIMEO
Specify the receiving or sending timeouts until reporting an error. The argument is a struct timeval. If an input or output function blocks for this period of time, and data has been sent or received, the return value of that function will be the amount of data transferred; if no data has been transferred and the timeout has been reached then -1 is returned with errno set to EAGAIN or EWOULDBLOCK, or EINPROGRESS (for connect(2)) just as if the socket was specified to be nonblocking. If the timeout is set to zero (the default) then the operation will never timeout. Timeouts only have effect for system calls that perform socket I/O (e.g., read(2), recvmsg(2), send(2), sendmsg(2)); timeouts have no effect for select(2), poll(2), epoll_wait(2), and so on.
Signed-off-by: liangchaozhong <liangchaozhong@xiaomi.com>
1. Remove tcp_txdrain() from close() to avoid indefinitely block
2. Send TCP_RST immediately if linger timeout
Signed-off-by: chao an <anchao@xiaomi.com>
Merge conflicts lead to code being placed in thre wrong place
The debug code should placed in tcp_send() not tcp_synack()
Signed-off-by: chao an <anchao@xiaomi.com>
if the wrbuffer does not have enough space to send the rest of
the data, then the send function will loop infinitely in nonblock
mode, add send timeout check to avoid this issue.
Signed-off-by: chao an <anchao@xiaomi.com>
Allocate the device buffer only if the protocol really need to send data.
not all protocols require the driver to prepare additional iob before
sending, especially UDP, each iob reserves l2/l3 header in advance
after prepare write buffer, net device could reuse this entry to send directly
Signed-off-by: chao an <anchao@xiaomi.com>
Fragmentation of network data will intensify iob consumption, if
the device receives a message storm of fragmented packets, the iob
cache will not be effectively used, this is not allowed on iot devices
since the resources of such devices are limited. Of course, this
also takes some disadvantages: data needs to be copied.
This option will brings some balance on resource-constrained devices,
enable this config to reduce the consumption of iob, the received iob
buffers will be merged into the contiguous iob chain.
Signed-off-by: chao an <anchao@xiaomi.com>
l3/l4 stack will decouple the reference of d_buf gradually, Only legacy
devices still retain d_buf support, new net devices will use d_iob
Signed-off-by: chao an <anchao@xiaomi.com>
