Linux Client: Latency Tests do not complete or only after a lengthy delay

[redpsalm 0]

Two days ago, I switched to version 2.11.3 to fix the issue with the client disconnecting in a loop. This fixed the problem but now I cannot use the Connect to recommended server button as latency tests do not complete (that was yesterday) or only after a lengthy delay (today - between 3 and 4 minutes). When it starts up, it quickly goes from 150 or so tests to 2 or 1 with the following message: Waiting for latency tests (1 to go). Is there any way around this limitation? Am I doing something wrong?

 

I am using Linux Mint 17.3 and the AirVPN client 2.11.3. I had the Network Lock activated initially but removed it. Below is the log file. The latency tests executed between 10:36:41 and 10:39:40.

 

I 2016.08.04 10:36:38 - Eddie client version: 2.11.3 / x64, System: Linux, Name: Linux Mint 17.3 Rosa \n \l / x64
. 2016.08.04 10:36:38 - Reading options from /home/jp/.airvpn/AirVPN.xml
. 2016.08.04 10:36:39 - Data Path: /home/jp/.airvpn
. 2016.08.04 10:36:39 - App Path: /usr/lib/AirVPN
. 2016.08.04 10:36:39 - Executable Path: /usr/lib/AirVPN/AirVPN.exe
. 2016.08.04 10:36:39 - Command line arguments (1): path="/home/jp/.airvpn"
. 2016.08.04 10:36:39 - Operating System: Unix 3.19.0.32 - Linux Orion 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
I 2016.08.04 10:36:39 - OpenVPN Driver - Found, /dev/net/tun
I 2016.08.04 10:36:39 - OpenVPN - Version: OpenVPN 2.3.2 (/usr/sbin/openvpn)
I 2016.08.04 10:36:39 - SSH - Version: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7, OpenSSL 1.0.1f 6 Jan 2014 (/usr/bin/ssh)
I 2016.08.04 10:36:39 - SSL - Version: stunnel 4.53 (/usr/bin/stunnel4)
! 2016.08.04 10:36:39 - Activation of Network Lock - Linux IPTables
. 2016.08.04 10:36:40 - Updating systems & servers data ...
I 2016.08.04 10:36:40 - Session starting.
W 2016.08.04 10:36:40 - Unable to understand if IPv6 is active.
. 2016.08.04 10:36:41 - Systems & servers data update completed
I 2016.08.04 10:39:40 - Checking authorization ...
! 2016.08.04 10:39:41 - Connecting to Asellus (Netherlands, Alblasserdam)
. 2016.08.04 10:39:41 - OpenVPN > OpenVPN 2.3.2 x86_64-pc-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [iPv6] built on Dec  1 2014
. 2016.08.04 10:39:41 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2016.08.04 10:39:41 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2016.08.04 10:39:41 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.04 10:39:41 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.04 10:39:41 - OpenVPN > Socket Buffers: R=[212992->131072] S=[212992->131072]
. 2016.08.04 10:39:41 - OpenVPN > UDPv4 link local: [undef]
. 2016.08.04 10:39:41 - OpenVPN > UDPv4 link remote: [AF_INET]109.202.107.19:443
. 2016.08.04 10:39:41 - OpenVPN > TLS: Initial packet from [AF_INET]109.202.107.19:443, sid=47215fd0 e5aeef4c
. 2016.08.04 10:39:41 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2016.08.04 10:39:41 - OpenVPN > Validating certificate key usage
. 2016.08.04 10:39:41 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0
. 2016.08.04 10:39:41 - OpenVPN > VERIFY KU OK
. 2016.08.04 10:39:41 - OpenVPN > Validating certificate extended key usage
. 2016.08.04 10:39:41 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2016.08.04 10:39:41 - OpenVPN > VERIFY EKU OK
. 2016.08.04 10:39:41 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org
. 2016.08.04 10:39:41 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.04 10:39:41 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.04 10:39:41 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2016.08.04 10:39:41 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2016.08.04 10:39:41 - OpenVPN > Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
. 2016.08.04 10:39:41 - OpenVPN > [server] Peer Connection Initiated with [AF_INET]109.202.107.19:443
. 2016.08.04 10:39:44 - OpenVPN > SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
. 2016.08.04 10:39:44 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.4.0.1,comp-lzo no,route-gateway 10.4.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.4.27.144 255.255.0.0'
. 2016.08.04 10:39:44 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2016.08.04 10:39:44 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2016.08.04 10:39:44 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2016.08.04 10:39:44 - OpenVPN > OPTIONS IMPORT: route options modified
. 2016.08.04 10:39:44 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2016.08.04 10:39:44 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2016.08.04 10:39:44 - OpenVPN > ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlan0 HWADDR=94:65:9c:f6:8b:6e
. 2016.08.04 10:39:44 - OpenVPN > TUN/TAP device tun0 opened
. 2016.08.04 10:39:44 - OpenVPN > TUN/TAP TX queue length set to 100
. 2016.08.04 10:39:44 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2016.08.04 10:39:44 - OpenVPN > /sbin/ip link set dev tun0 up mtu 1500
. 2016.08.04 10:39:44 - OpenVPN > /sbin/ip addr add dev tun0 10.4.27.144/16 broadcast 10.4.255.255
. 2016.08.04 10:39:49 - OpenVPN > /sbin/ip route add 109.202.107.19/32 via 192.168.1.1
. 2016.08.04 10:39:49 - OpenVPN > /sbin/ip route add 0.0.0.0/1 via 10.4.0.1
. 2016.08.04 10:39:49 - OpenVPN > /sbin/ip route add 128.0.0.0/1 via 10.4.0.1
. 2016.08.04 10:39:49 - Starting Management Interface
. 2016.08.04 10:39:49 - OpenVPN > Initialization Sequence Completed
I 2016.08.04 10:39:49 - /etc/resolv.conf renamed to /etc/resolv.conf.airvpn as backup
I 2016.08.04 10:39:49 - DNS of the system updated to VPN DNS (Rename method: /etc/resolv.conf generated)
I 2016.08.04 10:39:49 - Flushing DNS
I 2016.08.04 10:39:49 - Checking route
I 2016.08.04 10:39:50 - Checking DNS
! 2016.08.04 10:39:50 - Connected.
. 2016.08.04 10:39:50 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2016.08.04 10:39:50 - OpenVpn Management > >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
. 2016.08.04 10:46:42 - Updating systems & servers data ...
. 2016.08.04 10:46:43 - Systems & servers data update completed

[LZ1 672]

Hello !

 

Is your firewall blocking ICMP packets by any chance? If something is blocking the Air ICMPs, you could try allowing them. Because the Air client has to ping its servers to get their latency and thus order things in relation to what's recommended . If it can't, that might explain why your connect to recommend doesn't work. Oh and please use spoiler tags for your logs in the future. They're so minimalist and snazzy ;D

 

Sent to you from me with datalove

[Staff 9972]

Two days ago, I switched to version 2.11.3 to fix the issue with the client disconnecting in a loop. This fixed the problem but now I cannot use the Connect to recommended server button as latency tests do not complete (that was yesterday) or only after a lengthy delay (today - between 3 and 4 minutes). When it starts up, it quickly goes from 150 or so tests to 2 or 1 with the following message: Waiting for latency tests (1 to go). Is there any way around this limitation? Am I doing something wrong?

 

Hello!

 

We can reproduce this issue and at a first glance it might be a Mono 4 bug. To circumvent it, do not try to connect to any server until the "latency tests" are complete. To see the status of such tests click the "Stats" tab and look at "Pinger stats". If they are stuck at 2 or 1 to go, double click on "Pinger Stats" and you should see that the tests are re-started and completed in very few seconds.

 

The developers have worked hard to circumvent the numerous bugs in Mono 4 (especially. but not only, in WinForms) but some intrinsic bugs are impossible to bypass completely. For this reason, the developers have planned a massive migration to GTK+ (especially for the UI) for Eddie "branch" 3, at least in GNU/Linux.

 

Kind regards