Ask Your Question
0

What is Wireshark showing me with a TCP/IP block

asked 2021-10-11 17:55:01 +0000

rsherry8 gravatar image

updated 2021-10-11 18:11:14 +0000

grahamb gravatar image

Below is a data packet and the details from it. This output was generated by WireShark. I would expect to see the IP Header first followed by the TCP header. However, I am thinking WireShark is showing me four bytes before the IP header. The reason I say this is, in part, the first field of the IP header is the verison. This field is 4 bits long. The first byte is 0x02. This would imply that I am using version 2 of IP. I do not think that is right. What do the first four bytes in Wireshark's dump represent?

Note: This packet was generated by two programs running on the same machine using TCP/IP to communicate.

Frame 75: 44 bytes on wire (352 bits), 44 bytes captured (352 bits) on interface \Device\NPF_Loopback, id 0
Null/Loopback  
    Family: IP (2)  
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1  
Transmission Control Protocol, Src Port: 8080, Dst Port: 56803, Seq: 19, Ack: 19, Len: 0  
    Source Port: 8080  
    Destination Port: 56803  
    [Stream index: 0]  
    [TCP Segment Len: 0]  
    Sequence Number: 19    (relative sequence number)  
    Sequence Number (raw): 3112201488  
    [Next Sequence Number: 19    (relative sequence number)]  
    Acknowledgment Number: 19    (relative ack number)  
    Acknowledgment number (raw): 2603748537  
    0101 .... = Header Length: 20 bytes (5)  
    Flags: 0x010 (ACK)  
    Window: 10233  
    [Calculated window size: 2619648]  
    [Window size scaling factor: 256]  
    Checksum: 0xbde8 [unverified]  
    [Checksum Status: Unverified]  
    Urgent Pointer: 0  
    [SEQ/ACK analysis]  
    [Timestamps]  
        [Time since first frame in this TCP stream: 0.000581000 seconds]  
        [Time since previous frame in this TCP stream: 0.000009000 seconds]  

0000   02 00 00 00 45 00 00 28 9f 4c 40 00 80 06 00 00   ....E..([email protected]  
0010   7f 00 00 01 7f 00 00 01 1f 90 dd e3 b9 80 6d 10   ..............m.  
0020   9b 32 0c b9 50 10 27 f9 bd e8 00 00               .2..P.'.....
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-10-11 18:14:00 +0000

grahamb gravatar image

You've made the capture on the loopback adaptor so there is no Ethernet layer, instead there is the pseudo layer for loopback, which is mainly used to indicate the next layer which is IP.

edit flag offensive delete link more

Comments

What you are saying makes sense to me. I would expect the IP Header to be 16 bytes. If the pseudo layer before the IP Header is 4 bytes then I would expect the TCP header to start at offset 20 which it does. So it all fits.

rsherry8 gravatar imagersherry8 ( 2021-10-11 18:26:18 +0000 )edit

If you expand the frame block, you'll see the 'encapsulation type' as 'NULL/loopback (15)' , which is how loopback captures on Windows are encapsulated. Info on this header can be found in the wtap.h source file:

 * WTAP_ENCAP_NULL corresponds to DLT_NULL from "libpcap".  This
 * corresponds to
 *
 *  1) PPP-over-HDLC encapsulation, at least with some versions
 *     of ISDN4BSD (but not the current ones, it appears, unless
 *     I've missed something);
 *
 *  2) a 4-byte header containing the AF_ address family, in
 *     the byte order of the machine that saved the capture,
 *     for the packet, as used on many BSD systems for the
 *     loopback device and some other devices, or a 4-byte header
 *     containing the AF_ address family in network byte order,
 *     as used on recent OpenBSD systems for the loopback device;
 *
 *  3) a 4-byte header containing 2 octets of 0 and an Ethernet
 *     type in the byte order from an Ethernet header ...
(more)
grahamb gravatar imagegrahamb ( 2021-10-11 19:02:25 +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

Stats

Asked: 2021-10-11 17:55:01 +0000

Seen: 53 times

Last updated: Oct 11