Bogus IP packets and Wireshark

Bogus IP packets and Wireshark

  • Comments 5
  • Likes

Hi there,

 

In today’s blog post, I’m going to talk about an issue that I have come across several times while analyzing network traces with Wireshark. Let’s take the following example:

 

I apply the following filter on a network trace:

 

ip.addr==192.168.100.23 and ip.addr==192.168.121.51 and tcp.port==3268 and tcp.port==8081

 

And I get the following traffic:

 

No.     Time        Source                Destination           Protocol Info

   8773 17.458870   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [SYN] Seq=0 Win=65535 Len=0 MSS=1460

   8774 17.458988   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [SYN, ACK] Seq=0 Ack=1 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460

   8775 17.459239   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [ACK] Seq=1 Ack=1 Win=65535 Len=0

   8776 17.459239   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=264

   8850 17.658922   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [ACK] Seq=1 Ack=265 Win=64240 [TCP CHECKSUM INCORRECT] Len=0

   8851 17.659108   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [PSH, ACK] Seq=265 Ack=1 Win=65535 Len=21

   8853 17.661356   192.168.100.23        192.168.121.51        TCP      [TCP ACKed lost segment] 3268 > 8081 [ACK] Seq=286 Ack=2581 Win=65535 Len=0

   8854 17.661404   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [FIN, ACK] Seq=2581 Ack=286 Win=64219 [TCP CHECKSUM INCORRECT] Len=0

   8855 17.661605   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [ACK] Seq=286 Ack=2582 Win=65535 Len=0

   8859 17.665981   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [FIN, ACK] Seq=286 Ack=2582 Win=65535 Len=0

   8860 17.666013   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [ACK] Seq=2582 Ack=287 Win=64219 [TCP CHECKSUM INCORRECT] Len=0

 

When I take a closer look, I see that a TCP segment is missing from the list of packets and hence the next frame is displayed with a [TCP ACKed lost segment] comment by Wireshark. Interestingly if I apply the following filter, I can see the frame that’s missing from the TCP conversation:

 

ip.addr==192.168.100.23 and ip.addr==192.168.121.51

 

No.     Time        Source                Destination           Protocol Info

   8852 17.661030   HewlettP_12:34:56     Cisco_12:34:56        IP       Bogus IP length (0, less than header length 20)

 

Frame 8852 (2634 bytes on wire, 2634 bytes captured)

Ethernet II, Src: HewlettP_12:34:56 (00:17:a4:12:34:56), Dst: Cisco_12:34:56 (00:15:2c:12:34:56)

    Destination: Cisco_12:34:56 (00:15:2c:12:34:56)

    Source: HewlettP_12:34:56 (00:17:a4:12:34:56)

    Type: IP (0x0800)

Internet Protocol

    Version: 4

    Header length: 20 bytes

    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

        0000 00.. = Differentiated Services Codepoint: Default (0x00)

        .... ..0. = ECN-Capable Transport (ECT): 0

        .... ...0 = ECN-CE: 0

    Total length: 0 bytes (bogus, less than header length 20)

 

0000  00 15 2c 31 48 00 00 17 a4 77 00 24 08 00 45 00   ..,1H....w.$..E.

0010  00 00 57 d0 40 00 80 06 00 00 c0 a8 79 33 c0 a8   ..W.@.......y3..

0020  64 17 1f 91 0c c4 52 83 a3 f2 a2 a2 06 be 50 18   d.....R.......P.

0030  fa db 5e a2 00 00 48 54 54 50 2f 31 2e 31 20 32   ..^...HTTP/1.1 2

0040  30 30 20 4f 4b 0d 0a 50 72 61 67 6d 61 3a 20 6e   00 OK..Pragma: n

0050  6f 2d 63 61 63 68 65 0d 0a 43 6f 6e 74 65 6e 74   o-cache..Content

0060  2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c   -Type: text/html

0070  3b 63 68 61 72 73 65 74 3d 75 74 66 2d 38 0d 0a   ;charset=utf-8..

0080  53 65 72 76 65 72 3a 20 4d 69 63 72 6f 73 6f 66   Server: Microsof

0090  74 2d 49 49 53 2f 37 2e 35 0d 0a 58 2d 50 6f 77   t-IIS/7.5..X-Pow

...

 

Even though the total length field is set to 0, I see that the IP packet has some payload (probably including a TCP header).

 

The problem occurs because the Wireshark doesn’t fully parse the IP and TCP headers because of total length field in the IP header is 0. This also explains why we don’t see the same packet when TCP filter is applied.

 

After some testing, I realized that this issue could be fixed by setting the following value in Wireshark settings:

 

  

After I enable “Support packet-capture from IP TSO-enabled hardware”, Wireshark also started to correctly display the frames even when the TCP session filter is applied:

 

ip.addr==192.168.100.23 and ip.addr==192.168.121.51 and tcp.port==3268 and tcp.port==8081

 

No.     Time        Source                Destination           Protocol Info

   8771 17.458870   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1

   8772 17.458988   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [SYN, ACK] Seq=0 Ack=1 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 SACK_PERM=1

   8773 17.459239   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [ACK] Seq=1 Ack=1 Win=65535 Len=0

   8774 17.459239   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=264

   8848 17.658922   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [ACK] Seq=1 Ack=265 Win=64240 [TCP CHECKSUM INCORRECT] Len=0

   8849 17.659108   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [PSH, ACK] Seq=265 Ack=1 Win=65535 Len=21

   8850 17.661030   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [PSH, ACK] Seq=1 Ack=286 Win=64219 [TCP CHECKSUM INCORRECT] Len=2580

   8851 17.661356   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [ACK] Seq=286 Ack=2581 Win=65535 Len=0

   8852 17.661404   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [FIN, ACK] Seq=2581 Ack=286 Win=64219 [TCP CHECKSUM INCORRECT] Len=0

   8853 17.661605   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [ACK] Seq=286 Ack=2582 Win=65535 Len=0

   8857 17.665981   192.168.100.23        192.168.121.51        TCP      3268 > 8081 [FIN, ACK] Seq=286 Ack=2582 Win=65535 Len=0

   8858 17.666013   192.168.121.51        192.168.100.23        TCP      8081 > 3268 [ACK] Seq=2582 Ack=287 Win=64219 [TCP CHECKSUM INCORRECT] Len=0

 

When TSO (TCP segmentation offloading) is in place, TCPIP stack doesn’t deal with segmentation at TCP layer and leave it to NIC driver for effienciency purposes. Since Wireshark does see the packet before the NIC, we see the total length as 0 in the packet but when that packet is segmented accordingly by the NIC, there will be correct length field set in the packet. This can also be proved by collecting a network trace at the other end of the session

 

Note: Network Monitor already takes that into account and hence you don’t need to take any corrective action if you’re checking the trace with it.

 

Hope this helps

 

Thanks,

Murat

 

 

Comments
  • While Googling for this exact problem your response was not only my first response, it's exactly what I needed. Thank you for the informative posting!

    Regards,

    Bernie W.

  • I'm glad to hear that it has helped :)

    Thanks,

    Murat

  • Hi Murat,

    I am Usha Iyer, a Senior Acquisition Editor with Packt Publishing. As an Acquisition Editor, it is my role to evaluate, develop and ultimately bring book ideas to publication. I am also responsible for finding the right author for any book; bringing them onboard, then working with them as the book is written.

    I have begun to develop a title on ‘Wireshark Cookbook’, and am now looking for an author to write this book.

    You can find some more information about writing for us at Packt’s website www.packtpub.com/authors.

    Our book ‘BackTrack 4: Assuring Security by Penetration Testing’ book is selling well. We are coming out with more books on network security. Our book will include some recipes for people already familiar with Wireshark framework.

    Please contact me if you are interested in writing this book and I would love to discuss the opportunity with you further.

    Even if you do not want to involve yourself in the project, can you please suggest someone who may suit this project?

    Thanks,

    Usha

    Email: ushai@packtpub.com

  • this is more comprehensive and interesting article. i had also the similar issue, but couldnt figure out that time.

    thanks

  • test

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment