Wireshark · Wireshark-users: Re: [Wireshark-users] packets with capture length in Wireshark larger than configured MTU

[Andrej van der Zee <andrejvanderzee@xxxxxxxxx>]

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@xxxxxxxxx> 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)