Bug#1136459: openssh-server: [regression] stopped accepting connections over the WLAN
On Thu, May 14, 2026 at 01:44:04AM +0200, Thorsten Glaser wrote: 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. 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. 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, -- Colin Watson (he/him) [[email protected]]
Bug#1136459: openssh-server: [regression] stopped accepting connections over the WLAN
>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. 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 -- Thorsten Glaser Linux / Unix Developer Tel.: +49 160 91168501 E-Mail: [email protected] B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de/ GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
Bug#1136459: openssh-server: [regression] stopped accepting connections over the WLAN
>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. 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 -- Thorsten Glaser Linux / Unix Developer Tel.: +49 160 91168501 E-Mail: [email protected] B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de/ GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
Bug#1136459: openssh-server: [regression] stopped accepting connections over the WLAN
Dixi quod… >/usr/sbin/sshd -de -o IPQoS='lowdelay throughput' >also works (isn’t that the pre-1:10.0p1-7+deb13u3 setting?). 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 1 and: $ i=-1; while (( ++i < 256 )); do ./client/client 192.168.1.5 1 $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 1 (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 -- Thorsten Glaser Linux / Unix Developer Tel.: +49 160 91168501 E-Mail: [email protected] B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de/ GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
Bug#1136459: openssh-server: [regression] stopped accepting connections over the WLAN
On Thu, 14 May 2026, Thorsten Glaser wrote: >If I run the sever as /usr/sbin/sshd -de -o IPQoS=throughput >the connection succeeds. > >For the sake of completeness: > >/usr/sbin/sshd -de -o IPQoS=ef hangs >/usr/sbin/sshd -de -o IPQoS=le works >/usr/sbin/sshd -de -o IPQoS=none works >(do I need to test more?) /usr/sbin/sshd -de -o IPQoS='lowdelay throughput' also works (isn’t that the pre-1:10.0p1-7+deb13u3 setting?). bye, //Thorsten -- Thorsten Glaser Linux / Unix Developer Tel.: +49 160 91168501 E-Mail: [email protected] B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de/ GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
Bug#1136459: openssh-server: [regression] stopped accepting connections over the WLAN
Package: openssh-server Version: 1:10.0p1-7+deb13u4 Severity: important X-Debbugs-Cc: [email protected], [email protected] 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 -de server-side and ssh -v 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 -de -o IPQoS=throughput the connection succeeds. For the sake of completeness: /usr/sbin/sshd -de -o IPQoS=ef hangs /usr/sbin/sshd -de -o IPQoS=le works /usr/sbin/sshd -de -o IPQoS=noneworks (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. -- System Information: Debian Release: 13.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.86+deb13-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) Versions of packages openssh-server depends on: ii debconf [debconf-2.0] 1.5.91 ii init-system-helpers 1.69~deb13u1 ii libaudit1 1:4.0.2-2+b2 ii libc6 2.41-12+deb13u3 ii libcom-err2 1.47.2-3+b11 ii libcrypt1 1:4.4.38-1 ii libgssapi-krb5-21.21.3-5 ii libkrb5-3 1.21.3-5 ii libpam-modules 1.7.0-5 ii libpam-runtime 1.7.0-5 ii libpam0g1.7.0-5 ii libselinux1 3.8.1-1 ii libssl3t64 3.5.6-1~deb13u1 ii libwrap07.6.q-36 ii libwtmpdb0 0.73.0-3+deb13u1 ii openssh-client 1:10.0p1-7+deb13u4 ii openssh-sftp-server 1:10.0p1-7+deb13u4 ii procps 2:4.0.4-9 ii runit-helper2.16.4 ii systemd-standalone-sysusers [systemd-sysusers] 257.13-1~deb13u1 ii sysvinit-utils [lsb-base] 3.14-4 ii ucf 3.0052 ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1 Versions of packages openssh-server recommends: ii logind-considered-harmful [logind] 89 pn ncurses-term ii xauth 1:1.1.2-1.1 Versions of packages openssh-server suggests: ii kwalletcli [ssh-askpass] 3.03-1+b1 ii molly-guard 0.8.5 pn monkeysphere ii ssh-askpass 1:1.2.4.1-16+b1 pn ufw -- debconf information excluded
