netdev - Re: [PATCH v4 net-next 08/13] tcp: accecn: retransmit SYN/ACK without AccECN option or non-AccECN SYN/ACK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <705f02b2-44c6-4012-a1f3-0040652acc36@redhat.com>
Date: Thu, 16 Oct 2025 11:13:58 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: chia-yu.chang@...ia-bell-labs.com, edumazet@...gle.com,
 linux-doc@...r.kernel.org, corbet@....net, horms@...nel.org,
 dsahern@...nel.org, kuniyu@...zon.com, bpf@...r.kernel.org,
 netdev@...r.kernel.org, dave.taht@...il.com, jhs@...atatu.com,
 kuba@...nel.org, stephen@...workplumber.org, xiyou.wangcong@...il.com,
 jiri@...nulli.us, davem@...emloft.net, andrew+netdev@...n.ch,
 donald.hunter@...il.com, ast@...erby.net, liuhangbin@...il.com,
 shuah@...nel.org, linux-kselftest@...r.kernel.org, ij@...nel.org,
 ncardwell@...gle.com, koen.de_schepper@...ia-bell-labs.com,
 g.white@...lelabs.com, ingemar.s.johansson@...csson.com,
 mirja.kuehlewind@...csson.com, cheshire@...le.com, rs.ietf@....at,
 Jason_Livingood@...cast.com, vidhi_goel@...le.com
Subject: Re: [PATCH v4 net-next 08/13] tcp: accecn: retransmit SYN/ACK without
 AccECN option or non-AccECN SYN/ACK

On 10/13/25 7:03 PM, chia-yu.chang@...ia-bell-labs.com wrote:
> From: Chia-Yu Chang <chia-yu.chang@...ia-bell-labs.com>
> 
> 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 <chia-yu.chang@...ia-bell-labs.com>
> ---
>  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