Specific website loading slow, can my wireshark log help?

asked 2024-04-25 11:30:43 +0000

fordina1
1 ●3

updated 2024-05-22 02:26:31 +0000

Since moving from europe to asia, I have sometimes have problems connecting to a specific website, which I have to access regularly.

The problem seems to be on my side (probably router/IPS problem), since the website works normal for other users from europe, but I have problems from asia (chrome gives me the error "err_connection_reset" and the website stops loading)

I tried many things already, but cannot find a solution so far.

Here is the log: [removed]

P.S. the first 6 packages can be ignored, since they were from a previous capture and I don't know how to remove them!

EDIT:

mtupath shows the following:

MTU path scan to agenturtipp.de (85.13.165.58), ttl=64, limit=48
26 best MSS 1024 (estimated MTU 1052) [pPPPP*ppppppppppP**P**P***]


        #1 MSS IN RANGE     1 <==  1023 ==>  1024
        #2 SCAN TIMEOUT  1025 <==   439 ==>  1464
        #3 MSS EXCEEDED  1465 <== 14919 ==> 16384

[WARNING] Possible PMTU blackhole in route to peer

Thank you !

Edit 30th April:

The problem still occurs after setting lower MTU :( Here is a new anonymized wireshark log: https://we.tl/t-72S99n4PHf

MTU settings in cmd: https://i.imgur.com/Aa3u2wC.jpeg

MTU settings in my router cannot be set to 1052: https://i.imgur.com/HysrxIA.jpeg Do you think that might affect the MTU settings I set in the cmd? Or should the cmd setting be enought?

Edit 1st May: mtr to the server:

    |------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |  893 |  893 |    0 |    0 |    9 |    0 |
|                   h254.s98.ts.hinet.net -    0 |  893 |  893 |    0 |    1 |   10 |    2 |
|       168-95-162-94.tpn2-3301.hinet.net -    0 |  893 |  893 |    0 |    2 |   38 |    2 |
|        220-128-9-54.tpdb-3031.hinet.net -   16 |  555 |  470 |    1 |    2 |   12 |    1 |
|     220-128-13-93.r4102-s2.tp.hinet.net -    1 |  889 |  888 |    1 |    2 |   43 |    2 |
|     220-128-6-109.r4002-s2.tp.hinet.net -    0 |  893 |  893 |    0 |    3 |   86 |    8 |
|        202-39-91-29.pa-r32.us.hinet.net -    0 |  893 |  893 |  134 |  136 |  192 |  138 |
|        202-39-84-29.pa-r31.us.hinet.net -    0 |  893 |  893 |  134 |  136 |  176 |  140 |
|                              4.7.18.145 -  100 |  180 |    1 |    0 |  137 |  137 |  137 |
|        ae2.3603.edge4.ber1.neo.colt.net -    0 |  893 |  893 |  280 |  282 |  306 |  281 |
|    NEUE-MEDIEN.edge4.Berlin1.Level3.net -    0 |  893 |  893 |  286 |  288 |  327 |  287 |
|                   dd49318.kasserver.com -    0 |  893 |  893 |  282 |  283 |  294 |  284 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

4.7.18.145 seems to lose all packets. A MTU scan and pinging seems to work fine though:

MTU path scan to 4.7.18.145, ttl=64, limit=48
# 16 processing - best MSS 1024 (estimated MTU 1052) [pPPPPPpppppppppp]
# 01 nearest minimum MTU on local interface

        #1 MSS IN RANGE     1 <==  1023 ==>  1024
        #2 MSS EXCEEDED  1025 <== 15359 ==> 16384


ping 4.7.18.145

Ping wird ausgeführt für 4.7.18.145 mit 32 Bytes Daten:
Antwort von 4.7.18 ...

(more)

edit retag flag offensive close merge delete

Comments

Could you please share the file in PCAP or PCAPNG format instead of text output, we love using Wireshark for a reason ;-)

SYN-bit ( 2024-04-26 07:41:36 +0000 )edit

Oh yeah, my bad. I anonymized it: https://we.tl/t-IPz3lxhrDM Thank you!

fordina1 ( 2024-04-26 08:01:23 +0000 )edit

Thanks for adding the link to the pcapng file!

SYN-bit ( 2024-04-26 10:25:13 +0000 )edit

add a comment

answered 2024-04-26 10:30:36 +0000

SYN-bit

18376 ●9 ●309 ●255 https://SYN-b.it

A quick analysis shows that there is a huge amount of packet-loss. It does not seem to be MTU related, as the advertised MSS is working fine for a lot of packets and the segments missing seem to be of the same size (1452).

This leaves me to think there is a really bad link between you and the server somewhere. Or, based on your mtupath output, there could be multiple paths from the server towards you where one path has a lower MTU. It does need to be a packet switched path though, as normally loadbalancing over links is done flow based so that all packets follow the same path.

You could try to set your MTU size to a really low value (you mtupath output suggests to use 1024 instead of the current 1492). If that helps, you might want to increase it till it breaks again and keep using that MTU as a workaround.

edit flag offensive delete link

Comments

Thanks. I used netsh interface ipv4 set subinterface Ethernet mtu=1052 store=persistent to decrease mtu and will test it for a while. Should it be 1052 or 1024? I am not sure. I know the 28 bytes are headers and stuff.

fordina1 ( 2024-04-26 10:47:52 +0000 )edit

You are correct in that it needs to be 1052 (so my 1024 above was not correct, although it could not hurt for the test). I assume the 1024 in the output relates to the payload length of the ICMP packet, which will be preceded by the ICMP header (8 bytes) and the IP header (20 bytes), resulting in an MTU of 1052.

The mtupath tool mentioned MSS, but IMHO MSS is used for TCP only where a TCP segment of 1024 bytes would be preceded by the TCP header (20 bytes) and the IP header (20 bytes), resulting in an MTU of 1064.

But as the tool suggests 1052, I assume they (ab)use the term MSS also for ICMP packets.

SYN-bit ( 2024-04-26 11:24:32 +0000 )edit

Thank you, I will try a few days and report back :)

fordina1 ( 2024-04-29 03:22:44 +0000 )edit

Sadly, the problem occured again :( I updated my original post. Any help is appreciated!

fordina1 ( 2024-04-30 01:55:35 +0000 )edit

So, MTU problem is ruled out. What does an mtr trace to the destination show? Any hop that introduces packet-loss? You might want to use a packet size of 1000 or higher to get a bit of representative output...

SYN-bit ( 2024-04-30 18:20:11 +0000 )edit

Updated my initial post. What do you mean packet size of 1000 or higher? My MTU is still set to 1052.

fordina1 ( 2024-05-01 02:48:20 +0000 )edit

As MTU did not seem to be the problem, it can be set back to the original value (1500, or was it 1492?). That way, larger packets can be used in mtr. The reason for using larger packets is if there is a tiny bit of CRC errors on one of the intermediate links, the chance of getting a CRC error on a packet is higher.

Another thing to try is to use TCP packets in mtr, as icmp does not seem to trigger dropped packets.

All-in-all very strange that packet loss is introduced in the path from the server to you. Have you contacted the site owner about this issue? Might they have a policy for traffic coming from asia?

SYN-bit ( 2024-05-01 07:02:13 +0000 )edit

I just did a ping test myself to the server, it only responds to pings with a payload of 1024 bytes or less. So that's why the mtupath tool showed a low MTU, while in fact the path MTU is higher (as seen in the packet captures of the TCP traffic)

SYN-bit ( 2024-05-01 07:07:59 +0000 )edit

MTU was 1500 on windows side and the router seems to have a default of 1492. I set my windows setting to 1492 now as well. The server is mine and according to the hosting company there is no restriction whatsoever. Is the > 1024 no respond from the server a problem? As I said, there definitely is no problem for other visitors, just for me (which is 99% the distances/routing fault I assume) How can I use TCP packets in MTR? If there is bad routing, there is no way for me to fix it, right? I have to contact my ISP?

fordina1 ( 2024-05-02 02:04:00 +0000 )edit

The no response on large pings should not be a problem. Is it always slwo for you, or just sometimes? It could be that the packet-loss is there for evenyone, but as your round-trip time seems to be ~250ms, it could effect you more than others (packet loss will reduce your congestion window, and you can only transmit one congestion window per round-trip, so the higher your roundtrip time, the lower the throughput with a small congestion window).

How often do you have this slowness? I just tried myself again and see no packet-loss.

SYN-bit ( 2024-05-20 07:03:14 +0000 )edit

It's not always slow. I would say 5-10% of the requests are slow. Sometimes it could work for a few hours or even a day, and then the problem occurs again. Would a non-slow/normal wireshark report help in any way (for comparison with the broken one)?

fordina1 ( 2024-05-21 02:57:11 +0000 )edit

Yes, that would help as a comparison. Also, it would help to run the mtr command at a time when it is slow. The packet-loss might just be there occasionally. Are you sure you are not overloading your Internet connection at those times (backgroup backups, downloads, updates etc)?

SYN-bit ( 2024-05-21 20:44:47 +0000 )edit

I just did some more tests and it seems that the packet-loss is there for me too this time. As my RTT is ~30ms, the website still loads fine. But the same packet-loss with your ~280ms RTT will make it 9 times as slow.

This is because only one congestion window can be transferred per RTT.

You might want to check with the website hoster if there is packet-loss in their uplink? Or if there is bandwidth throttling in place?

SYN-bit ( 2024-05-21 21:08:11 +0000 )edit

Wow, thats good to know. Could you provide me some screenshot or trace from your package loss, so I can show the hoster? You are located in the Netherlands, right?

fordina1 ( 2024-05-22 00:49:08 +0000 )edit

@SYN-bit I uploaded a working page load report from wireshark. Please check my original post (Edit 22nd May). Thank you so much!

fordina1 ( 2024-05-22 02:27:10 +0000 )edit

see more comments

Specific website loading slow, can my wireshark log help?

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Specific website loading slow, can my wireshark log help? edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Specific website loading slow, can my wireshark log help?