"David S. Miller" wrote:
>
> From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
> Date: Sun, 12 Aug 2001 20:25:36 -0700
>
> It appears that the IP TOS values in netinet/ip.h are
> incorrect:
>
> I'll be using the page you even quoted:
>
> http://www.hut.fi/~msisomak/diffserv.html
>
> to show that the values are correct. This page, in figure
> 2, shows the following bit layout:
>
> ----------------------------------------
> | Precedence | Type of Service | 0 |
> ----------------------------------------
> 8 7 6 5 4 3 2 1 0
>
> The bit numbering above is mine, the page labels them
> backwards for whatever reason.
RFC 1349 labels them differently:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1349.html#sec-3
Also, from doing a google search on setsockopt and IP_TOS, I was able
to find exactly zero pieces of source code that do this, so I may be
the first one to every try it :)
>
> #define IPTOS_TOS_MASK 0x1E
> #define IPTOS_TOS(tos) ((tos) & IPTOS_TOS_MASK)
>
> TOS field, bits 1 thru 5
>
> #define IPTOS_LOWDELAY 0x10
>
> Minimize delay, binary 1000 in TOS field.
>
> #define IPTOS_THROUGHPUT 0x08
>
> Minimize thruput, binary 0100 in TOS field.
>
> #define IPTOS_RELIABILITY 0x04
>
> Maximize reliability, binary 0010 in TOS field.
>
> #define IPTOS_LOWCOST 0x02
> #define IPTOS_MINCOST IPTOS_LOWCOST
>
> Minimize monetary (misspelled on page) cost, binary 0001 in TOS
> field.
>
> Am I missing something??
>
> I think the mislabelled bit numbering in the figure of that web page
> has mislead your thinking, that's all.
>
> At least, Linux and BSD's header files agree perfectly for
> these values :-)
>
> Also, will the kernel take any 8-bit value I try to stuff in
> there with:
> setsockopt(dev_socket, SOL_IP, IP_TOS, (char*)&val, sizeof(int))
> or will it normalize values according to it's internal rules?
>
> 1) If you have any bits outside of the precidence or
> type of service field set, you will get -EINVAL.
> (basically if the lowest bit is set, it is reserved
> and thus invalid to pass to this sockopt)
I didn't seem to be getting errors on the system call, but I should
check more closely to make sure...
>
> 2) If this is a TCP connection, and CONFIG_INET_ECN is
> enabled, the low two bits you pass will be replaced
> with the current ECN bit settings. The lowest two
> TOS byte bits are used for ECN.
I think that #ifdef code should be changed to check for the
run-time enabled-ness of ECN. Also, is there a way to turn
ECN on/off for a specific socket only?
>
> 3) If the precidence in the TOS value passed is greater than
> or equal to IPTOS_PREC_CRITIC_ECP, and the user does not
> uave CAP_NET_ADMIN capabilities, you will get an -EPERM
> failure.
>
> Basically, I just read aloud the code in net/ipv4/ip_sockglue.c
> which you could have just as easily have done by grepping for
> IPTOS under net/ipv4/*.c But I'll let you be lazy just this
> one time :-)
I eventually found it, but couldn't easily explain what I was seeing.
The code generally looks correct, depending on the bit-ordering.
I wasn't passing values to setsockopt in network byte order, but
it doesn't look like I should: Do you agree?
Thanks,
Ben
>
> Later,
> David S. Miller
> davem@xxxxxxxxxx
--
Ben Greear <greearb@xxxxxxxxxxxxxxx> <Ben_Greear@xxxxxxxxxx>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
|