stavefajl

joined 2 years ago
[–] stavefajl 1 points 2 weeks ago

Thanks for the suggestions.

I see no CPU spike on the VPS, and no CPU spikes on the clients.
I use WG started by root using wg-quick via systemctl on all devices.
I tried setting the MTU to 1280, with no significant changes, apart from slight slowdown compared to MTU of 1420 or 1440.
Smaller packet size also resulted in slightly lower speeds.

I used tcpdump on both client and server to find the negotiated MSS, and it shows an MSS of 1460 outside wg tunnel, so by following the calculations shown in this article https://www.procustodibus.com/blog/2022/12/wireguard-performance-tuning/, 1440 is the correct MTU for the wireguard interface when using IPv4 inside the tunnel.

[–] stavefajl 1 points 2 weeks ago

I had to borrow a phone to set up a mobile hotspot.
It has the same speeds inside the wireguard tunnel as when I tested from my wired connection (250 kbps TCP, 170 kbps UDP).
The loss reported by iperf is dependent on the bandwidth that i test with. But as I increase bandwidth from the client the loss grows towards 100%.

I tried testing in reverse (sending from VPS to devices on different networks) with surprising results:

  • TCP, wireguard: 5-10 mbps
  • UDP, wireguard: 50 mbps
  • TCP, no wireguard: 45 mbps
  • UDP, no wireguard: 250 mbps (saturates download speed on client when compared to speedtest.net)
[–] stavefajl 5 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

Thanks! I had not read the manpage close enough, I guess.
When specifying the bandwidth, I can saturate the connection using UDP to around 15 Mbits/s. (That this speed is much much lower than the 300-500 Mbits my connection and the VPS is capable of is a problem for a different time, I think).

What I also realized is, that I had not put the iperf server in UDP-mode, so my results reported in another comment are wrong.
I read the results from the client, but the server did not respond.
When running the iperf server in UDP-mode, I get 15 Mbits/s outside the wireguard tunnel and 180 Kbits/s inside the tunnel. With TCP-mode I get 10-15 Mbits/s outside the thunnel and 250 Kbits/s inside the tunnel.

[–] stavefajl 1 points 2 weeks ago (2 children)

I am currently running mtr from multiple devices:

  • in wireguard tunnel: single hop 10.1.1.1, loss% 0,1, avg ping 27.4 ms
  • outside wg between same devices:
    • ISP supplied modem/router 55% loss, avg ping 1.6 ms
    • multiple hops without loss, avg ping 16-20 ms
    • random intermediary 30 % loss, avg ping 20 ms
    • endpoint, 5% loss, avg ping 25 ms

It looks like across the board my ISP modem / router is dropping 50-80 % of packets, and that packet loss is ramping up from 4% to 80 percent after a few minutes of running mtr.
It also looks like my VPS endpoint climbs to 20% packet loss over time (5-15 minutes of testing).

Can I use this information to probe further into the devices I have access to (ISP modem and VPS)?

[–] stavefajl 1 points 2 weeks ago
[–] stavefajl 1 points 2 weeks ago* (last edited 2 weeks ago)

I'm on linux on all devices. I tested packet fragmentation using:
ping -M do -s [packet size] [ip]
No fragmentation using packet size 1472 and below (before wireguard overhead).

[–] stavefajl 1 points 2 weeks ago (2 children)

I just tested again:

  • no wireguard, tcp: 9.75 Mbits/s
  • no wireguard, udp: 1.05 Mbits/s
  • wireguard, tcp: 248 Kbits/s
  • wireguard, udp: 1.05 Mbits/s

So, I get the "full" udp speed, but I get some errors / warnings about 'connection refused' and 'did not receive ack'. Obviously not correctly configured, when it is 10 times slower than tcp.

 

Hello I hope one of you can help point me in the right direction.

I have a VPS with a static IP and a wireguard tunnel from VPS to home network (no bridging in the router, just point-to-point with specific devices).

I found an abysmal connection speed with bandwidth on the order of 50-100 kbps tested via iperf. Connection between the same devices outside the wireguard tunnel is 10-20 mbps, which is 100-400 times slower, which I don't understand since wireguard usually has very little overhead.

I have tried different MTU settings on both VPS and devices on my home network (both cabled and via wi-fi) in the range from 1360 to 1460, and above speeds are the best I have reached with MTU 1420 and 1440. I have tried both with and without iptables rules setting the mss correspondingly.

The above speeds are acceptable for incremental backups and document synchronization, but completely unsuitable for media streaming.

Where would I start diagnosing the bottleneck?

Thanks in advance.

UPDATE 2025-10-09:
I have not figured the issue out yet, and I do not know where to go from here.
I found a single similar issue (asymmetric wireguard speeds) here: https://forum.openwrt.org/t/wireguard-client-upload-slowness/190772, but that was resolved by changing MTU.

It must be a VPS issue, since when testing from multiple clients on different networks and locations, the bandwidth from client to server does not vary.
I have tried MTU from 1280 to 1460. Current best settings, MTU = 1440 on client and server, and an iptables rule:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu.

Via tcpdump I have confirmed that the two endpoints negotiates an mss of 1460 (outside wireguard), making an MTU of 1420 to 1440 appropriate for the wireguard tunnel.

UDP without wireguard can saturate network connection.
TCP without wireguard has about 50-60% slowdown compared to UDP.
Bandwidth from vps to client is decent inside wireguard tunnel.
Bandwidth from client to vps inside wireguard tunnel is still abysmal.

Current speeds UDP:

  • UDP, no wireguard: 16 mbps (client to vps) (at the time of testing, saturates client connection upload)
  • UDP, no wireguard: 270 mbps (vps to client) (at the time of testing, saturates client connection download)
  • UDP, wireguard: 80 kbps (client to vps)
  • UDP, wireguard: 106 mbps (vps to client) Current speeds TCP:
  • TCP, no wireguard: 8 mbps (client to vps)
  • TCP, no wireguard: 117 mbps (vps to client)
  • TCP, wireguard: 280 kbps (client to vps)
  • TCP, wireguard: 4 mbps (vps to client)
[–] stavefajl 6 points 1 month ago

Som SorteKanin nævner er fightchatcontrol et godt sted at starte og finde kontaktoplysninger. Jeg vil lige overveje om jeg deler min oprindelige mail, for så sidder der i princippet nogle nøglemedarbejdere og 15 politikere og kan kæde min 'anonyme' onlineidentitet direkte sammen med mit navn uden at skulle gætte og formode. Ikke at jeg er paranoid og i praksis er jeg ligeglad lige nu, men det virker fjollet at opgive privatliv når vi netop diskuterer retten til privatliv. Jeg kan selvfølgelig ikke vide om de mailsvar jeg allerede har delt herinde indeholder individualiseret tegnsætning eller lignende. Jeg vil dog også gerne dele mine tanker og realitetsteste min argumentation. Det kan være at svar følger når jeg kommer hjem :)

 

Jeg har modtaget svar på min henvendelse til MEP Morten Løkkegaard om chatkontrol. Som kun den tredje ud af femten. Han er i hvert fald ikke fan. Ingen fortalere har svaret, men det er jo også det vi ser i medierne. Modstanderne har konkrete argumenter og fortalerne har vage floskler.

" Tak for din mail og for at dele dine tanker og bekymringer om forslaget til CSA-forordningen – også kendt som chatkontrol.   Lad mig starte med at sige det meget klart: Jeg er selv meget bekymret over udsigten til chatkontrol.   Der kan naturligvis ikke være tvivl om, at vi skal tage stærke og effektive skridt for at bekæmpe seksuelt misbrug og deling af overgrebsmateriale med børn. Det er samtidig vigtigt, at vores grundlæggende rettigheder ikke undermineres, og at der skabes grobund for masseovervågning.   Jeg mener, at forslaget om chatkontrol udfordrer helt fundamentale principper som retten til privatliv, brevhemmelighed og individets frihed. At give beskedtjenesterne mulighed for at scanne al online kommunikation, som kan ende hos myndighederne, uden nødvendigvis at der har været en forudgående konkret mistanke, er efter min mening uforeneligt med et frit og åbent samfund. Det går stik imod mit liberale verdenssyn, hvor individet skal beskyttes mod statslig overvågning, ikke omvendt.   Jeg og mange andre medlemmer af Europa-Parlamentet har gentagne gange udtrykt skepsis, fordi forslaget ikke bare kompromitterer frihedsrettighederne, men potentielt også kan åbne døren for misbrug af overvågningsteknologier og gøre os mere sårbare overfor hackere og fjendtlige regimer. Det går simpelthen for vidt!   Kampen mod overgreb på børn skal føres med gennemsigtige, proportionale og retsstatslige værktøjer. Effektiv beskyttelse af børn og respekt for individets frihedsrettigheder må ikke blive hinandens modsætninger. I mit arbejde i Europa-Parlamentet arbejder jeg for at finde netop den balance, og det vil jeg blive ved med.   Endnu en gang tak, fordi du skrev og for at dele din bekymring. "

[–] stavefajl 7 points 1 month ago (1 children)

Kunne vi please få nogle flere eksperter i almindelige nyheder der fortæller om hvorfor det rent teknisk er dumt?

[–] stavefajl 4 points 2 months ago

Støttet. Jeg har i øvrigt stadig kun fået svar fra to af de dansker parlamentarikere SLM jeg skrev til på mail. Vi nærmer os snart 1. September, og der følger jeg i hvert fald op med mail til alle som ikke har svaret. Vi har indtil videre kun hørt vage ikke-svar fra de som støtter forslaget.

[–] stavefajl 2 points 2 months ago (1 children)

Ja, man burde kunne få lov at aflevere i pdf-format, medmindre underviseren insisterer på at rette opgaven i Words 'track changes'. Jeg har personligt kun oplevet undervisere der bliver glade over at se flot typografi fremfor Word.

[–] stavefajl 4 points 2 months ago

Jeg er primært på lydbøger eller fysiske bøger. E-bøger bruger jeg kun til arbejde, videnskabelig litteratur og tekniske opslag. Men jeg har hørt godt om Calibre til linux der fungerer som bibliotek og server for diverse klienter. Det skulle have mulighed for fjerne nogle former for DRM.

view more: next ›