debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
urgent data needs to be treated as normal data when
CONFIG_NET_TCPURGDATA disable. some test sets will verify this
behavior, correct the processing logic.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
According rfc793 p69, from state SYN-RECEIVED to state TIME-WAIT, if the incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
Signed-off-by: wenquan1 <wenquan1@xiaomi.com>
According rfc793 p69, In SYN-RCVD state, if the incoming segment is not acceptable, an acknowledgment should be sent in reply (unless the RST bit is set):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
Signed-off-by: wenquan1 <wenquan1@xiaomi.com>
According RFC793,p72~p73 In states from ESTABLISHED to LASTACK:"If the ACK acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return"
Signed-off-by: wenquan1 <wenquan1@xiaomi.com>
notify the local waiting recv process; otherwise, after the peer TX
is closed, the wait of the recv process will continue to wait.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
shutdown should send TCP_FIN packet.
close should send TCP_RST packet when the data in readahead has not been
read and NEW_DATA has arrived.
send TCP_FIN packet when in other cases.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
the maximum retransmission interval allowed for car projects
cannot exceed 6 seconds, and allows for fixed retransmission intervals.
according to the previous algorithm, the retransmission interval
may be 0.5 * 2 ^ 4 = 8 seconds, which does not meet the requirements.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
CLOSE-WAIT - represents waiting for a connection termination request
from the local user.
TCP A TCP B
1. ESTABLISHED ESTABLISHED
2. (Close)
FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT
3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT
4. (Close)
TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK
5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED
6. (2 MSL)
CLOSED
in the current state, we can continue to send data until the user
calls shutdown or close, then directly enter the TCP_LAST_ACK state
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
When triggering TCP retransmission through a timer, conn->unacked_q will save more packets, which may result in sndseq being equal to ackseq. Previous implementations may cause conn->nrtx to not be cleared, leading to an increase in conn->rto errors and a longer timer time
Signed-off-by: wangchen <wangchen41@xiaomi.com>
when accept conn receives TCP_RESET, only accept conn itself should handle
the event, and there is no need to notify the listening conn. otherwise,
the server's poll will return with POLLERR and POLLHUP. this may cause
some applications to execute incorrect logic in the future.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
we will drop packet when tcp_close_eventhandler
is register and invoke by tcp_input. then we will always early return and
never stop, the peer will only close the connection if we send reset packet.
precondition:
close -> register tcp_close_eventhandler;
tcp_input -> tcp_callback(TCP_NEWDATA) -> devif_conn_event -> tcp_close_eventhandler
-> flags &= ~TCP_NEWDATA -> NOT entry tcp_data_event -> conn->recvreq NOT increase
old flow:
tcp_input -> tcp->seqno greater than conn->rcvseq -> tcp_send(TCP_ACK)
with this patch:
tcp_input -> tcp->seqno greater than conn->rcvseq -> !TCP_ESTABLISHED
-> case TCP_FIN_WAIT_1 -> dev->d_len greater than 0 -> tcp_reset
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
According to RFC793, Section 3.4, Page 33. In the SYN_SENT state, if receive a ACK without the SYN, we should reset the connection and retransmit the SYN.
Signed-off-by: liqinhui <liqinhui@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
when tcp socket stays in TCP_FIN_WAIT_1 or TCP_FIN_WAIT_2,not actively calling tcp_close_eventhandler,can reuslt in some TCP socket being set to a closed state,but nofosegs are not directly released,leading to IOB resource leakage.
Signed-off-by: wangchen <wangchen41@xiaomi.com>
1. Tcp will idle loop by tcp_timer when have no packet to send. This will cause low-power devices to be frequently woken up.
2. We should add tcp_timer when timer has been canceled and have packet to send.
Signed-off-by: meijian <meijian@xiaomi.com>
The Bluetooth network on N62 does not retransmit packet, so no packet
retransmition if we drop one, we will drop packet when tcp_close_eventhandler
is register and invoke by tcp_input. then we will always early return and
never stop, the peer will only close the connection if we send reset packet.
precondition:
close -> register tcp_close_eventhandler;
tcp_input -> tcp_callback(TCP_NEWDATA) -> devif_conn_event -> tcp_close_eventhandler
-> flags &= ~TCP_NEWDATA -> NOT entry tcp_data_event -> conn->recvreq NOT increase
old flow:
tcp_input -> tcp->seqno greater than conn->rcvseq -> tcp_send(TCP_ACK)
with this patch:
tcp_input -> tcp->seqno greater than conn->rcvseq -> !TCP_ESTABLISHED
-> case TCP_FIN_WAIT_1 -> dev->d_len greater than 0 -> tcp_reset
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
The previous iob_trimhead added dev->iob->io_offset, so if the
input frame is not merged into the ofo segment, we need to reset
dev->iob->io_offset so that the subsequent tcp_send can properly
assemble packets.
Signed-off-by: zhanghongyu <zhanghongyu@xiaomi.com>
After the sack is enabled and the ofosegs has gap, tcp cannot update the
tx_unacked, so the peer received packets are retransmitted after the
timer timeout.
So update tx_unacked first.
Signed-off-by: zhanghongyu <zhanghongyu@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>
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>
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>
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>
