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 */
# if __BYTE_ORDER == __LITTLE_ENDIAN
u_int8_t th_x2:4; /* (unused) */
u_int8_t th_off:4; /* data offset */
# endif
# if __BYTE_ORDER == __BIG_ENDIAN
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; gini@cs.mcgill.ca
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.
Thanks,
-- Imad
_______________________________________________
gini mailing list
gini@cs.mcgill.ca
http://mailman.cs.mcgill.ca/mailman/listinfo/gini
