It is actually 4 bits for the data offset - a nibble.

Please see below the definition used by Linux in its tcp.h


struct tcphdr


    u_int16_t th_sport;         /* source port */

    u_int16_t th_dport;         /* destination port */

    tcp_seq th_seq;             /* sequence number */

    tcp_seq th_ack;             /* acknowledgement number */


    u_int8_t th_x2:4;           /* (unused) */

    u_int8_t th_off:4;          /* data offset */

#  endif


    u_int8_t th_off:4;          /* data offset */

    u_int8_t th_x2:4;           /* (unused) */

#  endif

    u_int8_t th_flags;

#  define TH_FIN        0x01

#  define TH_SYN        0x02

#  define TH_RST        0x04

#  define TH_PUSH       0x08

#  define TH_ACK        0x10

#  define TH_URG        0x20

    u_int16_t th_win;           /* window */

    u_int16_t th_sum;           /* checksum */

    u_int16_t th_urp;           /* urgent pointer */



Wireshark may be taking some liberties in printing a 4-bit field.

Also, the header length is specified in 4-byte words.. so the maximum

header size is 60 bytes (15 *4 bytes).



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Imad
Gharazeddine | McGill
Sent: November-16-08 9:29 PM
To: Muthucumaru Maheswaran;
Subject: Data Offset field contradiction


During our attempt to create an STCP packet, we encountered this problem:

RFC 793 states that DATA OFFSET field must be 4 bits long. After it, comes
the RESERVED field which is 6 bits long.

Wireshark analysis of regular TCP packets from UMLs reveals that the HEADER
LENGTH field, which we assume to be the equivalent of the DATA OFFSET field,
has a field-length of 2 hex digits = 2x4bits = 8bits.

If the RFC states DATA OFFSET must be 4 bits, how come wireshark is
expecting this field to have 8 bits in it?

How can a TCP header length of 20 = value of "50" in wireshark be achieved
if our DATA OFFSET field is limited to 4 bits. With 4 bits you can only go
up to 15.


-- Imad

gini mailing list

Reply via email to