VPN connection 'dies' if available data rate has gone low for a while

[narration-sd]

Issue report

Operating system: Windows 11, Android 14, iPadOS 17.1.x latest, it's moving...

App version: latest which I think is 2023.5 on all, except I'm on betas with the iPad. Doesn't matter; it's been this way a very long time...

Issue description

Here's what happens. I have a not-great internet-wifi arrngement which I can't access, save for restarts via power cut/restore which I control via a smart plug.

• The situation is that internet access speed drops to a trickle once or more during a typical day. I recover it via power cycle
• Mullvad also loses its speed when this happens, but quite often does not recover once the connection is good again.
• when Mullvad is bad, I can fix it 100% by selecting a different egress server location
• switching to a server at the same location most often will not work for this
• however, I discovered that dropping the Mullvad connection for tens of seconds, then reconnecting, I often get the speed back
• when I use this last procedure, I can watch the speed come back up during a speed test run ... and often can get signifiicantly more speed by doing a second run.
• there's one more symptom I may just have observed again, perhaps coming up with the latest app versions. It's a big delay, seconds, before an otherwise fast connection comes up and runs. Like refreshing a page -- several seconds, and then the rush we recognize when the data is then coming in fast.

A couple of helpful notes for the surround:

• the laptop in particular is new and very fast in every regard, very well maintained. For data, last night I saw a 300Mbps rate, rather topping out the wifi/cable box, and the subscription.. The phone (Pixel) and iPad are also great.
• while this Mullvad-wifi-cable-internet-Mullvad-endpoint situation is working, most of the time in a day, I get 120-200 Mbps speed. - - with some background in protocols, what happens with Mullvad not recovering looks a lot like speed negotiation -- that it lowered the rate since the channel was trickling, and then often will not raise it when the channel is back. Hence my change-servers or disconnect-pause-reconned-VPN routines, discovered the usual way....
• problems like this have been with Mullvad since I started using it several years ago. I think some of them were improved, but this one has remained, and you have to thin kit is severe, considering especially non-technically aware persons. Or some who are :)

I'm otherwise very pleased with Mullvad -- your practices around VPN feel excellent, and you run a worldwide service that can be very helpful. Many things about the software have settled down.

So I'm hoping you can run this problem down as well. It's the sort of thing you ought to be able to simulate conditions for easily (just slope the allowed data rate towards zero for a while would be a great beginning), at least if it isn't some kind of bullet this consumer-level cable business (one of the largest) sends you that bollixes things up. Your 'box' should be proof from bad results of any such insults, presume you'd agree.

Ok, that's what I can give you. There are no logging abilities, or I'd send you those.

Kind regards, and a nice thought towards Scandinavian seasons, Clive

[Serock3]

Hello! I am sorry you had to wait so long for a response. We have made some improvements to the relay connection procedure since 2023.5, are you still experiencing this issue with new latest version?

[narration-sd]

Hello Sebastian, and Chalmers, eh? I have heard of this, from a long alumni :)

I'm definitely having much less problem this way. It may be your fix, but also I cleaned up what had been beleaguring my wifi -- an access point turned into a repeater which was actually causing many reconnects if not other problems.

If there is anything left of this issue, it's something I looked into actually yesterday, where the wifi and apparent Mullvad are present, but seem to take increasingly long times to start up connecting a fresh website link in browser, or other connections. I found that latency seemed to have gone up considerably, and went back down again if I moved to another Mullvad server in the same city.

Once the connection was firm, bandwidth seemed quite good itself - measuring 120-150 Mbps, as is reliable day for day now. But maybe latency influenced the handshake to start SSL connections, or something of the sort? And that the latency seemed to go down to normal on fresh server.

All this is less than firm, as I'd also been using some more distant and less prominent servers, like Salt Lake City instead of Los Angeles, for example (I'm in San Diego). The reason is the re-use of IP addresses by your server farms -- the LA ones in particular of 200, 300 etc. map as Romanian ones to, I presume, websites using out-of-date lists because those are cheap.

Maybe this will give you ideas to think about, but again, the basic nitrate-dies-to-near-nothing is not experienced now, for months. I changed that repeater about the time you announced the protocol alterations in your betas, so I can't be sure whether one or both fixed that, apologies.

Thanks again for the update -- appreciated you got back on this.

Clive