Clodo

We released a new experimental version, mainly to fix some "Checking route IPv4" failure related to network adapter not active when Eddie starts. Other issues still under investigation. Version 2.22.0 (Mon, 13 Jun 2022 09:01:26 +0000) [bugfix] [all] detection of network information when needed, not only at start [change] [linux] libcurl, avoid need of curl binary [bugfix] [linux/windows] font issues

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

This issue is under investigation, will be fixed as soon as possible, please be patient.

Exactly, the NETSH error above is an OpenVPN error, not Eddie's. Seems related to the wintun driver, but tap-driver is deprecated. @ProphetPX the issue is under investigation, please be patient.

@EclecticFish @BlueBanana fixed, please perform an "apt-get update" or re-download the .deb.

@EclecticFish @BlueBanana please wait, our fault, will be fixed as soon as possible.

@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.

I understand you want to help resolve issue, but please don't suggest anymore to check the "Force usage of old TAP driver": it's a deprecated feature, and we need to resolve issue without this fallback. Thanks. @zeroone1zero i will reply your ticket soon today

In Linux do we need to manually transfer the Hummingbird binaries to a folder, like \etc and set permissions? I usually pull the latest Hummingbird binary out of the AirVPN Suite and point Eddie to the folder location. If this has changed, please clarify before I upgrade. Thank you. Hummingbird Is bundled in any macOS version of Eddie, and in linux portable and AppImage versions of Eddie. In the above cases, to use it users need ONLY to check "Use hummingbird" in Preferences > Advanced, they needn't write a path to a binary file. Arch AUR, .deb or .rpm packages don't include HB for the same reason they don't include either OpenVPN, stunnel or ssh, as a OS package is made of plain Eddie with dependencies to other packages like OpenVPN, so Hummingbird must be in the environment path to be found.

What OS?

2.21.6 has an issue with NetLock when IPv6 is disabled at OS level (Linux only). This is fixed in the next release, please be patient a couple of days.

tray-icon under Linux will be reactivated at the next release (experimental), under testing, expected next week. Please have patience.

Just tested a Monterey (arch: M1/arm) and i can't reproduce this issue, does anyone else have this issue? Please open a ticket, report your OS and CPU arch and a Logs>Lifebelt report (to allow us to understand what options cause this behavior). Thx.

Was an error, fixed, now in "other versions" the "latest stable" link to 2.21.6. Thanks for the feedback.

Mmm... 2.21 performs more checks than 2.20 about iptables/iptables-legacy/nftables, probably one of them when checking ipv6 returns an error, this issue is under investigation, thanks for the feedback