openssh bugs - Mar 2010 - [Bug 1733] New: Enhance support for QoS (ToS) by supporting DSCP/CS and adding option

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

           Summary: Enhance support for QoS (ToS) by supporting DSCP/CS
                    and adding option
           Product: Portable OpenSSH
           Version: 5.4p1
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: philipp at redfish-solutions.com


Created an attachment (id=1808)
 --> (https://bugzilla.mindrot.org/attachment.cgi?id=1808)
QoS fix for DSCP/CS markings

This adds the option "UseQoS" which takes two marking arguments, the
first for non-interactive traffic and the second for interactive
traffic.

For instance, in a DSCP environment, one could use:

UseQoS af12 cs2

to retain compatibility, the default is:

UseQoS throughput lowdelay

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1808|application/octet-stream    |text/plain
          mime type|                            |

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Philip Prindeville <philipp at redfish-solutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1808|0                           |1
        is obsolete|                            |

--- Comment #1 from Philip Prindeville <philipp at redfish-solutions.com>
2010-03-14 05:01:17 EST ---
Created an attachment (id=1809)
 --> (https://bugzilla.mindrot.org/attachment.cgi?id=1809)
QoS fix for DSCP/CS markings with sytem-wide config restriction

Add flag to both keywords[] and
read_config_file()/process_config_line() to keep track of whether we're
parsing a user profile or a system profile.

If it's a user profile and the keyword[].restricted flag is set, don't
allow this directive.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Philip Prindeville <philipp at redfish-solutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1809|0                           |1
        is obsolete|                            |

--- Comment #2 from Philip Prindeville <philipp at redfish-solutions.com>
2010-03-14 05:05:47 EST ---
Created an attachment (id=1810)
 --> (https://bugzilla.mindrot.org/attachment.cgi?id=1810)
QoS fix for DSCP/CS markings with sytem-wide config restriction

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #3 from Philip Prindeville <philipp at redfish-solutions.com> 
---
Created attachment 1880
  --> https://bugzilla.mindrot.org/attachment.cgi?id=1880
Upstream patch for QoS markings

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Blocks|                            |1708

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #4 from Damien Miller <djm at mindrot.org>  ---
Why is the restriction that UseQoS may only appear in
/etc/ssh/ssh_config necessary? It isn't an effective control, since a
user who wanted to circumvent it could just build a ssh without the
check. Does the IP_TOS ioctl perform any privilege checks when setting
low-precedence traffic classes?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #5 from Philip Prindeville <philipp at redfish-solutions.com> 
---
(In reply to comment #4)
> Why is the restriction that UseQoS may only appear in
> /etc/ssh/ssh_config necessary? It isn't an effective control, since a
> user who wanted to circumvent it could just build a ssh without the
> check. Does the IP_TOS ioctl perform any privilege checks when setting
> low-precedence traffic classes?
It's a somewhat effective check, since not everyone may have access to
recompiled binaries or even sources and a compiler.

It removes for the large majority the need to fiddle with settings they
might not (and most likely don't) entirely understand.

And no, the setsockopt(IP_TOS) is entirely unprivileged.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Philip Prindeville <philipp at redfish-solutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philipp at redfish-solutions.c
                   |                            |om

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #6 from Damien Miller <djm at mindrot.org>  ---
If the setsockopt doesn't perform privilege checks, then why should
ssh?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #7 from Philip Prindeville <philipp at redfish-solutions.com> 
---
(In reply to comment #6)
> If the setsockopt doesn't perform privilege checks, then why should
> ssh?
It's not a privilege check so much as it's an enforcement of
system-wide policy.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #8 from Damien Miller <djm at mindrot.org>  ---
You have lost me - if the IP_TOS is allowed by any user by the kernel,
then whose policy is ssh enforcing?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #9 from Philip Prindeville <philipp at redfish-solutions.com> 
---
(In reply to comment #8)
> You have lost me - if the IP_TOS is allowed by any user by the kernel,
> then whose policy is ssh enforcing?
Don't think of it as policy enforcement.  Think of it as centralized
configuration management for certain critical controls.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #10 from Damien Miller <djm at mindrot.org>  ---
We are freezing for the OpenSSH 5.6 release. Retargetting these bugs to
the next release.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1803

--- Comment #11 from Damien Miller <djm at mindrot.org>  ---
Targetting OpenSSH 5.7

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|1708                        |

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Philip Prindeville <philipp at redfish-solutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |openbsd, patch

--- Comment #12 from Philip Prindeville <philipp at redfish-solutions.com>
---
(In reply to comment #9)
> (In reply to comment #8)
> > You have lost me - if the IP_TOS is allowed by any user by the kernel,
> > then whose policy is ssh enforcing?
> 
> Don't think of it as policy enforcement.  Think of it as centralized
> configuration management for certain critical controls.
Didn't see a response to this, so I'm not sure if this question is
adequately resolved or not.

In any case, how does the review process usually go?

Regardless of whether this is going into 5.6 or 5.7, how do I get a
sign-off on this?

Thanks.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Gary T. Giesen <giesen at snickers.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giesen at snickers.org

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #13 from Gary T. Giesen <giesen at snickers.org>  ---
I'd like to see DSCP implemented as well instead of the obsolete (and
unconfigurable) IP Precedence model...

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #14 from Gary T. Giesen <giesen at snickers.org>  ---
Just a further note that having the "system-wide config restriction"
is
pretty useless if anyone can copy their own binary onto the system and
bypass it. I suggest having a default in /etc/ssh/ssh_config, and can
can be overridden by the user either in their local config or as an
argument on the command line.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #15 from Philip Prindeville <philipp at redfish-solutions.com>
---
(In reply to comment #14)
> Just a further note that having the "system-wide config
restriction" is
> pretty useless if anyone can copy their own binary onto the system and
> bypass it. I suggest having a default in /etc/ssh/ssh_config, and can
> can be overridden by the user either in their local config or as an
> argument on the command line.
And... this is why I think that would be a bad idea.

You're fairly typical, I'd say, of most users.  You understand what QoS
settings are for, and how they can be changed, and what ultimately
they're expected to do.

But the finer details would seem to have been missed.

There are no "standard" profiles for interpreting QoS markings, for
instance.  There's a proposal (RFC 4594) for uniform markings that
ISP's and Enterprises are free to implement, or equally free not to.

So you can set your QoS bits to AF22 thinking that this will do what
you want, and there's a good chance you'd be wrong: the only person who
knows for sure is the Enterprise network architect that provisioned the
entire infrastructure.  Everyone else is just pulling numbers out of
their hat.

For *exactly* the same reasons that "PermitRootLogin",
"PermitEmptyPasswords", and "IgnoreRhosts" aren't
user-settable
(because end-users shouldn't be making decisions that potentially
impact performance and/or security organization-wide), the QoS bits
shouldn't be user-settable either.

If users can wreak havoc by having their own profile containing
"PermitRootLogin yes/PermitEmptyPasswords yes", then be aware that
they
can negatively impact organization-wide networking (especially VoIP and
IPTV services) by making poor choices elsewhere.

Make the compelling argument to me that users should be allowed to have
their own .sshd_config file, and put into it those latter two settings,
and I'll concede that by the same reasoning they should be allowed to
set their own QoS policy.

But the bottom line is that QoS markings are as much a part of a site's
singular and standardized architectural policy as the type and degree
of enforcement of their security measures.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #16 from Gary T. Giesen <giesen at snickers.org>  ---
You're confusing the settings for the daemon (sshd_config, which
obviously only root should be able to change) with the settings for the
client (ssh_config) when someone makes an outbound connection.

The settings for the daemon can't be bypassed since obviously it
requires root privileges to launch it to listen on port 22.

The settings for the client should be freely settable by the user, just
as it is with the -S option for telnet. I have no problems with having
smart defaults in ssh_config, but they definitely should be able to be
overridden.

In the end, there's no sense having a setting which provides no
security whatsoever (but looks like it does). If a user is malicious,
they can compile their own ssh client with the settings they want and
bypass your config anyways. Since the kernel doesn't enforce any
privileges on the setting of the DSCP markings, you shouldn't either.
Thus it only makes sense to provide a configurable default.

Keep in mind it's up to the network to trust and enforce DSCP markings,
so that's the proper place for these kind of access controls to appear.
Otherwise you'll need to convince the various *nix vendors to require
privileges on setting DSCP markings.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #17 from Philip Prindeville <philipp at redfish-solutions.com>
---
(In reply to comment #16)
> You're confusing the settings for the daemon (sshd_config, which
> obviously only root should be able to change) with the settings for the
> client (ssh_config) when someone makes an outbound connection.
I'm not confusing them at all, and if you reread my comments you'll see
that I explicitly said "make the compelling argument to me that users
should be allowed to have their own .sshd_config file".  Not sure what
was unclear about that.

Moving on...
> The settings for the daemon can't be bypassed since obviously it
> requires root privileges to launch it to listen on port 22.
Or you could read all users' settings and just use the most permissive
of the union...  Or individual users could run their own instances on
ports other than 22...  since your argument was that users could have
their own binary clients, I'm saying why not take it a step further and
have them run their own servers...

> The settings for the client should be freely settable by the user, just
> as it is with the -S option for telnet. I have no problems with having
> smart defaults in ssh_config, but they definitely should be able to be
> overridden.
You're missing the point that this is largely IRRELEVANT.  The network
doesn't care if the client or the server is sending mislabeled packets,
they both have exactly the same potential to be disruptive to other
traffic types like VoIP and IPTV.

I would make the argument that letting the user (and client) set the
encryption algorithm, cipher strength, etc. was a serious mistake.  If
the user uses too weak an encryption standard, his connection can be
eavesdropped or even subverted.
> In the end, there's no sense having a setting which provides no
> security whatsoever (but looks like it does). If a user is malicious,
> they can compile their own ssh client with the settings they want and
> bypass your config anyways. Since the kernel doesn't enforce any
> privileges on the setting of the DSCP markings, you shouldn't either.
> Thus it only makes sense to provide a configurable default.
Did you read comment #9?
> Keep in mind it's up to the network to trust and enforce DSCP markings,
> so that's the proper place for these kind of access controls to appear.
> Otherwise you'll need to convince the various *nix vendors to require
> privileges on setting DSCP markings.
Again, you're missing the obvious: the settings are more easily and
better trusted when they're set by someone who actually had a hand in
setting the site network policy!  They are more likely to work.

You're thinking of these as a per-host setting that only affects the
host, and they're not.  It's a setting that affects the entire network,
and should be set in a consistent and coherent way organization-wide.

It's not about what the user might set just because he can.  It's about
what should be set by the site administrators because they're actually
the most clueful.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #18 from Philip Prindeville <philipp at redfish-solutions.com>
---
(In reply to comment #16)
> In the end, there's no sense having a setting which provides no
> security whatsoever (but looks like it does). If a user is malicious,
> they can compile their own ssh client with the settings they want and
> bypass your config anyways. Since the kernel doesn't enforce any
> privileges on the setting of the DSCP markings, you shouldn't either.
> Thus it only makes sense to provide a configurable default.
This is a specious argument.

Look at the man page for libresolv.

The path to /etc/resolv.conf is hardwired in the binary, and that file
isn't writable by users.

Yes, users could link against their own version of libresolv, but what
would be the point?  They'd just be opening themselves to pointing to
the wrong server, an unreliable server, or perhaps even a server that's
been compromised and exposes them to DNS-based exploits.

Similarly, there's no interest in having users have their own binaries
for ssh that can inject packets with detrimental QoS markings, because
they will be making things worse for themselves in the end.  And
there's no interest in users having their own QoS settings just as
there's no interest in their having their own /etc/resolv.conf file.

Yes, you can do it... but why?  What does it really get you?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #19 from Damien Miller <djm at mindrot.org>  ---
resolv.conf is not world writable because it is used by system daemons
that shouldn't be subject to reconfiguration by users, not for any of
the reasons you cited.

Attempting to enforce DSCP policy in ssh(1) is ineffective and
therefore misguided. When I get around to looking at this patch again,
I don't plan on merging this part.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #20 from Philip Prindeville <philipp at redfish-solutions.com>
---
(In reply to comment #19)
> resolv.conf is not world writable because it is used by system daemons
> that shouldn't be subject to reconfiguration by users, not for any of
> the reasons you cited.
It's not just that resolv.conf isn't writable, there's also no way
to
override where it looks for the configuration file.  It would have been
easy, for instance, to have an environment variable that contained the
path to an alternate file to use, but this was deliberately not
supported.
> Attempting to enforce DSCP policy in ssh(1) is ineffective and
> therefore misguided. When I get around to looking at this patch again,
> I don't plan on merging this part.
Well, tell you what: let's compare notes from your experiences with all
of the site-wide rollouts of QoS that you've done with my experiences,
and maybe we can base our conclusions on actual empirical data and not
supposition.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #21 from Philip Prindeville <philipp at redfish-solutions.com>
2010-10-01 03:26:48 EST ---
Looking at this in a similar historical context...

I remember when DNS was first deployed. Prior to it, we had used HOSTS
files that we picked up via FTP from the NIC at USC.

A lot of programs even had the addresses of servers compiled into them.

When DNS came out, there were libraries you could link against, but not
all programs were released immediately using them.  Indeed, some
programs even used their own resolver libraries and had root name
servers coded into them.

After a while, the load on the root name servers became too high, and
these programs needed to be hunted down and replaced.  Such programs
also didn't leverage caching.

At no time, however, did the system-wide libraries (libresolv.a, etc)
allow the user to specify an alternate location for the resolver
configuration, or to override the name servers to query.

Which turned out to be fortuitous.

Not only can incorrect configuration of the resolver lead to heavy
loading on the root name servers, or poor performance due to a lack of
local caching... but:

* by diverting DNS queries to a highjacked server, I can intercept a
lot of your network traffic (email, for instance, by returning bogus MX
records);

* I can subvert your PKI by pointing you at bogus trusted certificate
authorities;

* I can cause a denial of service attack by pointing you at bogus NTP
servers and over time skewing your clock such that loses critical sync
with other server.

etc.

So generating a DNS query is not a privileged operation.  It's a rather
banal operation, and superficially affects only the process making the
query.  In this respect, it bears a good deal of parallel to the
discussion we're having about what's the big deal with setting QoS
bits.

Yet through a bit of misconfiguration by the user, it can overwhelm
critical network infrastructure (the root name servers), and can open
doors up to network attack.

Similarly, misconfiguration of QoS bits by the user can deprive other
critical network services of reserved bandwidth, etc.

Why don't we initially just commit it as is, and if someone comes
forward with a usage case that absolutely requires per-user
configuration of QoS settings, we'll change it then.

Because it's easier to add new configuration capability later once it's
proven it's needed, than to revoke it once software is deployed in the
field.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #22 from Philip Prindeville <philipp at redfish-solutions.com>
2010-10-30 04:10:04 EST ---
Will this go into 6.0 and when is 6.0 due out?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #23 from Damien Miller <djm at mindrot.org> 2010-11-05
14:35:06 EST ---
Created attachment 1949
  --> https://bugzilla.mindrot.org/attachment.cgi?id=1949
/home/djm/ssh-qos.diff

revised QoS diff. factors out common code, removes client-side policy
restriction on QoS

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #24 from Philip Prindeville <philipp at redfish-solutions.com>
2010-11-05 15:20:40 EST ---
(In reply to comment #23)
> Created attachment 1949 [details]
> /home/djm/ssh-qos.diff
> 
> revised QoS diff. factors out common code, removes client-side policy
> restriction on QoS
I would rewrite parse_ipqos() explicitly use hex values only.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #25 from Damien Miller <djm at mindrot.org> 2010-11-14
10:32:42 EST ---
Patch applied - thanks. This will be in OpenSSH 5.7

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #26 from Damien Miller <djm at mindrot.org> 2011-01-24
12:34:00 EST ---
Move resolved bugs to CLOSED after 5.7 release

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #27 from Gary T. Giesen <giesen at snickers.org> 2011-08-31
14:58:18 EST ---
Was there a reason you left out AF21?

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #28 from Gary T. Giesen <giesen at snickers.org> 2011-08-31
14:59:42 EST ---
Was there a reason you left out AF21?(In reply to comment
#27)
> Was there a reason you left out AF21?
Or rather, it's mislabeled:

906     

    { "af14", IPTOS_DSCP_AF21 },

907     

    { "af22", IPTOS_DSCP_AF22 },

908     

    { "af23", IPTOS_DSCP_AF23 },

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #29 from Philip Prindeville <philipp at redfish-solutions.com>
2011-08-31 15:31:25 EST ---
(In reply to comment #28)
> Was there a reason you left out AF21?(In reply to comment #27)
> > Was there a reason you left out AF21?
> 
> Or rather, it's mislabeled:
> 
> 906     
> 
>     { "af14", IPTOS_DSCP_AF21 },
> 
> 907     
> 
>     { "af22", IPTOS_DSCP_AF22 },
> 
> 908     
> 
>     { "af23", IPTOS_DSCP_AF23 },
The question must be for Damien: he modified my patch. It was correct
in my version.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=1733

--- Comment #30 from Damien Miller <djm at mindrot.org> 2011-09-02
09:53:13 EST ---
Yeah, my bad. I'll commit a fix for the 6.0 release.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.