ANSWERED Eddie constantly disconnecting/reconnecting

[SeUbHS 3]

This issue started occurring this afternoon on both my linux virtualbox and my Windows 10 host (these are on two separate physical computers). I've attached the logs for the linux machine here, but please let me know if there's any other info you need. I removed some the 2xxx ipv6 addresses from the logs since that was recommended to me last time for privacy. edit: oh, and it appears to be happening at the same time on my phone as well which is connected to wifi (VPN never worked on my phone when connected to carrier network). All 3 devices use different airvpn servers. I'd check the router, but it belongs to my roommate. The internet is still accessible through regular wifi without a vpn on.

eddie_logs.txt

[OpenSourcerer 1435]

Have you tried the TCP protocol?

[SeUbHS 3]

10 minutes ago, OpenSourcerer said:

Have you tried the TCP protocol?

Trying it on linux now. I'll  comment if I notice tcp is stable. Tried setting to tcp on my phone as well under settings>airvpn>default protocol and settings>vpn>transport protocol, but it says it's still using udp under connection status.

[OpenSourcerer 1435]

3 minutes ago, SeUbHS said:

Tried setting to tcp on my phone as well under settings>airvpn>default protocol and settings>vpn>transport protocol, but it says it's still using udp under connection status. 

Probably because there are two locations for these settings. The first is in the Settings (automatic settings for quick connect and connect at boot), the other in AirVPN Server > Gear symbol > Connection options (which are used when tapping on a server).

[SeUbHS 3]

6 minutes ago, OpenSourcerer said:

Probably because there are two locations for these settings. The first is in the Settings, the other in AirVPN Server >

Thanks, found it. Didn't make a difference connecting to mobile carrier over VPN, but not disconnects so far on using wifi+vpn on either device <knock on wood>
unimportant update: regarding phone not connecting to carrier I found servers on port 53 using the setting you suggested and this managed to connect using phone internet+vpn ;)

[SeUbHS 3]

On 8/29/2021 at 2:51 PM, OpenSourcerer said:

Probably because there are two locations for these settings. The first is in the Settings (automatic settings for quick connect and connect at boot), the other in AirVPN Server > Gear symbol > Connection options (which are used when tapping on a server).

So it's been a few days and it seems like using tcp 443 instead of udp 443 was the solution (still having issues with udp). What reasons could cause this to suddenly change like that on different operating systems?

[OpenSourcerer 1435]

Your system, your router or your ISP started limiting UDP traffic. You could also try other ports with UDP to see if it's a general UDP thing or limited to port 443.

[SeUbHS 3]

On 9/1/2021 at 11:06 PM, OpenSourcerer said:

Your system, your router or your ISP started limiting UDP traffic. You could also try other ports with UDP to see if it's a general UDP thing or limited to port 443.

I just realized this, but I've been getting packet loss every few minutes. Is it possible that TCP is more resistant to this, hence why I don't disconnect constantly unlike with UDP?

[OpenSourcerer 1435]

2 hours ago, SeUbHS said:

Is it possible that TCP is more resistant to this, hence why I don't disconnect constantly unlike with UDP?

Packet loss is a phenomenon that happens in both protocols but the user directly notices this only with UDP.
TCP packets must be transmitted and received in order, checked for integrity and the correct reception of each and every TCP packet acknowledged by the peer. Should anything be amiss, such as a packet loss, the packet must be resent. This allows for highly "stable" connections and to have a general sense of the state of such a connection. If it goes stale, programs can initiate measures to reconnect right away or do other things, like notifying the user or so.

UDP is connectionless. It's design is "fire and forget". It doesn't require an active connection, it doesn't care if sent packets are received at all. Packets are sent, and sent, and sent. Some of the ways for either parties to notice the connection is "lost" is if special keepalive packets stop coming or if a timeout on either party's side runs out. Too many lost packets and either side can assume the other side "lost connection". Which is not a real connection, but still.

Now, in the context of OpenVPN this may suggest that TCP is the superior choice and we all should use it. But it's not. For TCP to be able to provide all that cool retransmission logic more info must be stored in the packet header, which limits how much data can be transmitted in a single packet more than in UDP. We call this a "higher overhead". Also, since TCP is all about reliability, if your internet connection happens to be somewhat unstable, TCP limits transmission of packets to ensure this reliability. This leads to throughput limitations, or what people commonly call "slow speeds". The thing is: Inside OpenVPN's protocol for the tunnel there's data transmitted over either TCP or UDP as well, such as a website download or a video conference. And TCP still works as always: If a packet is lost, the packet is retransmitted. On an unstable internet link, OpenVPN's TCP would limit the throughput, which leads to the web server limiting throughput, in exceptionally bad cases of unstable internet possibly to the point where the browser loses the connection to the web server; the TCP-over-TCP problem.
UDP is a better idea: If OpenVPN's UDP loses a packet, a UDP connection in the tunnel will be treated as if a UDP packet is lost (no effect, in essence, maybe a lost frame in the video conference), and any TCP connection will simply retransmit the packet because it's how TCP works. For a minority of users, though, TCP may be a better idea if UDP is either rate-limited (you know, connectionless, difficult to track, can fill up bandwidth this way, blahblah) or blocked entirely.

Generally, it makes sense looking into it to find out why UDP performs this way and only use TCP if there's really no other way. Hope it clears things up a little.

[Staff 9972]

Quote

UDP is a better idea: If OpenVPN's UDP loses a packet, a UDP connection in the tunnel will be treated as if a UDP packet is lost (no effect, in essence, maybe a lost frame in the video conference)

And you avoid the TCP over TCP meltdown effect, i.e. when "lower and upper layers (which both are running their own version of congestion control algorithm) start competing with each other and in fact worsening the situation at each try. This is specially true for slow links and could result in terribly slow connections and constant freezing". https://hamy.io/post/0002/openvpn-tcp-or-udp-tunneling/

[SeUbHS 3]

On 9/6/2021 at 6:00 AM, Staff said:

And you avoid the TCP over TCP meltdown effect, i.e. when "lower and upper layers (which both are running their own version of congestion control algorithm) start competing with each other and in fact worsening the situation at each try. This is specially true for slow links and could result in terribly slow connections and constant freezing". https://hamy.io/post/0002/openvpn-tcp-or-udp-tunneling/

Unfortunately, the VPN only stays connected for less than a minute before disconnecting, reconnecting, and rinse/repeat no matter which protocol is used now. So far I've tried several different servers using udp 80, udp 41185 ip 3, tcp 443 ip 3, udp 443 ip 3, and maybe some other protocols. Is it possible these are issues on airvpn's end?

[OpenSourcerer 1435]

10 hours ago, SeUbHS said:

Is it possible these are issues on airvpn's end?

No, no one else creates threads with this issue or randomly finds this thread and starts posting "I have the same issue" posts. Problem's with you, or what's between you and AirVPN.
You can always post a support file from Eddie, you know… (Logs > lifebelt icon).

[SeUbHS 3]

21 minutes ago, OpenSourcerer said:

No, no one else creates threads with this issue or randomly finds this thread and starts posting "I have the same issue" posts. Problem's with you, or what's between you and AirVPN.
You can always post a support file from Eddie, you know… (Logs > lifebelt icon).

Here's another log. This time, it disconnected 2 times 11 minutes apart right after I got on the computer basically. I think I notice it disconnect more often when my roommates are using the internet. Regular wifi internet without airvpn is fine for me like I said (just a packet loss every 2 minutes or so which disconnects me from game servers).

eddie_log.txt

[OpenSourcerer 1435]

Log of TCP, I should've added. Sorry.

[SeUbHS 3]

On 9/8/2021 at 12:36 PM, OpenSourcerer said:

Log of TCP, I should've added. Sorry.

Just want to update that this problem stopped occurring shortly after I posted (minus a random disconnect here and there), so that's why I haven't been able to upload a TCP log. If it begins happening again, I'll be sure to post the tcp logs.

[OpenSourcerer 1435]

Thank you.