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

MSS=1460, but the packet length=7306

0

I wanted to understand how the process of exchanging data works, and according to the info I found on the internet, when two points want to transmit data, they do the three-way handshake and set some options. There's one concerning MSS, and both machines sent value of 1460. But when you look at the following image, you can see that the packet size is way above the limit. I know that you should also add 20+20+14 for headers, but 7306 >> 1514.

Take a look at the picture: wireshark 7306

There's also no fragmentation:

no fragmentation

MTU size on both systems is the same (1500), so does anyone could explain this behavior?

asked 30 Jun '15, 03:32

morfik's gravatar image

morfik
11226
accept rate: 0%


One Answer:

3

Likely down to Large Segment Offload (or TSO) where the NIC splits the traffic into MTU sized frames.

Your capture point is before the NIC has split the data. Try capturing off-machine using a span or mirror port on a switch to see the "real" traffic.

answered 30 Jun '15, 03:43

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%

Thanks to the information that grahamb provided, I manage to figure out where the "problem" was.

I was using LXC container, it's something like a virtual machine, and according to this article , TSO/LSO is used for better performance of the virtual systems or the whole working station.

I check whether the virtual interfaces have the TSO/LSO option set, and they have:

# ethtool -k veth10-sid  | grep "tcp-segmentation-offload"
tcp-segmentation-offload: on

This is just one of the ends of the tunnel. So if someone wanted to have (for instance for testing purposes) "normal size" of the packets, he could turn that option off on both ends, using the following command:

# ethtool -K veth10-sid tso off
# ethtool -k veth10-sid  | grep "tcp-segmentation-offload"
tcp-segmentation-offload: off

And now the packets have 1514 bytes in length.

(30 Jun '15, 04:12) morfik

note: converted your answer to a comment to the answer of @grahamb and changed the acceptance to his answer as it was the one that helped.

(30 Jun '15, 09:47) Jasper ♦♦

It's weird that the comment is the real answer. The info that grahamb provided was useful. It pointed me in the right direction, but that wasn't the answer to the question. Besides, if I wanted to comment the answer, and I thought it satisfied me, I would just post a comment: "it works, thx" -- which means absolutely nothing to the people who read this question. In the "comment" you have the right solution how to change some settings in linux and what exactly caused the problem, which was lxc.

(30 Jun '15, 11:31) morfik

Your question was (paraphrased) "why are my segments too big" and "can anyone explain this behaviour", I answered that. Marking my answer as "Accepted" helps others with the same question.

You didn't indicate that you wanted to be rid if the large segments, nor did you let on that this was on a VM. If you had done so the answer would be different.

(30 Jun '15, 12:14) grahamb ♦

I didn't even know that LXC would matter, so how could I include that in the question? You just gave me general info, and there was nothing concerning LXC containers either. Your answer just pointed me in the right direction, but it was actually me who provided the info what exactly caused the packet to have more bytes and how to disable/enable the TSO feature for the LXC container's interfaces (in the case that someone was asking himself whether there's a possibility to do so). So I don't really think this should be a comment.

(01 Jul '15, 06:23) morfik
1

@grahamb did give you the most probably root cause of the issue (and actually the right one). Your question was general and you got a general (valid) answer. From this point of view, his response is perfectly valid and should be identified as the right one for anyone doing a query for an issue with MTU (as your initial question and keywords indicated).

Your did find what was the right technical configuration required for your use case, but that will not always be applicable to other users (especially as your initial question and keywords did not make any reference to LXC.

(01 Jul '15, 07:51) Pascal Quantin
showing 5 of 6 show 1 more comments