While openssh-client seems to properly switch between the lowdelay/throughput QoS classes depending on whether the session is interactive or not, the new IPQoS option seems to have absolutely no effect: % ssh -vvvo 'IPQoS ef' -4 -Snone vera 2>&1 >/dev/null | egrep tos || echo no match debug3: packet_set_tos: set IP_TOS 0x10 ^D % ssh -vvvo 'IPQoS ef' -4 -Snone vera true 2>&1 >/dev/null | egrep tos || echo no match debug3: packet_set_tos: set IP_TOS 0x08 In both cases, the TOS value should be 0x2e (class ef). Using the hex number does not work either: % ssh -vvvo 'IPQoS 0x2e' -4 -Snone vera 2>&1 >/dev/null | egrep tos || echo no match debug3: packet_set_tos: set IP_TOS 0x10 ^D % ssh -vvvo 'IPQoS 0x2e' -4 -Snone vera true 2>&1 >/dev/null | egrep tos || echo no match debug3: packet_set_tos: set IP_TOS 0x08 I have also verified the actual packets emitted using tcpdump on the next hop. Exactly the same behaviour can be observed with IPv6 after upgrading to 1:5.9p1-7 (see http://bugs.debian.org/643312).
Replicated, patch coming. This only affects portable OpenSSH, so we should be able to get a fix in 6.0.
Created attachment 2130 [details] bad-af.diff Fix IPQoS in portable OpenSSH
*** Bug 1965 has been marked as a duplicate of this bug. ***
Fix applied - this will be in openssh-6.0, due real soon. Thanks!
With reference to http://bugs.debian.org/650512, which I just reopened, I am sorry to say that the bug persists in OpenSSH 6.0.
Debian OpenSSH 6.0 does indeed seem broken: attempting a connection with IPQoS=EF yields "tos 0x0" in tcpdumps. However, stock OpenSSH 6.0 compiled from source works just fine. I see "tos 0xb8" as expected in my tcpdumps. I suggest you search the patches applied downstream to see what broke it.
I will of course take this up with the Debian maintainer, but from a cursory look, I cannot find anything in the downstream patches: % grep -ri qos openssh-6.0p1/debian/patches #10018 openssh-6.0p1/debian/patches/keepalive-extensions.patch: oKexAlgorithms, oIPQoS, oRequestTTY, openssh-6.0p1/debian/patches/keepalive-extensions.patch: { "ipqos", oIPQoS }, openssh-6.0p1/debian/patches/debian-banner.patch: options->ip_qos_interactive = -1; openssh-6.0p1/debian/patches/debian-banner.patch: options->ip_qos_bulk = -1; openssh-6.0p1/debian/patches/debian-banner.patch: options->ip_qos_interactive = IPTOS_LOWDELAY; openssh-6.0p1/debian/patches/debian-banner.patch: if (options->ip_qos_bulk == -1) openssh-6.0p1/debian/patches/debian-banner.patch: options->ip_qos_bulk = IPTOS_THROUGHPUT; openssh-6.0p1/debian/patches/debian-banner.patch: sKexAlgorithms, sIPQoS, openssh-6.0p1/debian/patches/debian-banner.patch: { "ipqos", sIPQoS, SSHCFG_ALL }, (note that these are all context lines of the diffs, so no changes are being made…)
I also see that a ~/.ssh/config file overrides any options specified on the command line. I would suspect that this should be the opposite (command-line always overrides config file)
Forgot to include that my platform is OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012, MacPorts version of openssh on Mac OS X 10.7 Lion.
(In reply to comment #8) > I also see that a ~/.ssh/config file overrides any options specified > on the command line. No, it doesn't.
This doesn't appear to be Debian specific, or a problem with how patches were applied to the Debian version. I'm seeing the problem with the latest upstream version: openssh-6.3p1. I'm also seeing it with the version that ships with Debian 7.0 (Wheezy): openssh-6.0p1. I built these on a Debian Wheezy box. Just let me know if there are any other details I can provide. I've updated the Debian bug that tracks this, here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650512#45
I just rechecked. openssh-6.3p1 does set tos on Ubuntu Precise. Note that it isn't set before the user authenticates, so you need to look a fair way into the connection to see it.
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1