Bug#1136459: openssh-server: [regression] stopped accepting connections over the WLAN

Hi Colin,

> I think it would work best if you could take this upstream yourself.

if they let me=E2=80=A6

> 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.

Right.

> 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 believe so, yes.

> 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,

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=E2=80=99m 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=E2=80=99ve not found an option for that (and no filtering is configured),
so the firmware is likely buggy, but with an uninterested vendor, there
isn=E2=80=99t 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=E2=80=A50xBF, 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=E2=80=99ll 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=E2=80=99t have to do long timeouts),
  and fall back to a different QoS marker if they don=E2=80=99t 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=E2=80=99s also some 0x00 in the trace where I=E2=80=99d expect
0x02 for the same reason.

Getting that to work with both old and new clients=E2=80=A6 will be
interesting. Perhaps, if it=E2=80=99s 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
--=20
Thorsten Glaser
Linux / Unix Developer
Tel.: +49 160 91168501
E-Mail: [email protected]

B1 Systems GmbH
Osterfeldstra=C3=9Fe 7 / 85088 Vohburg / https://www.b1-systems.de/
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537