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):