Specific website loading slow, can my wireshark log help?

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

fordina1
1 ●1

updated 2024-05-01 02:47:57 +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

18344 ●9 ●304 ●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

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?