- This topic has 6 replies, 2 voices, and was last updated 1 month, 3 weeks ago by
.
-
Posts
-
I’ve been using Wiresock/WiresockUI for a good amount of time now. For the last few months, with seemingly no configuration changes made on my side, initiating file transfers over VPN (namely, bittorrent, or any other fast download) produces upwards of 5% loss on the connection, along with ping times to popular services (such as cloudflare) to go from 14ms to 500-2000ms, according to my network hardware, which causes issues for every other machine on the network, and sometimes causes my whole internet connection to become unstable.
I’m running using the virtual adapter, so that I can bind applications to that network interface. I’ve tried messing around with MTU settings, which seem to do either nothing, or make the problem even worse, with the best results being to just comment out the MTU field in my configuration.
Using the regular wireguard for windows client is about the same speed, and doesn’t seem to produce this issue at all. Any ideas on what could be causing this? Nothing in the logs seems to indicate that there’s any funny business going on that I can see.
Edit: I am using the latest versions of both Wiresock and WiresockUI.
It would be helpful to have the console log and PCAP files for further analysis. One possible cause could be that WireSock doesn’t support packet defragmentation, which can lead to issues like the one you’re encountering.
You can check out a recent discussion on a somewhat similar BitTorrent issue here
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.
If logging is enabled, try disabling it to see if it improves performance, as extensive logging can significantly increase latency. For troubleshooting, I recommend using the WireSock CLI directly instead of WireSockUI.
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.
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.
The fragmentation of Wireguard UDP packets is unusual and typically indicates problems with your Wireguard server setup. While it’s possible that these packets could be fragmented along the route, I find this unlikely. If packet fragmentation is occurring, consider adjusting the MTU on both your Wireguard server and client. Packets inside the tunnel can be fragmented and will be reassembled, but it’s uncommon for the Wireguard packets themselves to be fragmented. In my experience, I have not encountered this issue with my servers, although I have received a few complaints about it.
I will consider implementing Wireguard packet defragmentation, but please note that handling packet fragmentation and defragmentation can have a significant performance impact.
- You must be logged in to reply to this topic.