Freigeben über

Bogus IP packets and Wireshark

  • Artikel

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

  • Anonymous
    January 01, 2003
    I'm glad to hear that it has helped :) Thanks, Murat

  • Anonymous
    March 18, 2011
    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.

  • Anonymous
    October 06, 2011
    The comment has been removed

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

  • Anonymous
    May 12, 2014
    test

  • Anonymous
    November 09, 2014
    Just ran into this issue today. Thanks a lot for the tip.