I’ve got this trixie system, updated to latest everything earlier,
and I cannot connect to it over the WLAN from a bullseye system
any more. This worked very recently.

I ran /usr/sbin/sshd -ddddde server-side and ssh -vvvvv client-side
to test, and it hangs at:

[…]
debug1: sshd-auth version OpenSSH_10.0, OpenSSL 3.5.6 7 Apr 2026
debug2: fd 5 is TCP_NODELAY [preauth]
debug3: set_sock_tos: set socket 5 IP_TOS 0xb8 [preauth]
debug3: server_process_channel_timeouts: setting 0 timeouts [preauth]
debug3: channel_clear_timeouts: clearing [preauth]
debug3: fd 5 is O_NONBLOCK [preauth]
debug3: ssh_sandbox_init: preparing seccomp filter sandbox [preauth]
debug3: privsep user:group 995:65534 [preauth]
debug1: permanently_set_uid: 995/65534 [preauth]
debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth]
debug3: ssh_sandbox_child: attaching seccomp filter program [preauth]
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ssh-rsa [preauth]
debug3: send packet: type 20 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]

The client hangs after listing all the identity files and showing
the local version string as debug1.

ssh-ing to localhost works.

It’s not an MTU problem, 1500 byte DF ping packets go through.

If I run the sever as /usr/sbin/sshd -ddddde -o IPQoS=throughput
the connection succeeds.

For the sake of completeness:

/usr/sbin/sshd -ddddde -o IPQoS=ef	hangs
/usr/sbin/sshd -ddddde -o IPQoS=le	works
/usr/sbin/sshd -ddddde -o IPQoS=none	works
(do I need to test more?)

Server hangs on a FritzBox 7430 (OS 07.31 up-to-date) which is
meshed with a FritzBox 7330 (OS 06.56 up-to-date). They have
isolation disabled, and as far as I can tell, no filtering.

/usr/sbin/sshd -ddddde -o IPQoS='lowdelay throughput'
also works (isn’t that the pre-1:10.0p1-7+deb13u3 setting?).

bye,
//Thorsten

Dixi quod…

ssh’ing out also fails unless -o IPQoS='lowdelay throughput'
so it also affects the client.

I then ran a test which TC octets pass through, by cloning
https://github.com/mirabilos/ECN-Bits (an earlier project),
'cd c && make', then:

$ ./server/server 11111

and:

$ i=-1; while (( ++i < 256 )); do ./client/client 192.168.1.5 11111 $i; done

The result is that the Fritzboxen do not generally drop packets
with any TC octet (my first 0x49 didn’t pass, but it’s UDP, and
on retry, it worked).

However, if I start the server as…

$ ./server/server +0xB8 11111

(meaning it will (try to) respond to each incoming packet with
TC 0xB8‥0xBB), then no replies are registred at the client. I’m
not sure whether this is something done by Linux itself or a
device after it.

Reversing the construct from above, i.e. the trixie system sending…
0x00‥0x9F, 0xC0‥0xFF pass, i.e. 0xA0‥0xBF are dropped, which is
bit pattern 001xxx.xx (ToS.ECN), which corresponds to precedence 1
in the old model, or in DSCP, decimal 8‥15, which Wikipedia’s list
shows as CS1, ?, AF11, ?, AF12, ?, AF13, ?.

Unfortunately, I’m unable to get either of the laptops to switch
APs (sudo iwconfig wlan0 ap …), but I did get an iwlwifi crash on
attempting that… so I cannot test changing Fritzboxen atm.

Gruß
//Thorsten

That being said, I managed to take a pcap dump on¹ the 7330 (client).

What I see there:

1. c→s TC=00 tcp syn/ecn/cwr
2. c←s TC=00 tcp syn/ack/ecn
3. c→s TC=00 tcp ack
4. c→s TC=02 ssh version+crlf
5. c←s TC=00 tcp ack, no payload
and a few seconds later c→s fin/ack, c←s fin/ack, when I pressed ^C.

When I do a pcap dump on the 7430 (server), I see lots more, with TC=B8.

So it seems like certain network devices default to blocking packets
with the new default traffic class octet, which I think you’ll want
to take upstream.

On my side, I’ll try to contact AVM support, but since they got bought,
unsure whether they will do anything than to tell me to buy a newer
device (it’s not even mine so…).

① https://linuxundich.de/gnu-linux/netzwerk-traffic-direkt-mit-der-fritzbox-aufzeichnen-und-mit-wireshark-auswerten/
  ⇒ 192.168.1.2/html/capture.html (hidden page)

Gruß
//Thorsten

This is especially important as it can cause lock-out scenarios.

From B to A, I can do ssh -o IPQoS=… and get a working connection.
But in the other direction, I can do nothing, as the SSH client
and server cannot do IPQoS negotiation as even the initial handshake
(server sends its version string to the client) already uses the
problematic traffic class.

Thanks,
//Thorsten

I think it would work best if you could take this upstream yourself.
Since I have no access to your hardware, when upstream ask for extra
debugging information, I'd end up just acting as a glorified relay,
which I'm not very good at.

Upstream told me that they've had a total of two reports of problems
with the new IPQoS settings, so I expect they'd be interested in
additional reports of regressions.

I've CCed one of the main authors of these changes in case they can spot
anything that would come down to a bad backport on my part; Job, see
https://bugs.debian.org/1136459 for context.  Thorsten, if you could try
the version currently in testing (or perhaps also the version in
unstable), that would help to exclude problems caused by possible bad
backports.

Thanks,

Hi Colin,

if they let me…

Right.

I believe so, yes.

Thanks, but from my testing with UDP packets, it *seems* that one of
the FritzBox devices is at fault, and OpenSSH only as much in that
they changed the default. Unfortunately, AVM support indeed only wants
to sell me (I’m not even the owner) a newer model.

Meanwhile the other laptop hopped to a different AP MAC by itself,
so it even works now, and it seems to apply to incoming packets only.
I’ve not found an option for that (and no filtering is configured),
so the firmware is likely buggy, but with an uninterested vendor, there
isn’t much we can do.

Job, the problem is that such plastic boxen, doing DSL, access point,
even WLAN repeater, are rather widespread in Europe, and if some of
these block IP packets with a traffic class of 0xA0‥0xBF, in which
the new default QoS falls, then the users have a serious lock-out
problem, in situations where they cannot override anything (if the
SSH server uses the new QoS bits so a response does not even arrive).

This *could* be mitigated by something like:
- do the SSH handshake without setting the new IPQoS
- then negotiate somehow, perhaps with a new protocol extension,
  that you’ll be trying to set QoS to a certain value, send a
  packet in both directions with that set and another immediately
  after without it set (so you don’t have to do long timeouts),
  and fall back to a different QoS marker if they don’t arrive

(at least in the case when it is not explicitly given)

I also noticed that the new default sends out with 0xB8, not
0xBA, which I would have expected given I set this system to
use ECN by default (the DSCP is the same but 0xBA has ECT(0)
set). There’s also some 0x00 in the trace where I’d expect
0x02 for the same reason.

Getting that to work with both old and new clients… will be
interesting. Perhaps, if it’s going to need an extension anyway,
it could even test a bunch of them (ideally, both the interactive
and bulk DSCP codepoints with all four ECN variants, or at least
no ECN, ECT(0) and ECN CE; ECT(1) is likely to be L4S at some
point and needs explicit enabling).

bye,
//Thorsten