Wireshark sometimes is little misleading. The Linux stack is the ultimate judge in terms of compliance. If you keep the total bits allocation for the field then things should be OK (which seems to be the case here).

Even if you don't comply with Linux 100%, you could get STCP working between itself. That is, two STCP instances could be transmitting traffic. If the STCP complies with TCP in critical aspects, then you could
transmit between STCP and TCP as well.

On 17-Nov-08, at 9:10 PM, Imad Gharazeddine wrote:


Setting data offset field to an 8-bit field...
Setting control bits field to a 6-bit field...
Not explicitly setting a reserved field at all.

Although the above approach differs from the RFC, it works and wireshark is happy with everything. Checksumming also works.

Is this acceptable or do we strictly have to follow the RFC?

-- Imad

On Mon, Nov 17, 2008 at 7:33 PM, Imad Gharazeddine | McGill <[EMAIL PROTECTED]> wrote: We solved the previous problem by combining the 4-bit data offset field with the 6-bit reserved field, resulting in a 10-bit combined field which works in wireshark (checksums calculated correctly). Our definition of "works" here is that we get the same header length field value when we create our own STCP packets as those created by the UMLs.

We now have a similar problem with the CONTROL BITS field. It is 6 bits long, but wireshark assumes it's 8 bits long (the extra bits are: CWR & ECN-Echo... which I assume are bits spilling into the 'reserved' field i.e. they are bits that actually make use of the reserved field since their functionality is what the reserved field was designed for in the first place)

There are no "reserved" fields AFTER the CTRL BITS field to manipulate in this new case... so i'm not sure how to approach this now. Setting a SYN bit is supposed to give a CTRL BITS field of 00000010 when it in fact is giving 00001000.

Any hints/ideas?

-- Imad

On Mon, Nov 17, 2008 at 12:06 AM, Muthucumaru Maheswaran <[EMAIL PROTECTED]> wrote:
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; 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.


-- Imad

gini mailing list

Reply via email to