On 10/13/25 7:03 PM, [email protected] wrote:
> From: Chia-Yu Chang <[email protected]>
>
> If the TCP Server has not received an ACK to acknowledge its SYN/ACK
> after the normal TCP timeout or it receives a second SYN with a
> request for AccECN support, then either the SYN/ACK might just have
> been lost, e.g. due to congestion, or a middlebox might be blocking
> AccECN Options. To expedite connection setup in deployment scenarios
> where AccECN path traversal might be problematic, the TCP Server SHOULD
> retransmit the SYN/ACK, but with no AccECN Option.
>
> If this retransmission times out, to expedite connection setup, the TCP
> Server SHOULD retransmit the SYN/ACK with (AE,CWR,ECE) = (0,0,0)
> and no AccECN Option, but it remains in AccECN feedback mode.
>
> This follows Section 3.2.3.2.2 of AccECN spec (RFC9768).
>
> Signed-off-by: Chia-Yu Chang <[email protected]>
> ---
> include/net/tcp_ecn.h | 14 ++++++++++----
> net/ipv4/tcp_output.c | 2 +-
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/tcp_ecn.h b/include/net/tcp_ecn.h
> index c66f0d944e1c..97a3a7f36aff 100644
> --- a/include/net/tcp_ecn.h
> +++ b/include/net/tcp_ecn.h
> @@ -651,10 +651,16 @@ static inline void tcp_ecn_clear_syn(struct sock *sk,
> struct sk_buff *skb)
> static inline void
> tcp_ecn_make_synack(const struct request_sock *req, struct tcphdr *th)
> {
> - if (tcp_rsk(req)->accecn_ok)
> - tcp_accecn_echo_syn_ect(th, tcp_rsk(req)->syn_ect_rcv);
> - else if (inet_rsk(req)->ecn_ok)
> - th->ece = 1;
> + if (req->num_retrans < 1 || req->num_timeout < 1) {
I think the above condition does not match the commit message. Should be:
if (!req->num_retrans && !req->num_timeout) {
/P
