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

TCP packets being combined on the way to a server

0

Hi there!

I have the following scenario:

Client <-> Tunnel <-> VPN Server <-> FileServer

The client is requesting a file on a fileserver on the internet (ubuntu hosted in windows azure cloud) through a VPN that is terminated the VPN server (hosted in Germany at a different provider).

Now when performing this download I have a very strange effect: on the client and on the file server packets are only being sent with max packet length 1390 which is fine.

Nonetheless, when performing TCPDUMP traces on the VPN server I suddenly see occasional jumbo frames that exceed the allowed packet length of 1390. Suddenly there are TCP packets that have a length of twice the allowed packet size and the TCP segments are also combined accordingly. This is causing a coughup on the VPN server causing the connection to drop. But I cant see the fileserver sending those jumbo frames.

I assume that those jumbo frames were not transmitted over the internet, so the ubuntu fileserver on windows azure probably didnt sent them out, but maybe a loadbalancing/optimizing element in the datacenter of the VPN server? is that actually possible? Would an intermediate network element be able to combine multiple TCP packets that were originally sent from a location to a single jumbo framed packet?

This is the capture on the VPN server: alt text

And this is the capture on the file server: alt text

I can also upload the packet traces if required.

Thanks & Best Regards Qiong Wu

asked 28 May '14, 14:17

Freundschaft's gravatar image

Freundschaft
15115
accept rate: 0%

edited 28 May '14, 14:18


One Answer:

3

This may be a problem of where and how you are capturing the packets. I wrote a new blog post recently that explains some of those effects you mention here:

http://blog.packet-foo.com/2014/05/the-drawbacks-of-local-packet-captures/

answered 29 May '14, 02:26

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

good point, but is there actually any way of verifying whether this is connected with TCP optimization done on the local system or actual data on the line being too large? As far as I get it from your post, the only thing I can do is connect a TAP and check whats REALLY going over the line. Thanks for the input!

(29 May '14, 08:18) Freundschaft

well, if you did capture locally on a system that gives you strange results (like oversized packets) it is a safe bet that this is the reason.

A dead giveaway of TCP optimization is if the TCP checksum is 0. Everything else is hard to say.

(29 May '14, 08:39) Jasper ♦♦

thanks a lot for the help! I'll mark the answer as correct answer.

(30 May '14, 04:34) Freundschaft

by the way: I have another question, if I use a virtual TAP device to mirror the traffic on the network interface that I want to monitor and capture on that interface, would I also produce these side effects?

(02 Jun '14, 01:56) Freundschaft