On 7/30/25 22:34, Damien Miller wrote:
On Wed, 30 Jul 2025, Job Snijders wrote:
https://lpc.events/event/11/contributions/943/attachments/901/1780/inet_tos_lpc2021.pdf
In relationship to commit 5ee8448a, I was disappointed to discover that
the Linux ecosystem appears to have undone efforts to improve the
interactive experience versus fixing the root cause.
I guess you're referring to this?
https://salsa.debian.org/ssh-team/openssh/-/blob/master/debian/patches/revert-ipqos-defaults.patch?ref_type=heads
If so, then yeah - getting that sorted out would be good. At the very
least IMO Debian should fix this by defaulting to IPQoS=none rather
than a totally-broken legacy TOS value.
That would be it and how I found out there was some issue with the IPQoS
in my test case. Personally, it would be a lot easier to test this in a
real world environment but establishing something that would force IPv4
instead of IPv6 is a bit tricky considering there is a 250ms pause*
between the connection attempts. Fedora does not do this and I'm kind of
hoping Dmitry will weigh in on this. I'd love to understand more fully
why maintainers make some of the decisions that they do.
Either way, I'm not sure implementing RFC 8305 is going to be useful in
most environments but it's an issue for some of the people I'm
supporting. It's also giving me something to do when I need a break from
writing grant proposals to the NSF that will likely end up being
rejected because their budget is being decimated. Sigh.
Chris
(* The exact delay is a runtime option but it's still difficult to find
that specific environment and having access to system I can make ssh
attempts against).
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev