"David S. Miller" wrote: > > From: Ben Greear <greearb@candelatech.com> > 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@redhat.com -- Ben Greear <greearb@candelatech.com> <Ben_Greear@excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
