Web lists-archives.com

Re: Bug#926229: New QoS defaults break systems running on VMWare




On Tue, Apr 02, 2019 at 12:27:47PM +0200, Christian Ehrhardt wrote:
> This is related, but not the same as [1] and about the new defaults in
> regard to QoS.
> Due to upstream change [2] the new defaults now mean that ssh is
> broken if connecting to (or through) a system running on VMWare.
> 
> More details can be found on the Ubuntu bug [3] where this was
> reported initially.
> As [1] I'd ask for a revert of that change until iptables (for [1]),
> vmware (for this bug) and others if identified later will be fixed
> (the actual issue is in those components, so sooner or later this
> should no more be needed to be reverted).
> 
> Final FYI - Fedora [4] took the decision to force the issue by
> sticking with the new default.
> After all the "workaround" is user controllable being:
> 
> Configure your client to use the old defaults permanently in
> => /etc/ssh/ssh_config
> Host *
>     IPQoS lowdelay throughput
> # You might want to limit to your VMware based systems
> 
> Or per command via:
>  $ ssh IPQoS="latency throughput" user@host

If it were just the VMware issue, then my inclination would be to leave
OpenSSH as it is: it's proprietary software and the only leverage we
have to get them to fix it is to have their customers complaining.
However, the iptables issue in #923879 seems thornier and it's outside
my field of expertise.

I'm slightly leaning towards reverting this on a temporary basis for
buster, but CCing debian-devel: does anyone have opinions on this?

> I thought it is better to file it to make you aware of this extra
> context to [1] so that you can consider those two requests to revert
> [2] together.
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923879
> [2]: https://anongit.mindrot.org/openssh.git/commit/?id=5ee8448ad7c306f05a9f56769f95336a8269f379
> [3]: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1822370
> [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1624437#c8

Thanks,

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]