Eddie 2.14beta released

UncleHunto

Eddie 2.14.0 beta worked great on my Manjaro 64-bit Cinnamon Community Edition system, congratulations on the improvements! I was able to run it for days and never get freezes or crashes like I did with 2.13.X and to a lesser extent 2.12.X. The only small problem I noticed was that the tray icon didn't show up when that option was selected, but everything else worked quite well.

Unfortunately when I tried out 2.14.1 beta it froze when I tried to activate the network lock and it didn't generate any log files, even though I had selected those options in settings. Let me know if there is something you would like me to do in order to help figure out the cause of the problem I had with freezing when trying to activate network lock. Keep up the great work!

UncleHunto

Forgot to mention in my previous post, IPv6 was working great for me with 2.14.0 beta.

Clodo

Regarding the following change in 2.14.1:

"[bugfix] Linux - iptables --wait flag workaround."

May I ask, what this workaround actually does?

Is it any less reliable or secure than earlier versions of iptables together with older clients (up to 2.14 and incl. 2.13.6 stable)?

Reference: https://airvpn.org/topic/25199-debian-unstable-network-lock-fail-sbiniptables-save-unrecognized-option-wait/

In answer to your first question ; May I ask, what this workaround actually does?

answer is it gets network-lock working again.

It's NOT "less reliable or secure".

If there are concurrent iptables (from another process for example), iptables returns an error ("Resource temporarily unavailable" in older version, or "Another app is currently holding the xtables lock. Perhaps you want to use the -w option?" in newer versions).

Previously Eddie detected if the iptables version supports the "--wait" (or -w) flag, and used it.

But with newest distro, that seems not sufficient and throws another kind of error (still under investigation).

Eddie 2.14.x implements a workaround: it doesn't use --wait flag anymore, but detects if iptables fails for this reason, and retries at least 10 times with incremental delay. If all 10 times fail, Eddie throws a fatal error.

So NOTHING has changed about 'reliability' or 'security', this is only a different method to detect if iptables effectively added the requested rule.

Clodo

"Down / Up speeds / Server_name (Country) - IP" are now longer showing up in the title bar, is there a way to get them back? I can't find any option to do so in preferences.

This is a bug, it will be fixed in the next release.

There is an error when installing using the RPM package under Fedora 27.
 Problem: conflicting requests
  - nothing provides libappindicator1 needed by airvpn-2.14.0-0.x86_64
This is solved of course by using only the OpenVPN configuration file or by using the portable version of the Eddie client. Similar problem described here with another application.

Ouch.. libappindicator package is called "libappindicator" under Fedora, and "libappindicator1" under many other distributions.

Current Eddie RPM package requires this package for the tray.

Deploying two different RPM packages based on distro would be complex right now.

So, in the subsequent release we removed the libappindicator dependencies as "Required". Unfortunately, RPM doesn't have an equivalent of "Optional" like .deb control format.

Users who want Tray in RPM-based distro must install manually libappindicator package.

Maybe in the next releases we can add a warning to suggest that.

Clodo

Memory leak on Linux seem to persist.

see https://airvpn.org/topic/23911-eddie-client-memory-leak-on-linux/page-2?do=findComment&comment=69197

We profiled the Linux build with Mono with Eddie connected to VPN for more than 8 hours about three times. There isn't any evident memory leak, at least not in normal circumstances.

We continue to perform tests about this issue.

If anyone wants to perform some test (user-friendly edition):

- Download the MONO version of Eddie 2.14.0

- Download and extract this: https://airvpn.org/repository/misc/HeapShot.zip

- Open a terminal and launch

sudo mono HeapShot.Gui.exe

(remember the 'sudo', otherwise Eddie relaunches itself and profiling ends prematurely).

If it doesn't start, probably it's missing some Mono assembly, like the GTK. Try to install mono-complete.

- Click the "Run" icon and pick Eddie-UI.exe (or /usr/lib/AirVPN/AirVPN.exe if using the .deb or .rpm edition)

- Eddie will start. Connect to the VPN.

- Click "Take a Memory Snapshot" on HeapShot when you want (at VPN connection, after 8 hours etc). Before that, clear Eddie logs.

- ....

- Disconnect and close Eddie.

- Click Stop in HeapShot.

- Every click of "Take a Memory Snapshot" are showed in the left pane:

17fd8cb94b75366dbf5646dbda392693806b4407

More documentation about other profiling methods: http://www.mono-project.com/docs/debug+profile/profile/profiler/

Shiver Me Whiskers

I am getting better ping times to Castor (BE) from the Netherlands (15ms) on IPv6, than to the Netherlands servers themselves on IPv4 !

That is probably because I'm on a "pure IPv6" scheme (DS Lite) and have no real IPv4. No double NAT = Better performance... so really happy that IPv6 is finally coming to AirVPN !

Can't wait to see how it will work to closer servers.

Will report if I notice anything weird during this test phase.

Clodo

Does the portable version use the system installed mono or how does it work?
Which mono version is recommended?

The portable version doesn't require Mono, it's embedded internally.

There isn't a recommended version Mono for us.

We are still investigating the memleak reported issue.

Keksjdjdke

The portable version don't require Mono, it's embedded internally.
There isn't a recommended version Mono for us.
We are still investigating the memleak reported issue.

Will this bug be fixed? #74

cse

This report and setup guide applies to PCLinuxOS (running KDE5), specifically:

Untitled 1.txt

cse

Memory leak on Linux seem to persist.

see https://airvpn.org/topic/23911-eddie-client-memory-leak-on-linux/page-2?do=findComment&comment=69197

We profiled the Linux build with Mono with Eddie connected to VPN for more than 8 hours about three times. There isn't any evident memory leak, at least not in normal circumstances.
We continue to perform tests about this issue.

If anyone wants to perform some test (user-friendly edition):
- Download the MONO version of Eddie 2.14.0
- Download and extract this: https://airvpn.org/repository/misc/HeapShot.zip
- Open a terminal and launch
sudo mono HeapShot.Gui.exe
(remember the 'sudo', otherwise Eddie relaunches itself and profiling ends prematurely).
If it doesn't start, probably it's missing some Mono assembly, like the GTK. Try to install mono-complete.
- Click the "Run" icon and pick Eddie-UI.exe (or /usr/lib/AirVPN/AirVPN.exe if using the .deb or .rpm edition)
- Eddie will start. Connect to the VPN.
- Click "Take a Memory Snapshot" on HeapShot when you want (at VPN connection, after 8 hours etc). Before that, clear Eddie logs.
- ....
- Disconnect and close Eddie.
- Click Stop in HeapShot.
- Every click of "Take a Memory Snapshot" are showed in the left pane:

More documentation about other profiling methods: http://www.mono-project.com/docs/debug+profile/profile/profiler/

I'm having problem running eddie through the gui but I left my troublesome system running through the night using this command:

sudo mono --gc=sgen --profile=log:heapshot ../../bin/eddie-ui_2.14.0_linux_x64_mono/Eddie-UI.exe

that produced a 348M file called ouyput.mlpd yhat I am willing to share if you give me instructions.

top reported eddie to use about 700m resident after the run.

Abadrook

Regarding the following change in 2.14.1:

"[bugfix] Linux - iptables --wait flag workaround."

May I ask, what this workaround actually does?

Is it any less reliable or secure than earlier versions of iptables together with older clients (up to 2.14 and incl. 2.13.6 stable)?

Reference: https://airvpn.org/topic/25199-debian-unstable-network-lock-fail-sbiniptables-save-unrecognized-option-wait/

In answer to your first question ; May I ask, what this workaround actually does?

answer is it gets network-lock working again.

Well, yes, I am aware of this. The question was about the nature of the workaround. What exactly does it do and in what way is it a workaround?

Abadrook

Regarding the following change in 2.14.1:

"[bugfix] Linux - iptables --wait flag workaround."

May I ask, what this workaround actually does?

Is it any less reliable or secure than earlier versions of iptables together with older clients (up to 2.14 and incl. 2.13.6 stable)?

Reference: https://airvpn.org/topic/25199-debian-unstable-network-lock-fail-sbiniptables-save-unrecognized-option-wait/

In answer to your first question ; May I ask, what this workaround actually does?

answer is it gets network-lock working again.

It's NOT "less reliable or secure".
If there are concurrent iptables (from another process for example), iptables returns an error ("Resource temporarily unavailable" in older version, or "Another app is currently holding the xtables lock. Perhaps you want to use the -w option?" in newer versions).
Previously Eddie detected if the iptables version supports the "--wait" (or -w) flag, and used it.
But with newest distro, that seems not sufficient and throws another kind of error (still under investigation).

Eddie 2.14.x implements a workaround: it doesn't use --wait flag anymore, but detects if iptables fails for this reason, and retries at least 10 times with incremental delay. If all 10 times fail, Eddie throws a fatal error.
So NOTHING has changed about 'reliability' or 'security', this is only a different method to detect if iptables effectively added the requested rule.

Thank you, that answers my previous question in detail!

zhang888

If you have abnormal memory usage with Mono on your distro, a more helpful output for debugging the issue

can be generated by running it with --profile=malloc:log-malloc flag.

Then you can see sudden spikes and what caused them.

Memory leaks are harder to reproduce since they can occur under totally unique conditions, such as Window Manager,

sudden app like a browser that allocated lots memory and then Mono ran into issues, etc.

Fly AirVPN

Win10 Home 64bit PC went to sleep with Eddie 2.14.1 active. After waking the PC, Eddie returned an endless recurring notification loop (first image). After a right-click in the tray icon, there was a recurring message at the top for authentication and ipV6 rule (second image). Resolution was to exit Eddie and restart.

puff-m-d

Hello,

I am having the exact same issues as in this post:

Win10 Home 64bit PC went to sleep with Eddie 2.14.1 active. After waking the PC, Eddie returned an endless recurring notification loop. After a right-click in the tray icon, there was a recurring message at the top for authentication and ipV6 rule. Resolution was to exit Eddie and restart.

alreadyexists.png

alreadyexists2.png

It just started this morning after waking my system from sleep. However, in my case, exiting Eddie and starting it again does not work. I also tried shutting down Eddie and then rebooting my system, but still get the same errors. Eddie will not reconnect and I am not able to connect to AirVPN at all. Same errors as above post always occurs....

Note: I am on Windows 10 Pro and both Eddie 2.14 and 2.14.1 both have been working without issue until waking my system this morning and at the moment I cannot connect to AirVPN at all...

Edited to add: Affter further troubleshooting, I finally resolved my issue but there definitely seems to be a issue with Eddie. In preferences, I have the following options enabled:

Under "Settings > General", I have both "Connect at startup" checked and
"Reconnect to last server at start" checked, and
On the "Servers"tab, I have "Lock Current" checked.

When my system went to sleep last night, I was connected to the "Dschubba" server and all was well. This morning it seems that "Dschubba" is reporting as "(NA: Line problem)". With previous versions of Eddie, I would just reconnect to a different server and all would work fine. This does not work with the experimental version of Eddie however...

In order to connect, I had to do the following:

Under "Settings > General", disable both "Connect at startup" (now unchecked), and
Disable "Reconnect to last server at start" (now unchecked), and
On the "Servers"tab, disable "Lock Current" enabled (now unchecked).

After doing this, I was able to connect and the enable the three options again. All is now working as expected.

Conclusion: With the three options mentioned above enabled/checked, if you wake your system from sleep or try to reconnect to a server that happens to be "not available", then you get stuck in a loop where no matter what you do you can not connect or choose a different server. In my case, I had to do the following in order to be able to connect:

Disable/uncheck the three options that I listed above.
Exit and restart Eddie.
Choose a new available server and connect to it.
Enable the three options once again.
Exit and restart Eddie.

It seems that if you have those three options checked and Eddie happens to try to connect to a server that is "Not Available", then you get stuck in this loop of not being able to connect until you do as I outlined above.

I know that this issue will probably only appear very rarely if the conditions that I have outlined above happen to be present but I hope this will help you in troubleshooting this issue...

Staff

Version 2.14.2

[bugfix] Windows - Error "Windows WFP, Add rule failed: Interface ID '*' unknown or disabled for the layer."
[bugfix] Crash in some menu items if opened before some initialization.
[bugfix] Windows/Linux - Stats in title-bar.
[bugfix] macOS - Settings -> Networking -> Layer IPv4/IPv6 regression bug
[bugfix] Linux - RPM only - Removed libappindicator dependency

Other issues reported in this topic are still under investigation.

Clodo

Win10 64bit with 2.14.1. Not sure if it's by design, but notification tray tool tip no longer displays connected server.

It was a bug, fixed in 2.14.2.

Clodo

Will this bug be fixed? #74
...
When I enable dark mode on 10.13.3 (17D47) and start Eddie 1.14.1 the menu bar icon will only show a red line and some black dots. Here is a photo showing what it looks like.

This is very strange... Eddie under macOS have different sets of icons just to adapt to light/dark theme..

on my High Sierra with dark theme look:

b0c28f07fc2f588a5f7a369c5e7247c3dd7ef0bb

Anyone else here use dark-theme on macOS and don't see correctly the icon?

Random question: Would it be possible if your ISP didn't have v6 to block v4 entirely and only browse the internet via a v6 using Castor? When I attempt to block v4 eddie says "IPv4 blocking not yet implemented".

It'd be nice to have the VPN only route v6 packets, but I am not sure that's technically possible.

LZ1

On 2.14.1

Otherwise NL, Check Air DNS and Check Tunnel are on.

Linux Mint 18 Cinnamon.

I get this pop-up in two scenarios:

After waking up my computer from hibernation, with an Eddie instance which wasn't shut down properly beforehand.
When I get an assertion failure and it just pops up out of nowhere:
! 2018.02.18 22:03:52 - Connected.
. 2018.02.18 22:03:52 - OpenVPN > Initialization Sequence Completed
. 2018.02.18 22:12:04 - Updating systems & servers data ...
. 2018.02.18 22:12:06 - Systems & servers data update completed
. 2018.02.18 22:22:07 - Updating systems & servers data ...
. 2018.02.18 22:22:09 - Systems & servers data update completed
. 2018.02.18 22:32:10 - Updating systems & servers data ...
. 2018.02.18 22:32:12 - Systems & servers data update completed
. 2018.02.18 22:42:13 - Updating systems & servers data ...
. 2018.02.18 22:42:15 - Systems & servers data update completed
. 2018.02.18 22:52:16 - Updating systems & servers data ...
. 2018.02.18 22:52:18 - Systems & servers data update completed
. 2018.02.18 23:02:19 - Updating systems & servers data ...
. 2018.02.18 23:02:22 - Systems & servers data update completed
. 2018.02.18 23:03:39 - OpenVPN > TLS: soft reset sec=0 bytes=34565305/0 pkts=51766/0
. 2018.02.18 23:03:41 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2018.02.18 23:03:41 - OpenVPN > Validating certificate key usage
. 2018.02.18 23:03:41 - OpenVPN > ++ Certificate has key usage 00a0, expects 00a0
. 2018.02.18 23:03:41 - OpenVPN > VERIFY KU OK
. 2018.02.18 23:03:41 - OpenVPN > Validating certificate extended key usage
. 2018.02.18 23:03:41 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2018.02.18 23:03:41 - OpenVPN > VERIFY EKU OK
. 2018.02.18 23:03:41 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Columba, emailAddress=info@airvpn.org
. 2018.02.18 23:03:42 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2018.02.18 23:03:42 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.02.18 23:03:42 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2018.02.18 23:03:42 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.02.18 23:03:42 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2018.02.18 23:12:22 - Updating systems & servers data ...
. 2018.02.18 23:12:25 - Systems & servers data update completed
. 2018.02.18 23:15:51 - OpenVPN > [Columba] Inactivity timeout (--ping-restart), restarting
. 2018.02.18 23:15:51 - OpenVPN > SIGUSR1[soft,ping-restart] received, process restarting
. 2018.02.18 23:15:51 - OpenVPN > Restart pause, 2 second(s)
! 2018.02.18 23:15:51 - Disconnecting
. 2018.02.18 23:15:51 - Routes, removed a route previously added, 194.187.251.115 for gateway 10.4.0.1
. 2018.02.18 23:15:51 - Sending management termination signal
. 2018.02.18 23:15:51 - Management - Send 'signal SIGTERM'
. 2018.02.18 23:15:51 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2018.02.18 23:15:51 - OpenVPN > MANAGEMENT: Client disconnected
. 2018.02.18 23:15:51 - OpenVPN > Assertion failed at misc.c:785 (es)
. 2018.02.18 23:15:51 - OpenVPN > Exiting due to fatal error
. 2018.02.18 23:15:51 - Connection terminated.
. 2018.02.18 23:15:51 - DNS of the system restored to original settings (Rename method)
I 2018.02.18 23:15:54 - Checking authorization ...

I suspect I'll still get it in 2.14.2, so I just wanted to post anyway.

Besides this, which I thought was odd, as it doesn't tend to be 0:
. 2018.02.18 23:19:47 - Flushing DNS
I 2018.02.18 23:19:48 - Checking route IPv4
. 2018.02.18 23:20:08 - curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received
. 2018.02.18 23:20:08 - Checking route (2° try)
. 2018.02.18 23:20:29 - curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received
. 2018.02.18 23:20:29 - Checking route (3° try)
. 2018.02.18 23:20:51 - curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received
E 2018.02.18 23:20:51 - Checking route IPv4 failed.
. 2018.02.18 23:20:51 - OpenVPN > Initialization Sequence Completed
! 2018.02.18 23:20:51 - Disconnecting
. 2018.02.18 23:20:51 - Routes, removed a route previously added, 178.238.229.54 for gateway 10.4.0.1

While by contrast it normally looks more like this:
! 2018.02.18 23:33:00 - Disconnecting
. 2018.02.18 23:33:00 - Connection terminated.
I 2018.02.18 23:33:03 - Checking authorization ...
. 2018.02.18 23:33:12 - Updating systems & servers data ..., 2° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:33:23 - Checking authorization ..., 1° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
. 2018.02.18 23:33:32 - Updating systems & servers data ..., 3° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:33:43 - Checking authorization ..., 2° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
. 2018.02.18 23:33:52 - Updating systems & servers data ..., 4° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:33:53 - Cannot retrieve systems & servers data. (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:34:03 - Checking authorization ..., 3° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)

Either way, the curl 28 error is quite debilitating, as it doesn't matter where you connect to and there's no apparent reason to me why it happens.

After switching to TCP and unchecking "check if tunnel works" to no effect and still getting the same error mostly:

. 2018.02.18 23:49:20 - Checking authorization ..., 1° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:49:40 - Checking authorization ..., 2° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
. 2018.02.18 23:50:00 - Checking authorization ..., 3° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:50:20 - Checking authorization ..., 4° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
W 2018.02.18 23:50:20 - Authorization check failed, continue anyway (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
I 2018.02.18 23:50:20 - Cancel requested.
The client takes a long time to disconnect. At the first line, I had already clicked "cancel" and yet Eddie still tried completing all of the rest.

So then I tried logging out and logging back in. But now the problem is worse. Especially as when you're not logged in, you can't connect to anywhere, nor cancel the login attempt and I got a new popup:

W 2018.02.18 23:50:20 - Authorization check failed, continue anyway (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
I 2018.02.18 23:50:20 - Cancel requested.
I 2018.02.18 23:50:20 - Session terminated.
! 2018.02.18 23:51:51 - Logged out.
I 2018.02.18 23:52:01 - Checking login ...
. 2018.02.18 23:52:21 - Checking login ..., 1° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:52:41 - Checking login ..., 2° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
. 2018.02.18 23:53:01 - Checking login ..., 3° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
. 2018.02.18 23:53:15 - Updating systems & servers data ...
. 2018.02.18 23:53:21 - Checking login ..., 4° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
F 2018.02.18 23:53:21 - Cannot login. (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:53:35 - Updating systems & servers data ..., 1° try failed (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)
. 2018.02.18 23:54:07 - Updating systems & servers data ..., 2° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:54:28 - Updating systems & servers data ..., 3° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:54:48 - Updating systems & servers data ..., 4° try failed (curl: (28) Operation timed out after 20000 milliseconds with 0 bytes received)
. 2018.02.18 23:54:48 - Cannot retrieve systems & servers data. (curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received)

Finally, I turned off NL, tried SSH and then turned off "Check Air DNS" and I logged in instantly and connected moments later. I then disconnected, turned ON NL and switched to UDP. Left Air DNS unchecked. I still connected.

Sorry if the formatting is off. The forum software did this.

ultron

Do you have any plans upgrading OpenSSL to 1.1.0g version?

Or at least to 1.0.2n at first.

Thanks!

De Facto Pantalones

.

This tray icon issue aside, Eddie works just fine.

Any idea?

Seems that many are reporting tray icon issues. Not sure if this is relevant, but on Eddie 2.13.6 I was having problems w/ the Tray Icon. Windows 7 my OS. After various troubleshooting from the reset Tray Icon registry tweak to multiple clean installs... the solution to my problem was disabling a start-up program from my Gigabyte Motherboard. After turning that start-up program off (sorry, can’t recall what it was other than a motherboard tool, say GigabyteTuning tool (fortunately it wasn’t necessary to Run)... anyway, after tweaking start-up programs the tray icon worked like a charm.

I briefly tried new Beta and didnt have time to troubleshoot -so I can’t comment on 2.14 (but maybe the crux of the Tray Icon biscuit lay in machine hardware & its subsequent software not jiving w/ 2.14? *Mods -delete this is Im way off. Thanks

harold.lewis

Eddie 2.14.2 Portable_X64 Manjaro Plasma

fine but no tray icon

Monotremata

Weird, Sunday when I downloaded the new MacOS portable beta, it didn't work at all. It was stuck on 'Checking route' while connecting. I went back to 2.3.16 and it started doing the same thing there to any server I tried to connect to, and didn't allow me to connect until I deleted the .airvpn folder and started from scratch. I just decided to try it again (and made a backup of ~/.airvpn just in case) and today its working fine to connect to Castor. When I initially fired it up, it connected to Merope (the server I normally use) and I did a quick Speedtest, and actually got about 5x the speed I normally get using 2.3.16. Normally my connection tops out at like 5Mbps according to Speedtest.net when I connect to UDP and I can only get it to hit like 50 when I connect with TCP or SSH. Maybe Ill stick with the beta for awhile since its a little faster.

Oh and looks like the preferences still weren't updated either.. There is still no option to enable/disable IPv6 like there is in 2.3.16, so you still have to either reopen 2.3.16, or manually edit the airvpn.xml to get IPv6 to work with Castor.

ultron

Hi,

Starting Windows 10 x64 from hibernation mode with Eddie 2.14.2 running and connected results in the following recurring error:

Checking authorization ...
Windows WFP, unexpected: Rule 'ipv6_block_all' already exists

Unlike the user reporting the same issue previously, I do not have "Reconnect to last server at start" checked.

But I have the following set of options:

General - Connect at startup
General - Activate Network Lock at startup
Networking - IP Protocol user for connection: IPv4 only

Eddie_20180221_100119+.txt

Eddie 2.14beta released

Recommended Posts

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Guest

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Guest

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post

Share this post

Link to post