Not much info here to go on. If you searched for the specific errors you’re hitting and got no recent results then it’s probably not a known problem.

If you want to troubleshoot the problem, post the specific steps you’re taking, and the results you get. Include error output. And relevant logging if possible.

If you only want very general comments, then I would say “rolling release” and “just works” aren’t always in perfect alignment. More updates and more package versions interoperating on your machine over time will lead to (usually minor) problems. So it might be worth considering if this is a problem you want to invest time in.

I have been running Tumbleweed for a few years and haven’t hit any major app install problems. Only had a handful of very minor update issues. But I’ve not tried to install this specific program.

Cool, thanks. I’ll take a look.

I have heard that. Can it be given run conditions, like only on wifi, and respecting the Android battery saving setting?

My phone has an always on split tunnel VPN to home, so the other sync devices are always accessible. Without the Syncthing-Fork run conditions it chews through mobile data and battery.

Same here. It was already a little bit concerning that I was relying on a smaller fork to get syncthing on Android. It was on my to do list to figure out options. Now it’s at the top of the list, and I’m not doing updates for the time being on Android. That’s almost the entirety of my reliance on syncthing - phone to PC sync. I don’t really need it that much for sync between PCs.

Just throwing out more ideas:

Is there a CPU spike on the VPS?

Anything weird about Wireguard on either end? Using kernel mode WG everywhere and not a user mode version, right?

As a test I would be inclined to try a very small mtu to see if it makes a difference. 1280 is a failsafe that I use when on unknown networks and trying to wg out.

Maybe try with a smaller packet size, like 1KB which I think is -l 1K

Are you specifying bandwidth (-b) on the iperf UDP test? It defaults to 1M if I recall correctly, which would explain the result.

If not, try -b 10M or -b 0 for unlimited (the behavior used for TCP).