[PigmonkeY]

Doing some more digging, I set the MTU manually back to 1420.  I seemed to be getting no increased latency when downloading.   Then I restarted Wiresock to make sure my changes were actually taking, and all of a sudden the loss is back and network latency is all over the place.

There is DEFINITELY some unintended weirdness going on with Wiresock.

[PigmonkeY]

Disabling logging doesn’t seem to make any change, and having only switched back to wiresockUI recently, in an attempt to get more of a picture of what’s going on, that doesn’t seem to have any effect on the issue, either.

Sadly, looks like packet fragmentation is the issue, and without having any packet defragmentation to speak of, it may be that I need to go back to the official wireguard client.  I’ll trade some overall speed for not having my entire network become unstable.   I guess I’m going to need to relegate Wiresock to use on desktop systems for specifically pointing at a browser or other less intensive workloads.

Thanks for the help.

[PigmonkeY]

Following the solution on that reddit thread, it does seem to have brought the whole network latency down by switching to TCP only, and setting an MTU of 1280.  However, now my wiresockUI client is reporting 10-15% loss, up from 5-10%.

I can’t seem to find the pcap files or console log files anywhere on my system, despite doing a system wide search.

Edit: I can also confirm, after letting the download run for a little bit longer, that this hasn’t solved the network latency issue.  Currently my ping times for the entire network to cloudflare/microsoft are around 400-500ms, up from my standard 10-15ms.

• This reply was modified 1 week, 6 days ago by PigmonkeY.

[Author]

Posts