Ask Your Question

Why is my TCP Header Seen as "Data (20 Bytes)"?

asked 2020-07-24 15:29:41 +0000

redapplesonly gravatar image

Hi Wireshark Gurus,

I am a college student working on a coding assignment. I'm writing a C program which creates a PCAP file, writes one valid network packet into the file, then exits. The point of the exercise is to learn how to format Ethernet, IP, and TCP headers in code. I pass my assignment if Wireshark can successfully open my PCAP and read the packet.

So far, my code writes a valid Ethernet and IP header (although I am skipping some IP fields, like CRC checksum and flags). My code also writes a TCP header... but Wireshark doesn't recognize it! After the IP header, it simply sees "Data, 20 bytes." I followed the RFC for TCP on the TCP header format, plus set IP_Protocol = 6, and I thought that was all that was necessary. But no.

Why might Wireshark look at my TCP header, and see raw data? I'm guessing it might be one of two reasons:

  • The IP header is still malformed, leaving Wireshark to consider the IP payload as "Data"
  • The TCP header format is screwed up

When Wireshark looks at where it should see a TCP header, it reports that it sees this:

Data (20 bytes)  0016 d7a6 7145 c91d 0ca8 87dd 5018 01df 0443 0000

(I added those spaces.) When I hand-check that data against what my code is writing, everything looks okay. (Field values were copied from another packet I captured in Wireshark.)

Field               octets  decimal val binary value                                hex value
src_port            2       22          0000 0000 0001 0110                         0016
dst_port            2       55206       1101 0111 1010 0110                         D7A6
tcp_seq_number      4       1900398877  0111 0001 0100 0101 1100 1001 0001 1101     7145 C91D
tcp_ack_number      4       212371421   0000 1100 1010 1000 1000 0111 1101 1101     0CA8 87DD
tcp_OffAndFlags     2       20504       0101 0000 0001 1000                         5018
tcp_window_size     2       479         0000 0001 1101 1111                         01DF
tcp_checksum        2       1091        0000 0100 0100 0011                         0443
tcp_urgent_pointer  2       0           0000 0000 0000 0000                         0000

Everything is exactly as it should be, as far as I can tell. So what is wrong?

What I see in Wireshark is included below. Many thanks in advance!

Frame 1: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Dec 31, 1969 19:00:00.000000000 Eastern Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 0.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 54 bytes (432 bits)
    Capture Length: 54 bytes (432 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:data]
    [Coloring Rule Name: Broadcast]
    [Coloring Rule String: eth[0] & 1]
Ethernet II, Src: 64:96:c8:fa:fc:ff (64:96:c8:fa:fc:ff), Dst: Woonsang_04:05:06 (01:02:03:04:05:06)
    Destination: Woonsang_04:05:06 (01:02:03:04:05:06)
    Source: 64 ...
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2020-07-24 15:37:09 +0000

grahamb gravatar image

From your IP "header":

Fragment offset: 512

This indicates that this is not the first IP fragment, so the IP dissector will be looking for that before it can reassemble the fragments and offer the data to the TCP dissector.

Try setting the value to 0.

edit flag offensive delete link more


Yep, that did it. Great catch!

To be honest, the Fragment Offset value of 512 is probably me incorrectly setting the IP flags in my code. I'll deep dive and fix.

Just out of curiosity, if this was a valid packet and Frag Offset was legitimately set to 512, the packet would be signifying, "I'm a fragment of a bigger IP packet, my payload would be placed at the 512th byte of the previous IP packet's payload"? The fragment setting has always confused me.

Thank you!

redapplesonly gravatar imageredapplesonly ( 2020-07-24 16:45:02 +0000 )edit

if this was a valid packet and Frag Offset was legitimately set to 512, the packet would be signifying, "I'm a fragment of a bigger IP packet, my payload would be placed at the 512th byte of the previous IP packet's payload"?

No, because there's no guarantee that IP fragments are sent in order - at least at one point, I think the Linux IPv4 stack sent the segments in reverse order or, at least, sent the last fragment first, so that the receiver would know the total length of the reassembled packet and could allocate space for it and not have to reallocate.

What it means is "this is a fragment of a bigger IP packet, and its payload is bytes 513 through {513 + length - 1} of the bigger packet", where I'm using 1-origin numbering, so the first byte of the bigger packet is byte 1 ...(more)

Guy Harris gravatar imageGuy Harris ( 2020-07-24 22:29:21 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-07-24 15:29:41 +0000

Seen: 1,479 times

Last updated: Jul 24 '20