File upload stalling, many "bad" TCP packages

wireshark
ethernet
wifi
speedtest
retag add tags

Hi, I just bought a new LTE / 4g Router for home use (Asus 4G AC53U) and while normal web browsing seems to work just fine, large file uploads do not complete / stall after a very short period of time. Also, when doing a speed test (speedtest.net) I get around 80Mbps download (which seems to be OK) but less than 0.2Mbps upload (the upload seems to stall right after starting the transfer).

$ ./speedtest-cli --no-download
Retrieving speedtest.net configuration...
Testing from Sunrise Communications AG (194.230.158.166)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Swiss Network SA (Lausanne) [2.29 km]: 32.867 ms
Skipping download test
Testing upload speed................................................................................................
Upload: 0.18 Mbit/s

I already tried disabling the router's (and client OS's) firewall, and did a factory reset of the router. Firmware appears to be the latest version (3.0.0.4.382_50399-gcd97187).

My Wireshark dump shows lots of "bad" TCP packets, such as Dup ACK followed by Out-Of-Order and TCP Retransmission, just before the client gives up (timeout?).

It happens on both Ethernet and WiFi connections, with all my computers (Mac, Ubuntu). When using my Android mobile phone though, it works.

What could be the cause of this?

Wireshark dump: https://1fichier.com/?rs7wfjaqy6gecup...

For comparison, this is a wireshark dump of a "good" speedtest (on the same computer, tethering to my mobile phone): https://1fichier.com/?ydj16ver8jdkii3...

stimpy

asked 2019-04-29 06:53:51 +0000

18.5k

SYN-bit

updated 2019-04-29 17:18:04 +0000

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

There seems to be a MTU problem in the upload path. If you filter on "tcp.stream==19", you can see that frame 385 gets acknowledged in frame 429, but non of the following (full-sized) frames get acknowledged. Then when frame 431 is sent (less than a full frame), it gets acknowledged in frame 438. Looking at the SACK values in the TCP options of frame 438, you can see that only up till sequence number 381 is received, plus sequence numbers 14861-15997 (which is exactly what frame 431 sent).

This might be caused by:

A problem within the provider network?
A configuration issue on the LTE/4G router, maybe it should be configured with a lower MTU for our mobile network?

(I need to wait for the 1 hour interval on your filesharing platform before I can look at the other trace, does it use the same SIM card as the LTE/4G router?)

18.5k

SYN-bit

answered 2019-04-29 17:34:55 +0000

edit flag offensive 0 remove flag delete link

Comments

You are right, it does appear to be an MTU problem. Playing around with different values in Ubuntu I managed to get stable transfers with an MTU ~1460 bytes (default was 1500). Unfortunately, the router does not expose a setting for MTU, so I have to configure all my devices separately -- except for the Android phone which seems to work fine with 1500 bytes (!?)

Sorry about the ad-ridden filesharing site. The other trace was done with a different SIM card, but the same provider.

Dankjewel, SYN-bit!

stimpy (2019-05-01 06:11:40 +0000) edit

Graag gedaan! :-)

SYN-bit (2019-05-01 19:26:29 +0000) edit

The Android phone might perform an automatic Path MTU detection when it fails to transfer large packets, learning the best MTU that way.

Jasper (2019-05-03 07:14:27 +0000) edit

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer

File upload stalling, many "bad" TCP packages edit

Comments

1 Answer

Comments