EclecticFish 5 Posted ... (edited) 20 hours ago, Clodo said: @EclecticFish @IG-11 @st4r Your ping/latency issue is under investigation, but currently we can't reproduce it, see my results in attachment (my results matches ping from cmdline). - Ping engine is used to determine server score, hence it isn't updated when VPN is connected, it is only when not connected. - Seems an issue reported only by Windows users. Please tell me more if possible, focus on "Castor" for example: when Eddie starts, your latency result compared to real (ping 91.207.57.114 for Castor)? If you close Eddie and reopen, do you obtain almost the same result? In "Stats" tab, there is "Pinger stats": a double-click on it resets all ping results and restarts testing, should it be useful. Thanks for any feedback. Hi, thanks for responding and investigating. "- Seems an issue reported only by Windows users." No, I'm using Linux, please refer to my first post.Ping - In my first post I observed that despite the high latency suggested by the Eddie client, the actual pings from the command line were good.Ping results for Castor from within VPN tunnel. i.e. Eddie up and running. ~$ ping 91.207.57.114 PING 91.207.57.114 (91.207.57.114) 56(84) bytes of data. 64 bytes from 91.207.57.114: icmp_seq=1 ttl=54 time=31.6 ms 64 bytes from 91.207.57.114: icmp_seq=2 ttl=54 time=31.4 ms 64 bytes from 91.207.57.114: icmp_seq=3 ttl=54 time=31.4 ms 64 bytes from 91.207.57.114: icmp_seq=4 ttl=54 time=31.4 ms 64 bytes from 91.207.57.114: icmp_seq=5 ttl=54 time=31.3 ms 64 bytes from 91.207.57.114: icmp_seq=6 ttl=54 time=32.0 ms 64 bytes from 91.207.57.114: icmp_seq=7 ttl=54 time=31.4 ms ^C --- 91.207.57.114 ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6008ms rtt min/avg/max/mdev = 31.321/31.516/31.987/0.210 ms As expected, nothing wrong with that at all. Closing the tunnel before ping test won't tell me anything in this case. The issue, for me at least, is with the misleading information the GUI is providing with 2.20.6, not the performance. As you can see Eddie finds an extra 400ms from somewhere. How can that happen? This never happened before 2.20.6 At least, not for virtually all servers at the same time. Now the result after double clicking pinger stat. Useful tip, thanks. The latency column is cleared for all servers but not repopulated. To repopulate the latency field, I disabled the connection via Eddie then reconnected to the same server. I notice that you are using 2.20.8 according to your screenshot. Thanks Edited ... by EclecticFish Quote Share this post Link to post
IG-11 5 Posted ... @Clodo 20 hours ago, Clodo said: - Ping engine is used to determine server score, hence it isn't updated when VPN is connected, it is only when not connected. Oh, I see. Thanks for the clarification. Did some tests as you suggested. Castor server, 91.207.57.114: - real ping (Eddie closed), 3 tries: 35, 33, 35 ms - Eddie results for the same server (restarted it 3 times as well): 77, 84, 72 ms Maybe it'll be helpful as well but what I also noticed is that when Eddie shows abnormally high latency - for multiple servers such results are roughly the same Quote Share this post Link to post
Staff 9971 Posted ... New version 2.21.8 This release follows the stable version 2.21.6 by fixing some minor issues. Released as stable. This was an urgency release to resolve common issues discovered. Other issues also reported in this topic are under evaluation. [bugfix] [windows] "Network interface no more available" in some situation [change] [linux/macOS] Hummingbird available also in High Sierra [change] [linux] eddie-tray updated to GTK3 (cleaning dependencies issue) [bugfix] [all] Minor bugfixes Quote Share this post Link to post
EclecticFish 5 Posted ... Attempted install of 2.21.8sudo apt-get install eddie-ui Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies. eddie-ui : Depends: libayatana-appindicator3 but it is not installable E: Unable to correct problems, you have held broken packages. Interesting. Apt cleanup didn't resolve it. Quote Share this post Link to post
BlueBanana 39 Posted ... Hi, installation fails on Ubuntu 22.04:root@RYZEN3950X:/home/bomb/Desktop# gdebi "/home/bomb/Downloads/eddie-ui_2.21.8_linux_x64_debian.deb" Reading package lists... Done Building dependency tree... Done Reading state information... Done Reading state information... Done This package is uninstallable Dependency is not satisfiable: libayatana-appindicator3 Is there a solution ? Regards BB Quote Hide BlueBanana's signature Hide all signatures AMD Ryzen 3950X @ 105W PPL Gigabyte X570 Aorus Elite Nvidia RTX 4070 Ti Super Corsair DDR4-3200 32GB Share this post Link to post
Clodo 176 Posted ... @EclecticFish @BlueBanana please wait, our fault, will be fixed as soon as possible. 2 EclecticFish and BlueBanana reacted to this Quote Share this post Link to post
Clodo 176 Posted ... 16 hours ago, Clodo said: @EclecticFish @BlueBanana please wait, our fault, will be fixed as soon as possible. @EclecticFish @BlueBanana fixed, please perform an "apt-get update" or re-download the .deb. 1 EclecticFish reacted to this Quote Share this post Link to post
EclecticFish 5 Posted ... 6 hours ago, Clodo said: @EclecticFish @BlueBanana fixed, please perform an "apt-get update" or re-download the .deb. I had a system notification this morning that the update was now available. Super smooth update this time via the software updater. Thanks. The latency column issue persists but we knew this update wasn't going to fix that. Last night Eddie disconnected and elected to connect to what it thought was the lowest latency server As this was on another continent it was in reality a higher latency option. This is more likely to occur with laptops connected via wireless. This afternoon I updated another machine, from an older version of Eddie to 2.21.8. Initially this gave a mix of normal and very high latencies. This being a bit inconsistent, I shut down the session and forced a recalculation. This time all the figures were high, as per this machine. Both running Linux. I don't have time to check on a Windows machine just now. Quote Share this post Link to post
***** 1 Posted ... 2.21.8 still stuck at verifying IPv4 route Does this have something to do with all incoming/outgoing connections blocked prior to enabling network lock? In 2.20.0 and prior versions, this was never an issue. Eddie System/Environment Report - 5/27/2022 - 8:03 PM UTC Eddie version: 2.21.8 Eddie OS build: linux_x64 Eddie architecture: x64 OS type: Linux OS name: Linux Mint OS version: 19.3 (Tricia) OS architecture: x64 Mono /.Net Framework: 4.6.2 (Debian 4.6.2.7+dfsg-1ubuntu1); Framework: v4.0.30319 OpenVPN: 2.4.4 - OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 (/usr/sbin/openvpn) Hummingbird: Not available WireGuard: 1.0.20201112 SSH: OpenSSH_7.6p1 Ubuntu-4ubuntu0.7, OpenSSL 1.0.2n 7 Dec 2017 (/usr/bin/ssh) SSL: stunnel 5.44 (/usr/bin/stunnel4) curl: 7.58.0 (/usr/bin/curl) Profile path: /home/user1/.config/eddie/default.profile Data path: /home/user1/.config/eddie Application path: /usr/lib/eddie-ui Executable path: /usr/lib/eddie-ui/eddie-ui.exe Command line arguments: (2 args) path.resources="/usr/share/eddie-ui" path.exec="/usr/bin/eddie-ui" Network Lock Active: Yes, Linux iptables Connected to VPN: No OS support IPv4: Yes OS support IPv6: Yes Detected DNS: 127.0.0.53 Test DNS IPv4: Failed Test DNS IPv6: Failed Test Ping IPv4: Failed Test Ping IPv6: Failed Test HTTP IPv4: Error: curl: (28) Connection timed out after 20001 milliseconds Test HTTP IPv6: Error: curl: (7) Couldn't connect to server Test HTTPS: Error: curl: (6) Could not resolve host: eddie.website ---------------------------- Important options not at defaults: login: (omissis) password: (omissis) remember: True netlock: True netlock.allow_private: False netlock.allow_ping: False network.entry.iplayer: ipv4-only network.ipv6.mode: block network.ipv4.autoswitch: True pinger.enabled: False ui.skip.provider.manifest.failed: True ---------------------------- Logs: . 2022.05.27 12:59:27 - Eddie version: 2.21.8 / linux_x64, System: Linux, Name: Linux Mint, Version: 19.3 (Tricia), Mono/.Net: 4.6.2 (Debian 4.6.2.7+dfsg-1ubuntu1); Framework: v4.0.30319 . 2022.05.27 12:59:27 - Command line arguments (2): path.resources="/usr/share/eddie-ui" path.exec="/usr/bin/eddie-ui" . 2022.05.27 12:59:27 - Raise system privileges . 2022.05.27 12:59:31 - Reading options from /home/user1/.config/eddie/default.profile . 2022.05.27 12:59:32 - OpenVPN - Version: 2.4.4 - OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 (/usr/sbin/openvpn) . 2022.05.27 12:59:32 - SSH - Version: OpenSSH_7.6p1 Ubuntu-4ubuntu0.7, OpenSSL 1.0.2n 7 Dec 2017 (/usr/bin/ssh) . 2022.05.27 12:59:32 - SSL - Version: stunnel 5.44 (/usr/bin/stunnel4) . 2022.05.27 12:59:32 - curl - Version: 7.58.0 (/usr/bin/curl) ! 2022.05.27 12:59:33 - Activation of Network Lock - Linux iptables I 2022.05.27 12:59:33 - Ready . 2022.05.27 12:59:33 - Cannot retrieve information about AirVPN: curl: (7) Couldn't connect to server I 2022.05.27 13:00:03 - Session starting. I 2022.05.27 13:00:03 - Checking authorization ... . 2022.05.27 13:00:04 - IPv6 disabled on network adapter (default) . 2022.05.27 13:00:04 - IPv6 disabled on network adapter (enp4s0) . 2022.05.27 13:00:04 - IPv6 disabled on network adapter (wlp3s0) ! 2022.05.27 13:00:04 - Connecting to Virgo (United States of America, Phoenix, Arizona) . 2022.05.27 13:00:04 - Routes, skipped for 193.37.254.13 : IPv4 Net gateway not available. . 2022.05.27 13:00:04 - Routes, skipped for 193.37.254.13 : IPv4 Net gateway not available. . 2022.05.27 13:00:04 - OpenVPN > OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022 . 2022.05.27 13:00:04 - OpenVPN > library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 . 2022.05.27 13:00:04 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2022.05.27 13:00:04 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2022.05.27 13:00:04 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2022.05.27 13:00:04 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2022.05.27 13:00:04 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]193.37.254.13:443 . 2022.05.27 13:00:04 - OpenVPN > Socket Buffers: R=[212992->212992] S=[212992->212992] . 2022.05.27 13:00:04 - OpenVPN > UDP link local: (not bound) . 2022.05.27 13:00:04 - OpenVPN > UDP link remote: [AF_INET]193.37.254.13:443 . 2022.05.27 13:00:04 - OpenVPN > TLS: Initial packet from [AF_INET]193.37.254.13:443, sid=3708f782 e2578afd . 2022.05.27 13:00:04 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2022.05.27 13:00:04 - OpenVPN > VERIFY KU OK . 2022.05.27 13:00:04 - OpenVPN > Validating certificate extended key usage . 2022.05.27 13:00:04 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2022.05.27 13:00:04 - OpenVPN > VERIFY EKU OK . 2022.05.27 13:00:04 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Virgo, emailAddress=info@airvpn.org . 2022.05.27 13:00:04 - OpenVPN > Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA . 2022.05.27 13:00:04 - OpenVPN > [Virgo] Peer Connection Initiated with [AF_INET]193.37.254.13:443 . 2022.05.27 13:00:05 - OpenVPN > SENT CONTROL [Virgo]: 'PUSH_REQUEST' (status=1) . 2022.05.27 13:00:05 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.33.110.1,dhcp-option DNS6 fde6:7a:7d20:1d6e::1,tun-ipv6,route-gateway 10.33.110.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:1d6e::102f/64 fde6:7a:7d20:1d6e::1,ifconfig 10.33.110.49 255.255.255.0,peer-id 0,cipher AES-256-GCM' . 2022.05.27 13:00:05 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2022.05.27 13:00:05 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS 10.33.110.1' . 2022.05.27 13:00:05 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:1d6e::1' . 2022.05.27 13:00:05 - OpenVPN > Pushed option removed by filter: 'tun-ipv6' . 2022.05.27 13:00:05 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:1d6e::102f/64 fde6:7a:7d20:1d6e::1' . 2022.05.27 13:00:05 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2022.05.27 13:00:05 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2022.05.27 13:00:05 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2022.05.27 13:00:05 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2022.05.27 13:00:05 - OpenVPN > OPTIONS IMPORT: peer-id set . 2022.05.27 13:00:05 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2022.05.27 13:00:05 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2022.05.27 13:00:05 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2022.05.27 13:00:05 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2022.05.27 13:00:05 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2022.05.27 13:00:05 - OpenVPN > TUN/TAP device tun0 opened . 2022.05.27 13:00:05 - OpenVPN > TUN/TAP TX queue length set to 100 . 2022.05.27 13:00:05 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 . 2022.05.27 13:00:05 - OpenVPN > /sbin/ip link set dev tun0 up mtu 1500 . 2022.05.27 13:00:05 - OpenVPN > /sbin/ip addr add dev tun0 10.33.110.49/24 broadcast 10.33.110.255 . 2022.05.27 13:00:10 - OpenVPN > Initialization Sequence Completed . 2022.05.27 13:00:10 - DNS of the system updated to VPN DNS (Rename method: /etc/resolv.conf generated) . 2022.05.27 13:00:10 - Routes, add 0.0.0.0/1 for interface "tun0". . 2022.05.27 13:00:10 - Routes, add 128.0.0.0/1 for interface "tun0". . 2022.05.27 13:00:10 - Routes, add 193.37.254.11/32 for interface "tun0". . 2022.05.27 13:00:10 - Routes, skipped for 2a0d:5600:2:5:a1cc:337e:25cc:9027 : IPv6 blocked. . 2022.05.27 13:00:10 - Flushing DNS I 2022.05.27 13:00:10 - Checking route IPv4 . 2022.05.27 13:01:17 - Checking route (4° try) . 2022.05.27 13:01:41 - Checking route (5° try) E 2022.05.27 13:02:01 - Checking route IPv4 failed, last reason: curl: (28) Connection timed out after 20000 milliseconds ! 2022.05.27 13:02:01 - Disconnecting . 2022.05.27 13:02:01 - Sending soft termination signal . 2022.05.27 13:02:01 - OpenVPN > event_wait : Interrupted system call (code=4) . 2022.05.27 13:02:01 - OpenVPN > SIGTERM received, sending exit notification to peer . 2022.05.27 13:02:07 - OpenVPN > Closing TUN/TAP interface . 2022.05.27 13:02:07 - OpenVPN > /sbin/ip addr del dev tun0 10.33.110.49/24 . 2022.05.27 13:02:07 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting . 2022.05.27 13:02:07 - Routes, delete 0.0.0.0/1 for interface "tun0", not exists. . 2022.05.27 13:02:07 - Routes, delete 128.0.0.0/1 for interface "tun0", not exists. . 2022.05.27 13:02:07 - Routes, skipped for 193.37.254.13 : IPv4 Net gateway not available. . 2022.05.27 13:02:07 - Routes, delete 193.37.254.11/32 for interface "tun0", not exists. . 2022.05.27 13:02:07 - Routes, skipped for 2a0d:5600:2:5:a1cc:337e:25cc:9027 : IPv6 blocked. . 2022.05.27 13:02:07 - Routes, skipped for 193.37.254.13 : IPv4 Net gateway not available. . 2022.05.27 13:02:07 - IPv6 restored on network adapter (default) . 2022.05.27 13:02:07 - IPv6 restored on network adapter (enp4s0) . 2022.05.27 13:02:07 - IPv6 restored on network adapter (wlp3s0) . 2022.05.27 13:02:07 - DNS of the system restored to original settings (Rename method) . 2022.05.27 13:02:07 - Connection terminated. I 2022.05.27 13:02:10 - Checking authorization ... . 2022.05.27 13:02:11 - IPv6 disabled on network adapter (default) . 2022.05.27 13:02:11 - IPv6 disabled on network adapter (enp4s0) . 2022.05.27 13:02:11 - IPv6 disabled on network adapter (wlp3s0) ! 2022.05.27 13:02:11 - Connecting to Acamar (United States of America, Miami) . 2022.05.27 13:02:11 - Routes, skipped for 173.44.55.157 : IPv4 Net gateway not available. . 2022.05.27 13:02:11 - Routes, skipped for 173.44.55.157 : IPv4 Net gateway not available. . 2022.05.27 13:02:11 - OpenVPN > OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022 . 2022.05.27 13:02:11 - OpenVPN > library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08 . 2022.05.27 13:02:11 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2022.05.27 13:02:11 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2022.05.27 13:02:11 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2022.05.27 13:02:11 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2022.05.27 13:02:11 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]173.44.55.157:443 . 2022.05.27 13:02:11 - OpenVPN > Socket Buffers: R=[212992->212992] S=[212992->212992] . 2022.05.27 13:02:11 - OpenVPN > UDP link local: (not bound) . 2022.05.27 13:02:11 - OpenVPN > UDP link remote: [AF_INET]173.44.55.157:443 . 2022.05.27 13:02:11 - OpenVPN > TLS: Initial packet from [AF_INET]173.44.55.157:443, sid=26568122 e9c4d2fe . 2022.05.27 13:02:11 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2022.05.27 13:02:11 - OpenVPN > VERIFY KU OK . 2022.05.27 13:02:11 - OpenVPN > Validating certificate extended key usage . 2022.05.27 13:02:11 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2022.05.27 13:02:11 - OpenVPN > VERIFY EKU OK . 2022.05.27 13:02:11 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Acamar, emailAddress=info@airvpn.org . 2022.05.27 13:02:11 - OpenVPN > Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA . 2022.05.27 13:02:11 - OpenVPN > [Acamar] Peer Connection Initiated with [AF_INET]173.44.55.157:443 . 2022.05.27 13:02:12 - OpenVPN > SENT CONTROL [Acamar]: 'PUSH_REQUEST' (status=1) . 2022.05.27 13:02:13 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.4.78.1,dhcp-option DNS6 fde6:7a:7d20:4e::1,tun-ipv6,route-gateway 10.4.78.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:4e::1042/64 fde6:7a:7d20:4e::1,ifconfig 10.4.78.68 255.255.255.0,peer-id 12,cipher AES-256-GCM' . 2022.05.27 13:02:13 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2022.05.27 13:02:13 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS 10.4.78.1' . 2022.05.27 13:02:13 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:4e::1' . 2022.05.27 13:02:13 - OpenVPN > Pushed option removed by filter: 'tun-ipv6' . 2022.05.27 13:02:13 - OpenVPN > Pushed option removed by filter: 'ifconfig-ipv6 fde6:7a:7d20:4e::1042/64 fde6:7a:7d20:4e::1' . 2022.05.27 13:02:13 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2022.05.27 13:02:13 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2022.05.27 13:02:13 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2022.05.27 13:02:13 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2022.05.27 13:02:13 - OpenVPN > OPTIONS IMPORT: peer-id set . 2022.05.27 13:02:13 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2022.05.27 13:02:13 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2022.05.27 13:02:13 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2022.05.27 13:02:13 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2022.05.27 13:02:13 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2022.05.27 13:02:13 - OpenVPN > TUN/TAP device tun0 opened . 2022.05.27 13:02:13 - OpenVPN > TUN/TAP TX queue length set to 100 . 2022.05.27 13:02:13 - OpenVPN > do_ifconfig, tt->did_ifconfig_ipv6_setup=0 . 2022.05.27 13:02:13 - OpenVPN > /sbin/ip link set dev tun0 up mtu 1500 . 2022.05.27 13:02:13 - OpenVPN > /sbin/ip addr add dev tun0 10.4.78.68/24 broadcast 10.4.78.255 ! 2022.05.27 13:02:14 - Disconnecting . 2022.05.27 13:02:14 - Sending soft termination signal . 2022.05.27 13:02:14 - OpenVPN > event_wait : Interrupted system call (code=4) . 2022.05.27 13:02:14 - OpenVPN > SIGTERM received, sending exit notification to peer . 2022.05.27 13:02:17 - OpenVPN > Initialization Sequence Completed . 2022.05.27 13:02:17 - DNS of the system updated to VPN DNS (Rename method: /etc/resolv.conf generated) . 2022.05.27 13:02:18 - Routes, add 0.0.0.0/1 for interface "tun0". . 2022.05.27 13:02:18 - Routes, add 128.0.0.0/1 for interface "tun0". . 2022.05.27 13:02:18 - Routes, add 173.44.55.155/32 for interface "tun0". . 2022.05.27 13:02:18 - Routes, skipped for 2607:ff48:aa81:200:89bd:a0e5:6626:b661 : IPv6 blocked. . 2022.05.27 13:02:18 - Flushing DNS . 2022.05.27 13:02:20 - OpenVPN > Closing TUN/TAP interface . 2022.05.27 13:02:20 - OpenVPN > /sbin/ip addr del dev tun0 10.4.78.68/24 . 2022.05.27 13:02:20 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting . 2022.05.27 13:02:20 - Routes, delete 0.0.0.0/1 for interface "tun0", not exists. . 2022.05.27 13:02:20 - Routes, delete 128.0.0.0/1 for interface "tun0", not exists. . 2022.05.27 13:02:20 - Routes, skipped for 173.44.55.157 : IPv4 Net gateway not available. . 2022.05.27 13:02:20 - Routes, delete 173.44.55.155/32 for interface "tun0", not exists. . 2022.05.27 13:02:20 - Routes, skipped for 2607:ff48:aa81:200:89bd:a0e5:6626:b661 : IPv6 blocked. . 2022.05.27 13:02:20 - Routes, skipped for 173.44.55.157 : IPv4 Net gateway not available. . 2022.05.27 13:02:20 - IPv6 restored on network adapter (default) . 2022.05.27 13:02:20 - IPv6 restored on network adapter (enp4s0) . 2022.05.27 13:02:20 - IPv6 restored on network adapter (wlp3s0) . 2022.05.27 13:02:20 - DNS of the system restored to original settings (Rename method) . 2022.05.27 13:02:20 - Connection terminated. I 2022.05.27 13:02:20 - Cancel requested. ! 2022.05.27 13:02:20 - Session terminated. ---------------------------- Network Interfaces and Routes: { "routes": [ { "destination": "0.0.0.0\/0", "gateway": "192.168.1.1", "interface": "wlp3s0", "metric": "20600", "proto": "dhcp" }, { "destination": "169.254.0.0\/16", "interface": "wlp3s0", "metric": "1000", "scope": "link" }, { "destination": "192.168.1.0\/24", "interface": "wlp3s0", "metric": "600", "proto": "kernel", "scope": "link", "src": "192.168.1.3" }, { "destination": "::1\/128", "interface": "lo", "metric": "256", "pref": "medium", "proto": "kernel" }, { "destination": "fe80::\/64", "interface": "wlp3s0", "metric": "256", "pref": "medium", "proto": "kernel" } ], "ipv4-default-gateway": "192.168.1.1", "ipv4-default-interface": "wlp3s0", "interfaces": [ { "friendly": "lo", "id": "lo", "name": "lo", "description": "lo", "type": "Loopback", "status": "Unknown", "bytes_received": "78590754", "bytes_sent": "78590754", "support_ipv4": true, "support_ipv6": true, "ips": [ "127.0.0.1", "::1" ], "bind": true }, { "friendly": "enp4s0", "id": "enp4s0", "name": "enp4s0", "description": "enp4s0", "type": "Ethernet", "status": "Down", "bytes_received": "0", "bytes_sent": "0", "support_ipv4": true, "support_ipv6": true, "ips": [], "bind": false }, { "friendly": "wlp3s0", "id": "wlp3s0", "name": "wlp3s0", "description": "wlp3s0", "type": "Wireless80211", "status": "Up", "bytes_received": "4998323825", "bytes_sent": "731431651", "support_ipv4": true, "support_ipv6": true, "ips": [ "192.168.1.3", "fe80::260a:64ff:feda:53a3" ], "bind": true } ] } ---------------------------- ip addr show: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether bc:ee:7b:0d:f8:e2 brd ff:ff:ff:ff:ff:ff 3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 24:0a:64:da:53:a3 brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp3s0 valid_lft 86346sec preferred_lft 86346sec inet6 fe80::260a:64ff:feda:53a3/64 scope link valid_lft forever preferred_lft forever ---------------------------- ip link show: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether bc:ee:7b:0d:f8:e2 brd ff:ff:ff:ff:ff:ff 3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000 link/ether 24:0a:64:da:53:a3 brd ff:ff:ff:ff:ff:ff Quote Share this post Link to post
ProphetPX 1 Posted ... (edited) UPDATE: i fixed my problem by DOWNGRADING my Eddie client to 2.20.0 INSTEAD of the last few versions (the most recent ones) which i also tried but THIS IS THE ONLY ONE THAT WORKS and i am on the VPN right now using 2.20.0 -- Original post: I am having BUGGY things going on with the latest Eddie release as posted in this thread. HERE are my problems with this release: (I have a system report shared there too) please help? i am probably going to go DOWNGRADE my Eddie client now because this sucks!!!! thanks Edited ... by ProphetPX update Quote Share this post Link to post
cheeze 4 Posted ... I too am experiencing the issue wherein Eddie hangs at " Checking Route IPv4" . It keeps trying different servers as each one times out. This is occurring on two machines, MX linux 21.1 and Mint 20.3 This began since ver 2.21.? Currently still happening on 2.21.8 The only way to connect, is to exit Eddie completely, let the machine connect to my ISP in sans VPN, then run Eddie and connect to an AirVPN server. This is not a solution because I have to initiate a connect to the internet in the clear before running Eddie. I hope my post is not considered hijacking this thread. I am contributing to the same presented. 1 EclecticFish reacted to this Quote Share this post Link to post
OpenSourcerer 1435 Posted ... 6 minutes ago, cheeze said: I hope my post is not considered hijacking this thread. I am contributing to the same presented. It's an Announcement thread with Staff and dev attention, you're in the right place here 2 cheeze and EclecticFish reacted to this Quote Hide OpenSourcerer's signature Hide all signatures NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT. LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too! Want to contact me directly? All relevant methods are on my About me page. Share this post Link to post
Searching 3 Posted ... Hello. Just to let know that with Eddie 2.21.18 I can run Hummingbird from within Eddie in OSX High Sierra, and it is working fine. For me it was a long waited feature, so thanks AirVPN team and developers. Happy birthday!! 1 1 EclecticFish and Staff reacted to this Quote Share this post Link to post
EclecticFish 5 Posted ... 12 hours ago, cheeze said: I too am experiencing the issue wherein Eddie hangs at " Checking Route IPv4" . It keeps trying different servers as each one times out. This is occurring on two machines, MX linux 21.1 and Mint 20.3 This began since ver 2.21.? Currently still happening on 2.21.8 The only way to connect, is to exit Eddie completely, let the machine connect to my ISP in sans VPN, then run Eddie and connect to an AirVPN server. This is not a solution because I have to initiate a connect to the internet in the clear before running Eddie. I hope my post is not considered hijacking this thread. I am contributing to the same presented. I normally don't notice any blocking or hunting but encountered it on a laptop with an earlier version. I'm not saying this is how network settings should be but these are my network settings on this desktop machine: Quote Share this post Link to post
cheeze 4 Posted ... On 5/29/2022 at 5:25 AM, EclecticFish said: I normally don't notice any blocking or hunting but encountered it on a laptop with an earlier version. I'm not saying this is how network settings should be but these are my network settings on this desktop machine: Those are the settings I have too. I also tried "Inside Tunnel If Supported, Otherwise Block" for IPV4. It did not solve the issue. Quote Share this post Link to post
scooby0786 6 Posted ... Guys, delete all Eddie stuff for those struggling. For Windows guys, also delete Tap/Wintun driver separately from "Device manager." Restart and do a fresh install of Eddie and see if that resolves it. If not, try my old method for past updates which I feel may still be relevant and work for most of you. Method 1:Preferences>Networking: Layer ipv4: inside tunnel must be supported. Switch to block if issue is detected ticked on. Layer ipv6 blocked. switch to block switched on and ticked. Internet protocol used: ipv4 only Interface used for connection: Automatic. TCP/UDP send buffer size/receive buffer size: Automatic for both.Or:Method 2: Preferences>Networking: Layer ipv4: inside tunnel must be supported. Switch to block if issue is detected ticked on. Layer ipv6 inside tunnel must be supported. switch to block if issue is detected switched on and ticked. Internet protocol used for connection: ipv4, IPv6 Interface used for connection: Automatic. TCP/UDP send buffer size/receive buffer size: Automatic for both. Hope it helps. Link to my original post here: Quote Share this post Link to post
Monotremata 22 Posted ... (edited) So far so good. I'm still getting the weird buffer errors when I use Hummingbird though. Running the latest Monterey on an Intel Mac mini. Doesnt happen all the time but usually when a big download starts, or I just copy something over the network to my NAS, I get a whole bunch of the errors below. The log covers a whopping one minute, I had to turn off MacOS's notifications for Eddie because whenever it does this that thing is constantly popping up on screen until it stops. OpenVPN is fine, but Hummingbird has always done this here even before 1.0.. Does Little Snitch have anything to do with it? E 2022.05.30 09:46:27 - Hummingbird > ERROR: errors sending on network socket . 2022.05.30 09:46:27 - Hummingbird > UDP send exception: send: No buffer space available E 2022.05.30 09:46:27 - Hummingbird > ERROR: errors sending on network socket Edited ... by Clodo fix useless long logs Quote Share this post Link to post
EclecticFish 5 Posted ... Uninstalled Eddie, removed, purged. Downloaded fresh copy of 2.21.8 Would not install due to a new dependency problem, probably caused by the purge. sudo apt --fix-missing update sudo apt update sudo apt install -f Install worked this time. VPN works as usual. Latency column still in error, so I just have to ignore it. dpkg not reporting any broken packages It's a mystery. Quote Share this post Link to post
HeyWAZZab33 0 Posted ... On 5/8/2022 at 12:53 AM, ***** said: Eddie Desktop Edition 2.21.6 does not allow me to connect to any server. It always gets stuck at "Checking route IPV4..." The only workaround is to select Layer IPv4 to Outside tunnel, then it connects. Any other setting fails. OS: Linux Mint 19.3 Cinnamon My Networking settings: (works in 2.20.0 and 2.19.7) I have the exact same problem. Everything worked fine until I updated. I can get server pings, but everything fails at 'checking route'. OS: Windows 10 My network settings are all on automatic, no static IPs. Here my report: ! 2022.05.31 12:54:16 - Disconnecting . 2022.05.31 12:54:16 - Sending soft termination signal . 2022.05.31 12:54:19 - OpenVPN > SIGTERM received, sending exit notification to peer . 2022.05.31 12:54:22 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting . 2022.05.31 12:54:22 - Routes, delete 217.64.127.197/32 for interface "WLAN (Intel(R) Wi-Fi 6E AX210 160MHz)". . 2022.05.31 12:54:22 - Routes, delete 217.64.127.197/32 for interface "WLAN (Intel(R) Wi-Fi 6E AX210 160MHz)", not exists. . 2022.05.31 12:54:22 - Connection terminated. I 2022.05.31 12:54:22 - Cancel requested. ! 2022.05.31 12:54:23 - Session terminated. I 2022.05.31 12:54:24 - Session starting. I 2022.05.31 12:54:24 - Checking authorization ... . 2022.05.31 12:54:25 - Added new network interface "Eddie", Wintun version 0.12 . 2022.05.31 12:54:25 - Using WinTun network interface "Eddie (Eddie Tunnel)" ! 2022.05.31 12:54:25 - Connecting to Caelum (Austria, Vienna) . 2022.05.31 12:54:25 - Routes, add 217.64.127.197/32 for interface "WLAN (Intel(R) Wi-Fi 6E AX210 160MHz)". . 2022.05.31 12:54:25 - Routes, add 217.64.127.197/32 for interface "WLAN (Intel(R) Wi-Fi 6E AX210 160MHz)", already exists. . 2022.05.31 12:54:25 - OpenVPN > OpenVPN 2.5.5 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 15 2021 . 2022.05.31 12:54:25 - OpenVPN > Windows version 10.0 (Windows 10 or greater) 64bit . 2022.05.31 12:54:25 - OpenVPN > library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10 . 2022.05.31 12:54:25 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2022.05.31 12:54:25 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2022.05.31 12:54:25 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2022.05.31 12:54:25 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2022.05.31 12:54:25 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]217.64.127.197:443 . 2022.05.31 12:54:25 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144] . 2022.05.31 12:54:25 - OpenVPN > UDP link local: (not bound) . 2022.05.31 12:54:25 - OpenVPN > UDP link remote: [AF_INET]217.64.127.197:443 . 2022.05.31 12:54:31 - OpenVPN > TLS: Initial packet from [AF_INET]217.64.127.197:443, sid=42fc2b1c cda1c8b2 . 2022.05.31 12:54:31 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org . 2022.05.31 12:54:31 - OpenVPN > VERIFY KU OK . 2022.05.31 12:54:31 - OpenVPN > Validating certificate extended key usage . 2022.05.31 12:54:31 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2022.05.31 12:54:31 - OpenVPN > VERIFY EKU OK . 2022.05.31 12:54:31 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Caelum, emailAddress=info@airvpn.org . 2022.05.31 12:54:31 - OpenVPN > Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 4096 bit RSA, signature: RSA-SHA512 . 2022.05.31 12:54:31 - OpenVPN > [Caelum] Peer Connection Initiated with [AF_INET]217.64.127.197:443 . 2022.05.31 12:54:31 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.12.26.1,dhcp-option DNS6 fde6:7a:7d20:81a::1,tun-ipv6,route-gateway 10.12.26.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:81a::108d/64 fde6:7a:7d20:81a::1,ifconfig 10.12.26.143 255.255.255.0,peer-id 1,cipher AES-256-GCM' . 2022.05.31 12:54:31 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp' . 2022.05.31 12:54:31 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS 10.12.26.1' . 2022.05.31 12:54:31 - OpenVPN > Pushed option removed by filter: 'dhcp-option DNS6 fde6:7a:7d20:81a::1' . 2022.05.31 12:54:31 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified . 2022.05.31 12:54:31 - OpenVPN > OPTIONS IMPORT: compression parms modified . 2022.05.31 12:54:31 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified . 2022.05.31 12:54:31 - OpenVPN > OPTIONS IMPORT: route-related options modified . 2022.05.31 12:54:31 - OpenVPN > OPTIONS IMPORT: peer-id set . 2022.05.31 12:54:31 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625 . 2022.05.31 12:54:31 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified . 2022.05.31 12:54:31 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2022.05.31 12:54:31 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2022.05.31 12:54:31 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2022.05.31 12:54:31 - OpenVPN > interactive service msg_channel=0 . 2022.05.31 12:54:31 - OpenVPN > open_tun . 2022.05.31 12:54:31 - OpenVPN > wintun device [Eddie] opened . 2022.05.31 12:54:31 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ip set address 45 static 10.12.26.143 255.255.255.0 . 2022.05.31 12:54:32 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ip delete dns 45 all . 2022.05.31 12:54:32 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ip delete wins 45 all . 2022.05.31 12:54:32 - OpenVPN > IPv4 MTU set to 1500 on interface 45 using SetIpInterfaceEntry() . 2022.05.31 12:54:32 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ipv6 set address 45 fde6:7a:7d20:81a::108d/128 store=active . 2022.05.31 12:54:32 - OpenVPN > add_route_ipv6(fde6:7a:7d20:81a::/64 -> fde6:7a:7d20:81a::108d metric 0) dev Eddie . 2022.05.31 12:54:32 - OpenVPN > C:\Windows\system32\netsh.exe interface ipv6 add route fde6:7a:7d20:81a::/64 45 fe80::8 store=active . 2022.05.31 12:54:32 - OpenVPN > env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem . 2022.05.31 12:54:32 - OpenVPN > NETSH: C:\Windows\system32\netsh.exe interface ipv6 delete dns 45 all . 2022.05.31 12:54:32 - OpenVPN > IPv6 MTU set to 1500 on interface 45 using SetIpInterfaceEntry() . 2022.05.31 12:54:32 - OpenVPN > Initialization Sequence Completed . 2022.05.31 12:54:32 - Interface Eddie metric changed from Automatic to 3, layer IPv4 . 2022.05.31 12:54:32 - Interface Eddie metric changed from Automatic to 3, layer IPv6 . 2022.05.31 12:54:32 - DNS leak protection with packet filtering enabled. . 2022.05.31 12:54:32 - DNS IPv4 of a network adapter forced (Eddie, from automatic to 10.12.26.1) . 2022.05.31 12:54:32 - DNS IPv6 of a network adapter forced (Eddie, from automatic to fde6:7a:7d20:81a::1) . 2022.05.31 12:54:32 - DNS IPv4 of a network adapter forced (VirtualBox Host-Only Network, from automatic to 10.12.26.1) . 2022.05.31 12:54:32 - DNS IPv6 of a network adapter forced (VirtualBox Host-Only Network, from automatic to fde6:7a:7d20:81a::1) . 2022.05.31 12:54:32 - Routes, add 0.0.0.0/1 for interface "Eddie (Eddie Tunnel)". . 2022.05.31 12:54:33 - Routes, add 128.0.0.0/1 for interface "Eddie (Eddie Tunnel)". . 2022.05.31 12:54:33 - Routes, add ::/1 for interface "Eddie (Eddie Tunnel)". . 2022.05.31 12:54:33 - Routes, add 8000::/1 for interface "Eddie (Eddie Tunnel)". . 2022.05.31 12:54:33 - Routes, add 217.64.127.195/32 for interface "Eddie (Eddie Tunnel)". . 2022.05.31 12:54:33 - Routes, add 2001:ac8:29:b:a50:6136:ace6:d39b/128 for interface "Eddie (Eddie Tunnel)". . 2022.05.31 12:54:33 - Flushing DNS I 2022.05.31 12:54:33 - Checking route IPv4 . 2022.05.31 12:55:01 - Checking route (4° try) . 2022.05.31 12:55:26 - Checking route (5° try) Edit: Solved by downgrading to 2.21.6 Edit2: Still broken, problem can be circumvented by connecting WiFi before starting Eddie. Latency still an issue, double latency on local servers. Quote Share this post Link to post
EclecticFish 5 Posted ... Reverted to 2.20.0 to test whether latency column figures returned to normal after restart. They did. All good. No issues in log. Updated to 2.21.8 then restarted. Latency column in error again. No performance issues and nothing shouting to me in the log. Quote Share this post Link to post
ta13oo 0 Posted ... Hello, glad to know am not alone with latency issue. This machine is Windows 8.1 & problem started last week when was still using Eddie 2.20.0. Normally use Canadian servers & latency column showed as usual 41-48ms on them. The first couple I tried showed 41 ms but were so slow was unusable. Third attempt, business as usual. Couple days of this & upgraded to 2.21.8 with same problem. 2-3 tries & would find a server working normally. Today when I turned Eddie on all Canadian servers showed above 61ms in column so to avoid the bother I used a USA server that showed 9ms & has worked fine all day. Live in USA so don't really like using those servers, no big deal. Just wanted to pass along the info in case might help. Quote Share this post Link to post
Clodo 176 Posted ... 2.21.8 tries to detect the default gateway at startup, hence those who enable the network later will run into issues. This is fixed in 2.22.0 ready to be released as experimental version, we are only waiting for confirmation. About ping issue, honestly I haven't found a solution yet: we never reproduce the issue (in this video https://www.clodo.it/files/temp/ping.mp4 i have OS ping both in Linux and Windows, and Eddie in both OS always matches the outcome). Still under investigation, we need to identify the reason and reproduce it, in order to fix. It's normal that, when connected to a VPN server, ping results are not populated or updated. Ping aims at finding the best server to connect to, therefore collecting results when you are connected to a server is useless. Those who allegedly experience the ping issue should confirm it WITHOUT ever trying to connect (open Eddie only), and should specify the OS (apparently there's no macOS user with this issue?). Thanks 1 cheeze reacted to this Quote Share this post Link to post
EclecticFish 5 Posted ... Thanks @Clodo for following this up. Network is always on before powering up machine. Machine powered up, logged on and connecting to LAN (cable or wireless) Open Eddie. Activate network lock. Logon to AirVPN. Choose a server and connect to it. Ignore false results. If I let Eddie choose for me it may pick the best result from incorrect latency results. If connected via wireless and connection drops, Eddie will either choose a server or run latency checks. Comparing a machine running 2.20.0 with a machine running 2.21.8, I would expect latency results to be similar but they are nothing like the same. Both machines are running the same version of Linux OS. One is connected via cable and the other via wireless. I thought I would run a comparison with both machines on the same server but Eddie doesn't like this and it seems to force a disconnection. This may be because of a duplicate account name being seen on the same server, so the server is kicking one connection off as if it's stale. In each case the server Eddie chose was a good choice, as if this part is performed with a real ping test and not what is displayed by the latency column... The comparison had to be done separately. I nominated a server for the test and swapped a machine to it, noted the latency figure then back to the original server. I repeated the test for the second machine. The results were 279 ms and 34 ms. To me this implies a calculation error. Next I tried a ping test to Castor again from each machine. There was less than 2 ms difference between them. On the network layer things appear normal. The problem must be on the application layer, in which case how might reverting to 2.20.0 remove the error? I could be wrong but I think your tests are run using a Virtual Machine? In this case each build will tend to be fresh. When I previously tried purging old Eddie it prevented installation of the new version due to missing dependencies, so it seems the purge was effective. If a previous instance had interacted it wasn't evident in network performance. I don't know how the AirVPN wrapper integrates with the OpenVPN software. As far as I can tell it must work okay for most users. How would we go about breaking the latency calculation without affecting the network layer? Quote Share this post Link to post
EclecticFish 5 Posted ... After my last tests I shut down. Four hours later I booted up and connected in the usual way but noted something odd. The latency figures were almost normal. No changes have been made to my Eddie client. I double checked by stopping and starting. This resulted in high numbers being reported again. Quote Share this post Link to post
EclecticFish 5 Posted ... Saturday morning - mostly normal latency figures seen after first boot and launch of Eddie. [Unfortunately this was only temporary] This time when I changed server the latency figures are good again, unlike Friday. [Unfortunately it was back to reporting incorrectly again after that] Although nothing has been changed on the client the desktop is kept up to date, so it's possible that system updates have an effect. To find the dependencies, I went to Downloads in Terminal and used dpkg --info ~/Downloads$ dpkg --info eddie-ui_2.21.8_linux_x64_debian.deb From the output: Depends: libc6 (>= 2.3.2), sudo, curl, libnotify-bin, mono-runtime, mono-utils, libmono-system-core4.0-cil, libmono-system-windows-forms4.0-cil, openvpn, stunnel4, curl, libsecret-tools, libayatana-appindicator3-1 Breaks: airvpn (<< 2.14.4) Replaces: airvpn (<< 2.14.4) I don't recall openvpn being updated recently. Most of the others are Linux specific. Just to double check that there were no old versions left on the machine, I did dpkg --list | grep Eddie ii eddie-ui 2.21.8 Anyway, for now at least, I'm guessing that the process of updating packages which may or may not be obviously related caused something to flush out. Update: Client defaulted to incorrectly high latency figures. Noticing some hesitancy during sessions, due to DNS. This would not affect ping to ip addresses but it could affect pings to named servers. Update 21/06/22 - Staff confirm that DNS cannot be causing the latency errors. Quote Share this post Link to post
Not connected, Your IP: 18.218.108.24
Online: 26304 users - 317414 Mbit/s total BW.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png){kind=avatar}