Wireshark mailing list archives
Re: packets with capture length in Wireshark larger than configured MTU
From: Andrej van der Zee <andrejvanderzee () gmail com>
Date: Thu, 14 Apr 2011 14:29:39 +0900
Hi, To answer my own question, and for others facing the same issue, this looks like large/generic receive offload to the NIC and can be switched off with ethtool, although this will most likely result in higher CPU utilisation. In my case it messes with my algorithm for reassembling TCP streams which relies on TCP seq and ack numbers, it seems. Best regards, Andrej On 2011/04/14, at 9:38, Andrej van der Zee <andrejvanderzee () gmail com> wrote:
Hi, I am using Ubuntu Maverick (kernel 2.6.35-25) with the following config for eth0: eth0 Link encap:Ethernet HWaddr b8:ac:6f:99:6d:be inet addr:85.17.148.22 Bcast:85.17.148.255 Mask:255.255.255.0 inet6 addr: fe80::baac:6fff:fe99:6dbe/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:126634506 errors:0 dropped:0 overruns:0 frame:0 TX packets:100914149 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:88690663907 (88.6 GB) TX bytes:66274092073 (66.2 GB) Interrupt:16 Memory:da000000-da012800 It sais MTU of 1500. When I capture in Wireshark I see packets which are much larger than the 1500 (see below). I am wondering how this is possible. Thank you, Andrej No. Time Source Destination Protocol Info 61 09:19:15.599088 85.17.148.22 175.105.93.20 HTTP HTTP/1.1 200 OK (application/x-amf) Frame 61 (8478 bytes on wire, 8478 bytes captured) Arrival Time: Apr 14, 2011 09:19:15.599088000 [Time delta from previous captured frame: 0.030731000 seconds] [Time delta from previous displayed frame: 0.030731000 seconds] [Time since reference or first frame: 14.020010000 seconds] Frame Number: 61 Frame Length: 8478 bytes Capture Length: 8478 bytes [Frame is marked: False] [Protocols in frame: eth:ip:tcp:http:media] [Coloring Rule Name: Checksum Errors] [Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || mstp.checksum_bad==1] Ethernet II, Src: Dell_99:6d:be (b8:ac:6f:99:6d:be), Dst: All-HSRP-routers_12 (00:00:0c:07:ac:12) Destination: All-HSRP-routers_12 (00:00:0c:07:ac:12) Address: All-HSRP-routers_12 (00:00:0c:07:ac:12) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Dell_99:6d:be (b8:ac:6f:99:6d:be) Address: Dell_99:6d:be (b8:ac:6f:99:6d:be) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 85.17.148.22 (85.17.148.22), Dst: 175.105.93.20 (175.105.93.20) 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: 8464 Identification: 0xd304 (54020) Flags: 0x02 (Don't Fragment) 0.. = Reserved bit: Not Set .1. = Don't fragment: Set ..0 = More fragments: Not Set Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0x513e [correct] [Good: True] [Bad : False] Source: 85.17.148.22 (85.17.148.22) Destination: 175.105.93.20 (175.105.93.20) Transmission Control Protocol, Src Port: http (80), Dst Port: 52787 (52787), Seq: 2671789300, Ack: 2723574492, Len: 8412 Source port: http (80) Destination port: 52787 (52787) [Stream index: 3] Sequence number: 2671789300 [Next sequence number: 2671797712] Acknowledgement number: 2723574492 Header length: 32 bytes Flags: 0x10 (ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgement: Set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 116 Checksum: 0x16a8 [incorrect, should be 0xbea6 (maybe caused by "TCP checksum offload"?)] [Good Checksum: False] [Bad Checksum: True] [Expert Info (Error/Checksum): Bad checksum] [Message: Bad checksum] [Severity level: Error] [Group: Checksum] Options: (12 bytes) NOP NOP Timestamps: TSval 474870612, TSecr 789164 [SEQ/ACK analysis] [Number of bytes in flight: 8412] Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n] [Message: HTTP/1.1 200 OK\r\n] [Severity level: Chat] [Group: Sequence] Request Version: HTTP/1.1 Response Code: 200 Date: Thu, 14 Apr 2011 00:19:15 GMT\r\n Server: Apache/2.2.16 (Ubuntu)\r\n Cache-Control: no-cache\r\n Expires: Sat, 25 Dec 1999 00:00:00 GMT\r\n Pragma: no-cache\r\n Content-Length: 13087\r\n [Content length: 13087] Keep-Alive: timeout=15, max=97\r\n Connection: Keep-Alive\r\n Content-Type: application/x-amf\r\n \r\n Media Type Media Type: application/x-amf (8129 bytes)
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- packets with capture length in Wireshark larger than configured MTU Andrej van der Zee (Apr 13)
- Re: packets with capture length in Wireshark larger than configured MTU Andrej van der Zee (Apr 13)