TCP (only) packet loss

[#1]

Hi,
I seem to be having very strange issues, whereby I am only getting TCP packet loss (as ICMP ping shows 0% packet loss)
I tried calling up support, and obviously they weren't technical enough to help me.
They said that they tried to switch on and off the firewall on my connection, but that had no effect and hence I am here.
I also looked into switching the firewall of on the Technicolor TG582n, but it seems that the firewall option is locked for the average Joe.
Can I somehow flash this thing to allow me tweaking all the settings?
PCAP dumps of two separate SSH connections to two separate machines in two separate countries:
https://dl.dropboxusercontent.com/u/51316125/SSH.pcap
https://dl.dropboxusercontent.com/u/51316125/SSH2.pcap
Also TCP flow if you haven't got a PCAP reader:
https://dl.dropboxusercontent.com/u/51316125/SSH%20Flow.txt
https://dl.dropboxusercontent.com/u/51316125/SSH%20Flow2.txt
Any ideas how to debug this, or who to try and contact?
Is there something like MTR but via TCP?
Because the only solution I can see for now is switching providers which I'd prefer not to do.
Thanks!

[#2]

Also, I'll add to the bill that the router is acting weird, whereby it just decides to reboot at random points during the day, but it did that before, and I didn't have this issue I am having in the past week.
I have now also found how to disable the firewall via CLI, so we will see if this helps at all.

[#3]

Bump.
MTR and screenshots attached, showing that ICMP packets are fine, but TCP just choke.
I obviously tried other destinations, so it's not a matter of the destination

[#4]

Hi Jammer,
I'm sorry that our Technical Support Team weren't able to help.
You've mentioned that the router randomly reboots which is a bit odd - although this has been happening for some time, it is possible that the router is faulty and has got worse over time which may have start causing this problem.
I've sent our a replacement router for you to connect to see if this clears things up for you. If it doesn't, let us know ad we'll do some more digging for you.

[#5]

Hi Chris,
Thanks for that, it's very nice that someone actually cares, I will let you know if it helps.
Are there any other level 3 devices (apart from the router) along the way that could be causing the issue?
Thanks!

[#6]

No problem at all.
Not anything that I can think of. I'll have a chat with our Network/Products Team and if there's anything we can think of, I'll get back to you though.

[#7]

Does the Packet Loss only occur on SSH or does it happen on other TCP traffic?
Would you be able to provide some further Wiresharks that are a little longer with some more traffic on it at all?

[#8]

It's not only SSH, anything that uses TCP seems to start dropping out. Obviously its most noticeable in SSH.
I have no issues providing further Wireshark dumps, just let me know what filter you want me to set, and how long you want me to run them for, also, do you want me to dump any particular services, or destinations?
I could even have a TCP SYNs based ping to the hops along the way, to find the hop where the issue happens, if you tell me some TCP the port numbers on the hops along the way.

[#9]

What happens if you ping with a larger packet size?
eg if on fibre:
ping -f -l 1464 -t 84.45.109.112
eg If on ADSL:
ping -f -l 1472 -t 84.45.109.112

[#10]

So I am on the new router now, and the packet loss is not happening at the moment (it was never a permanent thing).
If it continues with the new router, I will try larger packets to see if there is some problems with MTU along the way.
Also, something that caught my eye while setting up the new router:

Quote

Link Information Uptime: 0 days, 0:02:21 DSL Type: ITU-T G.992.5 Bandwidth (Up/Down) [kbps/kbps]: 440 / 23,293 Data Transferred (Sent/Received) [kB/MB]: 983.41 / 7.21 Output Power (Up/Down) [dBm]: 10.9 / 0.0 Line Attenuation (Up/Down) [dB]: 3.9 / 8.5 SN Margin (Up/Down) [dB]: 32.7 / 3.0 System Vendor ID (Local/Remote): TMMB / ---- Chipset Vendor ID (Local/Remote): BDCM / IFTN Loss of Framing (Local/Remote): 0 / 0 Loss of Signal (Local/Remote): 0 / 0 Loss of Power (Local/Remote): 0 / 0 Loss of Link (Remote): - Error Seconds (Local/Remote): 1 / 0 FEC Errors (Up/Down): 0 / 32 CRC Errors (Up/Down): 0 / 1 HEC Errors (Up/Down): 0 / 0

The uplink looks very very tragic, and I bet that could be the case why TCP packets start getting dropped, as 440k can be very easily consumed by any background application such as uploading an email attachment or a skype call.

[#11]

Contact support and they will remove the upstream cap.

[#12]

Why would they put a cap in the first place? Perhaps that's the limitation of the link that I am seeing?

[#13]

It's because once upon a time, someone found that their line was less stable without the cap or something like that, and ever since then they're terrified that it might be worse if everything was uncapped. And occasionally someone might even still incorrectly state that the uncapping would reduce your download speed.

[#14]

In my case that was the case (line unstable) but once the line fault had been sorted it was OK
Note that the line fault needed about 4 engineer visits to sort and they never did find the actual cause just switched me to a different line from the exchange to the cab

[#15]

@Jammer - I've just got the order placed for your upload to be uncapped. I would expect to see a noticeable difference tomorrow morning.