Presentation is loading. Please wait.

Presentation is loading. Please wait.

An IP-header’s TOS field On setting and inspecting the ‘Type-of-Service’ field for outgoing or incoming datagrams.

Similar presentations


Presentation on theme: "An IP-header’s TOS field On setting and inspecting the ‘Type-of-Service’ field for outgoing or incoming datagrams."— Presentation transcript:

1 An IP-header’s TOS field On setting and inspecting the ‘Type-of-Service’ field for outgoing or incoming datagrams

2 Recall IP header format Time-to-Live Header Checksum Source IP-address Destination IP-address IdentificationFragment offset Header length Total Length (in bytes) Type of Service IP version Protocol ID-number DM 32 bits Options

3 precedenceDTR ECN Type-Of-Service 7 6 5 4 3 2 1 0 This 8-bit field in the IPv4 Header has been variously defined over the years. In a modern definition it has a 6-bit field called Differentiated Services Code Point (DSCP) and a 2-bit field called Explicit Congestion Notification (ECN). Routers may use this ToS value when selecting a destination for the packet. Legend: D = requests low Delay T = requests high Throughput R = requests high Reliability

4 Precedence Meanings for the 3-bit precedence field have been defined in Request For Comment documents (RFC791, RFC971): 111: Network Control 110: Internetwork Control 101: CRITIC/ECP 100: Flash Override 011: Flash 010: Immediate 001: Priority 000: Routine Here the middle four values pertain to national security and military communications having various levels of severity or urgency, (such as an outbreak of hostilities or a nuclear device detonation)

5 Caveat It should be mentioned that the ToS field’s ‘precedence’ bits are no longer used within contemporary networking systems for their originally envisioned purposes, and hence incoming IP packets which have these bits set ought to be regarded with suspicion – i.e., ask who is sending them, and why?

6 Nevertheless… We can employ one of the Linux ‘socket options’ to let applications manipulate the value that a socket places in the TOS field of its outgoing packets (SOL_IP, IP_TOS) And we can employ another of the socket options to enable an application to inspect the TOS value of incoming IPv4 packets (SOL_IP, IP_RECVTOS)

7 ‘msghdr’ and ‘cmsghdr’ This will give us yet another example of a client-and-server application which makes use of socket options and ancillary data delivered via the ‘recvmsg()’ function ‘client’ application ‘server’ application ‘tweaktos.cpp’‘clonetos.cpp’ The ‘client’ sends a message having a user-specified TOS-value, and the ‘server’ echos back that message using an identical TOS-value.

8 Our ‘private’ LAN It’s probably a good idea, when we try out this client-and-server application, to do it on one of our ‘private’ local networks that does not ‘route’ any of our packets to any public networks (or to the Internet), so the ‘unusual’ TOS values in our ‘test-packets’ won’t arouse any unwarranted suspicions about who we are and what we’re up to!

9 Recall ‘msghdr’ structure struct msghdr { void*msg_name;// optional address socklen_tmsg_namelen;// size of address struct iovec*msg_iov;// scatter/gather array intmsg_iovlen;// no. of members void*msg_control;// ancillary data buffer intmsg_controllen;// ancillary buffer length intflags;// flags on received message }; struct iovec { void *iov_base; size_t iov_len; }

10 Recall ‘cmsghdr’ structure struct cmsghdr { socklen_tcmsg_len;// data byte count, including header intcmsg_level;// originating protocol’s ID-number intcmsg_type;// protocol-specific type ID-number unsigned charcmsg_data[0];// variable amount of data follows }; Our buffer for receiving ancillary data: ‘packages’ of ancillary data

11 Recall the ‘CMSG’ macros intrxtos = 0; // to be filled in with incoming packet’s TOS struct smsghdr*cmsg;// for use as the loop variable for ( cmsg = CMSG_FIRSTHDR( &mymsghdr ); cmsg != NULL; cmsg = CMSG_NXTHDR( &mymsghdr, cmsg ) ) { if (( cmsg->cmsg_level == SOL_IP ) &&( cmsg->cmsg_type == IP_TOS )) memcpy( &rxtos, CMSG_DATA( cmsg ), 1 ); }

12 Viewing memory While learning about (or debugging) how your ancillary data arrives via ‘recvmsg()’, it may be instructive and helpful if you can get a look at memory-buffer’s contents You can insert (temporarily) the following block of code (or some suitable variation) so you’ll see a memory ‘dump’ onscreen

13 ‘hex’ and ‘ascii’ # shows the contents of the n-byte memory-area whose address is ‘buf’ unsigned char*cp = (unsigned char*)buf; for (int i = 0; i < n; i += 16) { printf( “\n %03X: “, i ); for (int j = 0; j < 16; j++) { if ( i+j < n ) printf( “%02X “, cp[ i+j ] ); elseprintf( “ “ ); } for (int j = 0; j < 16; j++) { intch = ( i+j < n ) ? cp[ i+j ] : ‘ ‘; if (( ch 0x7E )) ch = ‘.’; printf( “%c”, ch ); } printf( “\n\n” );

14 In-class exercise #1 Modify our ‘tweaktos.cpp’ program so that it will draw a ‘dump’ of the contents of its ancillary data buffer (named ‘cbuf’) before terminating

15 In-class exercise #2 Modify our ‘tweaktos.cpp’ demo so that it will ALSO receive an incoming packet’s ‘Time-to-Live’ field, as well as continuing to receive its ‘Type-Of-Service’ field, and display a ‘dump’ of the ancillary data’s memory buffer to see both these items arranged as successive records in ‘cbuf’


Download ppt "An IP-header’s TOS field On setting and inspecting the ‘Type-of-Service’ field for outgoing or incoming datagrams."

Similar presentations


Ads by Google