This is a static archive of our old Q&A Site. Please post any new questions and answers at

TCP packet length was much greater than MTU


I am a newbie with TCP, MTU (which I have to play around with) and Wireshark. I sent some data that was over 100k over tcp and used Wireshark to view and confirm the data that I sent. I assume each Wireshark frame corresponds to a TCP segment, am I correct? I noticed the length of some of the frames were 1514, which looked correct, because MTU was 1500 plus some bytes for headers. However, some of the frame lengths were much higher, such as 5xxx, 1xxxx. Why was that the case..? I thought all the frames (the ones about data sent from my machine to the remote server) would be 1514.

I also added the column "Packet Length" and thought maybe that column would report TCP segment size and I noticed the numbers in that column were the same as the numbers in the column "Length". What's the difference between "Packet Length" and "Length"?

asked 14 Sep '13, 19:23

wiresharknewbie's gravatar image

accept rate: 0%

One Answer:


Probably you captured on the host that transmitted the oversized packet, and TCP Large Segment Offload is enabled. (Sometimes abbreviated TSO and sometimes LSO.) The operating system is passing packets larger than MTU to the network adapter, and the network adapter driver is breaking them up so that they fit within the MTU. If you capture from the wire, instead of from an endpoint involved in the communication, you will see that the packets are correctly sized when they are transmitted. This is one reason of several to capture from the wire, instead of on an endpoint.

TSO is a performance enhancement, but you can turn it off, in which case, the OS will no longer generate oversized frames.

To show the size of the TCP segment, add a custom column using the field "tcp.len".

answered 14 Sep '13, 21:52

Jim%20Aragon's gravatar image

Jim Aragon
accept rate: 24%

Thanks a bunch! Follow-up questions - how can I capture from the wire?

I tried to add a custom column using the field "tcp.len" but I don't see the field "tcp.len" in the menu. I am using 1.6.7 on Ubuntu. Maybe the older version doesn't have that field?

(15 Sep '13, 01:08) wiresharknewbie

It's a custom field, which means there is no hard-coded column setting for it. You need to create a custom column. The easiest way to do this is to find a packet with that field, right-click on it and select "Apply as Column".

Capture on the Wire means using an additional capture device on a TAP or SPAN port. See

(15 Sep '13, 06:28) Jasper ♦♦

Thank you for pointing out the document! TAP or SPAN won't be my option so I will try disabling offload to see if that solves the problem. I tried to get tcp.len to show as column, but I was only able to get frame.len, ip.len, data.len to show. I was not able to find a field under the "Transmission Control Protocol" section about length even though the heading of that section included "Len" (Transmission Control Protocol, Src Port: 123 (123), Dst Port: 456 (456), Seq: 789, Ack: 1, Len: 1448)

(15 Sep '13, 15:18) wiresharknewbie

tcp.len is a hidden field, so it won't appear in the packet details pane unless you enable hidden fields to be displayed. So you can either:

  1. Enable hidden fields via: Edit -> Preferences -> Protocols -> Display hidden protocol items, and then do the right-click -> Apply as column trick that Jasper pointed out, or
  2. Manually add the tcp.len field via: Edit -> Preferences -> Columns -> Add -> Field type: Custom, Field name: tcp.len -> [click title and rename from Custom to something else like TCP Len] -> [drag & drop new column to desired location] -> OK
(15 Sep '13, 16:46) cmaynard ♦♦

Awesome - thanks so much for pointing out TCP Segment length is a hidden field! I followed 1 and now I have TCP Segment length as a column.

(15 Sep '13, 23:56) wiresharknewbie

Sounds great...EXCEPT, I set a column for frame.len > 1500 and saw lengths of 4540B, 5094b and even 22734. And, I am using a span port in a 3750x. Is the span doing something goofy??

(25 Nov '14, 10:47) dribniff
showing 5 of 6 show 1 more comments