[Planetlab-devel] Re: CAP_NET_ADMIN for setting ToS in IPv4 header (was Re: [CVS] svn.planet-lab.org - check in: r16735 - vsys-scripts/trunk)

"S.Çağlar Onur" caglar at CS.Princeton.EDU
Fri Jan 22 14:56:12 EST 2010


Hi Marc,

On Jan 22, 2010, at 11:13 AM, Marc Fiuczynski wrote:

> Hi Caglar,
> 
> On Jan 22, 2010, at 10:47 AM, caglar at CS.Princeton.EDU wrote:
>> vsys script for letting users to set the Type of Services(ToS) byte in the IPv4 header
>> 
>> +	gcc fd_tos.c fdpass.o -o exec/fd_tos
> 
> Thank you for putting together this solution using vsys.  Vsys is a nice solution for punching a fine grain hole into Linux's coarse grain capabilities.
> 
> However, in this particular case I think Linux just gets this wrong.  According to the manual pages for the SO_PRIORITY socket option:  Set the protocol-defined priority for all packets to be sent on this socket. Linux uses this value to order the networking queues: packets with a higher priority may be processed first depending on the selected device queueing discipline. For ip(7), this also sets the IP type-of-service (TOS) field for outgoing packets. Setting a priority outside the range 0 to 6 requires the CAP_NET_ADMIN capability.

OK, It turns out that vsys script is not needed for setting the TOS bit for values defined  in the netinet/ip.h (but it's needed for higher values). These predefined TOS values automatically sets the SO_PRIORITY option without requiring a CAP_NET_ADMIN capability.

bash-3.2# ./test
IP_TOS is 0
IP_TOS set 8
IP_TOS is 8
SO_PRIORITY is 2
SO_PRIORITY set 3
SO_PRIORITY is 3

> For implementing per stream outbound bandwidth limits on the node I think it sufficient to just use the ToS range of 0..6.  My only concern then is the statement "Linux uses this value to order the networking queues: packets with a higher priority may be processed first depending on the selected device queueing discipline", which is a horribly vague statement.  For what we are doing, I'd be fine with some sort of IP tables rule that clears the ToS field for ranges 0..6.

Best regards,
--
S.Çağlar Onur <caglar at cs.princeton.edu>




More information about the Devel mailing list