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)
