Wireshark-users: [Wireshark-users] packets with capture length in Wireshark larger than configure
From: Andrej van der Zee <andrejvanderzee@xxxxxxxxx>
Date: Thu, 14 Apr 2011 09:38:39 +0900
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)
- Follow-Ups:
- Re: [Wireshark-users] packets with capture length in Wireshark larger than configured MTU
- From: Andrej van der Zee
- Re: [Wireshark-users] packets with capture length in Wireshark larger than configured MTU
- Prev by Date: Re: [Wireshark-users] VoIP RTP Analysis, Lost Packet Analysis
- Next by Date: Re: [Wireshark-users] packets with capture length in Wireshark larger than configured MTU
- Previous by thread: Re: [Wireshark-users] Wireshark-users Digest, Vol 59, Issue 10
- Next by thread: Re: [Wireshark-users] packets with capture length in Wireshark larger than configured MTU
- Index(es):