File upload stalling, many "bad" TCP packages

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

stimpy
3 ●2 ●2

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

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...

edit retag flag offensive close merge delete

add a comment

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

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

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?)

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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

File upload stalling, many "bad" TCP packages

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

File upload stalling, many "bad" TCP packages edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

File upload stalling, many "bad" TCP packages