Eddie fails to connect once every 3-4 boots [Windows 10]

[Jeremiah Rose 0]

I made a previous post about a number of problems/bugs/usability issues with Eddie in Windows, but this post is about a specific problem.

Once every 3 or 4 times I boot my laptop, Eddie fails to start up correctly and connect to the VPN. I'm not sure why this is happening so I'll just post the log here. This is happening on a clean boot, and I can confirm there are no issues with my underlying internet connection. Has this been reported as a bug and are the Eddie team working on it? Are there any known workarounds? Do AirVPN provide refunds when their product is not working as it should?
 

. 2020.09.13 09:56:12 - Eddie version: 2.18.9 / windows_x64, System: Windows, Name: Windows 10 Home, Version: Microsoft Windows NT 10.0.19041.0, Mono/.Net: v4.0.30319
. 2020.09.13 09:56:12 - Command line arguments (0):
. 2020.09.13 09:56:15 - Raise system privileges
. 2020.09.13 09:56:20 - Profile path: C:\Users\Jeremiah\AppData\Local\Eddie\default.profile
. 2020.09.13 09:56:20 - Reading options from C:\Users\Jeremiah\AppData\Local\Eddie\default.profile
. 2020.09.13 09:56:23 - Tun Driver - 0901: 9.24.2; wintun: Not found
. 2020.09.13 09:56:23 - OpenVPN - Version: 2.4.8 - OpenSSL 1.1.0l  10 Sep 2019, LZO 2.10 (C:\Program Files\AirVPN\openvpn.exe)
. 2020.09.13 09:56:23 - SSH - Version: plink 0.67 (C:\Program Files\AirVPN\plink.exe)
. 2020.09.13 09:56:23 - SSL - Version: stunnel 5.40 (C:\Program Files\AirVPN\stunnel.exe)
. 2020.09.13 09:56:23 - curl - Version: 7.68.0 (C:\Program Files\AirVPN\curl.exe)
W 2020.09.13 09:56:24 - Windows WFP, recovery of pending rules.
. 2020.09.13 09:56:24 - Recovery. Unexpected crash?
. 2020.09.13 09:56:25 - Routes, removed an existing route, 173.44.55.155 for gateway 10.4.66.1
. 2020.09.13 09:56:25 - Routes, removed an existing route, 2607:ff48:aa81:200:89bd:a0e5:6626:b661 for gateway fde6:7a:7d20:42::1
. 2020.09.13 09:56:25 - Interface Local Area Connection metric restored from 3 to Automatic, layer IPv4
. 2020.09.13 09:56:25 - Interface Local Area Connection metric restored from 3 to Automatic, layer IPv6
! 2020.09.13 09:56:25 - Deactivation of Network Lock
! 2020.09.13 09:56:25 - Activation of Network Lock - Windows Filtering Platform
I 2020.09.13 09:56:26 - Ready
. 2020.09.13 09:57:46 - Cannot retrieve information about AirVPN: curl: (28) Connection timed out after 20013 milliseconds
I 2020.09.13 09:57:46 - Session starting.
I 2020.09.13 09:57:47 - Checking authorization ...
. 2020.09.13 09:59:06 - Cannot retrieve information about AirVPN: curl: (28) Connection timed out after 20012 milliseconds
W 2020.09.13 09:59:07 - Authorization check failed, continue anyway (curl: (28) Connection timed out after 20015 milliseconds)
! 2020.09.13 09:59:07 - Connecting to Acamar (United States of America, Miami)
. 2020.09.13 09:59:07 - OpenVPN > OpenVPN 2.4.8 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 31 2019
. 2020.09.13 09:59:07 - OpenVPN > Windows version 6.2 (Windows 8 or greater) 64bit
. 2020.09.13 09:59:07 - OpenVPN > library versions: OpenSSL 1.1.0l  10 Sep 2019, LZO 2.10
. 2020.09.13 09:59:07 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
. 2020.09.13 09:59:07 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
. 2020.09.13 09:59:07 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
. 2020.09.13 09:59:07 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
. 2020.09.13 09:59:07 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]173.44.55.157:443
. 2020.09.13 09:59:07 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144]
. 2020.09.13 09:59:07 - OpenVPN > UDP link local: (not bound)
. 2020.09.13 09:59:07 - OpenVPN > UDP link remote: [AF_INET]173.44.55.157:443
. 2020.09.13 09:59:08 - OpenVPN > TLS: Initial packet from [AF_INET]173.44.55.157:443, sid=ecc1f39a b7bdf8c7
. 2020.09.13 09:59:08 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2020.09.13 09:59:08 - OpenVPN > VERIFY KU OK
. 2020.09.13 09:59:08 - OpenVPN > Validating certificate extended key usage
. 2020.09.13 09:59:08 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2020.09.13 09:59:08 - OpenVPN > VERIFY EKU OK
. 2020.09.13 09:59:08 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Acamar, emailAddress=info@airvpn.org
. 2020.09.13 09:59:09 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2020.09.13 09:59:09 - OpenVPN > [Acamar] Peer Connection Initiated with [AF_INET]173.44.55.157:443
. 2020.09.13 09:59:10 - OpenVPN > SENT CONTROL [Acamar]: 'PUSH_REQUEST' (status=1)
. 2020.09.13 09:59:10 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.4.66.1,dhcp-option DNS6 fde6:7a:7d20:42::1,tun-ipv6,route-gateway 10.4.66.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:42::1064/64 fde6:7a:7d20:42::1,ifconfig 10.4.66.102 255.255.255.0,peer-id 2,cipher AES-256-GCM'
. 2020.09.13 09:59:10 - OpenVPN > Pushed option removed by filter: 'redirect-gateway ipv6 def1 bypass-dhcp'
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: compression parms modified
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: peer-id set
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1625
. 2020.09.13 09:59:10 - OpenVPN > OPTIONS IMPORT: data channel crypto options modified
. 2020.09.13 09:59:10 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM'
. 2020.09.13 09:59:10 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2020.09.13 09:59:10 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
. 2020.09.13 09:59:10 - OpenVPN > interactive service msg_channel=0
. 2020.09.13 09:59:10 - OpenVPN > ROUTE_GATEWAY 192.168.0.1/255.255.255.0 I=5 HWADDR=f4:63:1f:e2:a0:ed
. 2020.09.13 09:59:10 - OpenVPN > GDG6: remote_host_ipv6=n/a
. 2020.09.13 09:59:10 - OpenVPN > GetBestInterfaceEx() returned if=8
. 2020.09.13 09:59:10 - OpenVPN > GDG6: II=8 DP=::/3 NH=fe80::8
. 2020.09.13 09:59:10 - OpenVPN > GDG6: Metric=256, Loopback=0, AA=1, I=0
. 2020.09.13 09:59:10 - OpenVPN > ROUTE6_GATEWAY fe80::8 I=8
. 2020.09.13 09:59:10 - OpenVPN > open_tun
. 2020.09.13 09:59:10 - OpenVPN > CreateFile failed on TAP device: \\.\Global\{2F47B9AC-1B71-425A-B375-8958758F5BBA}.tap
. 2020.09.13 09:59:10 - OpenVPN > All TAP-Windows adapters on this system are currently in use.
. 2020.09.13 09:59:10 - OpenVPN > Exiting due to fatal error
! 2020.09.13 09:59:10 - Disconnecting
. 2020.09.13 09:59:10 - Connection terminated.
I 2020.09.13 09:59:13 - Checking authorization ...

[OpenSourcerer 1435]

7 hours ago, Jeremiah Rose said:

Has this been reported as a bug and are the Eddie team working on it? Are there any known workarounds?

It's not an Eddie bug, that's for sure. I'm not sure whether you can classify this as a bug, anyway, more like a hiccup. Try this:

• "Have you tried turning it off and on again?" – Disable and reenable the TAP adapter, then retry a connection.
• If not, uninstall TAP adapter via device manager, then relaunch Eddie. It will reinstall it.

7 hours ago, Jeremiah Rose said:

Do AirVPN provide refunds when their product is not working as it should?

While it makes sense to use AirVPN with Eddie, you can also use it with vanilla OpenVPN. As long as you still have a viable way to access your subscription, I doubt AirVPN will refund you as a gesture of goodwill. See also ToS section 9:
 

Quote

In case you are not satisfied with the commercial Service, once you have subscribed you have the right to obtain a full reimbursement, given that your request is sent within 3 commercial days from the subscription payment. […] The right to be refunded is invalid if You have violated the Terms of Service and/or if you send the request after having used the Service for more than 3 days and/or if you have used the Service for a global traffic volume exceeding 5 GigaBytes.

I believe you are past 3 days and 5 GB.

[Jeremiah Rose 0]

In what universe is the program failing to start up correctly every 3-4 boots not a bug?

Turning it off and on again does result in a connection, most of the time. However, the bug is in the fact that Eddie does not connect the first time.

Uninstalling and reinstalling TAP might fix it, I will give it a try. Regardless, if TAP is not working on the first install then this is an example of a bug.

Which brings me back to my first question - has this been reported and if not where can I submit a bug report? Also, is Eddie truly open source? I have checked out the GitHub but it seems that pull requests are not being merged?

Edited ... by Jeremiah Rose
Elaboration

[OpenSourcerer 1435]

9 hours ago, Jeremiah Rose said:

In what universe is the program failing to start up correctly every 3-4 boots not a bug?

While a bug can actually be conditional, if it failed at every boot, then yes, I'd see this as a bug. But it works in 2 out of 3 cases, and it works for the vast majority of other users with a similar setup than yours.
 

9 hours ago, Jeremiah Rose said:

Turning it off and on again does result in a connection, most of the time. However, the bug is in the fact that Eddie does not connect the first time.

Eddie is an OpenVPN wrapper, it doesn't connect itself. It triggers OpenVPN to connect, and OpenVPN configures TAP. If TAP experiences hiccups, you can't possibly say that Eddie is the problem, which is all the reasoning behind me telling you that I don't classify this as a bug. As written, bugs are somewhat universal, meaning, others would need to have exactly the same thing happening. But for the vast majority this works, leading me to believe that this is somewhat specific to your machine.
 

9 hours ago, Jeremiah Rose said:

Also, is Eddie truly open source? I have checked out the GitHub but it seems that pull requests are not being merged?

Yes, it is open source. Eddie is in the process of being rewritten completely (will be Eddie 3.x, maybe even another codename), which is why Eddie 2.x is developed more, erm, slowly. AirVPN's source code publishing guidelines seem to be that source code of newly written software is not published directly but only after release, which is what happened during Hummingbird beta, anyway. (Sources of these are on GitLab, by the way.)
Please also be advised, there are only two known developers for the softwares, clodo and ProMIND. The former is working on Eddie (and possibly Eddie 3.x), the latter on Hummingbird and Eddie for Android. In addition, work is being done on a common AirVPN library which all softwares of AirVPN use in the background, so you've got four projects maintained by two devs. While not impossible to manage, it sure makes prioritizing crucial, and things to be replaced like Eddie 2.x logically won't be at the top.

[Jeremiah Rose 0]

Thanks Giganerd for your reply.

I am a software developer and I disagree that this should not be seen as a bug. Any flaw in a piece of software that prevents it from working as it should (in this case, failing to elevate privileges and freezing requiring a system reset) is a bug, pure and simple, and needs to be fixed. If a bug only occurs on certain setups, that makes the bug harder to isolate and solve, but it will undoubtedly be affecting more users than the small percentage who choose to actively pursue the issue and submit bug reports.

So, is there no mechanism for reporting bugs in Eddie? Where do I create a ticket?

If the bug is in the OpenVPN codebase, or in TAP, then the Eddie developers need to bite the bullet and help make sure that their dependencies are bug free as well as Eddie itself. As AirVPN is a commercial enterprise with paying customers, this is doubly important.

I often see open source projects attempting to dodge responsibility for bugs, which results in many projects failing to fix basic usability errors. It is attitudes like this that perpetuate the perception that open source software is B grade, lacking polish, and usable for nerds only. Unfortunately I'm afraid this description does apply to Eddie in it's current state on Windows 10.

[OpenSourcerer 1435]

Well, then as a software dev it should be a piece of cake to analyze deeper what is happening on your machine there (see also: reproduction, because you are way more knowledgable about this than your regular user) and provide the Eddie devs with in-depth information on where this bug actually occurs for you. As a fellow believer in FOSS I'm sure you agree that this will help fix the bug for you and the others more quickly and avoid the toxic mindset that you shouldn't help a given FOSS software in any way just because it's developed by a commercial enterprise with money behind it, and "what can I possibly help with here", which might or might not further ignite the belief that FOSS is B-grade software.
 

7 hours ago, Jeremiah Rose said:

So, is there no mechanism for reporting bugs in Eddie? Where do I create a ticket?

There is none in Eddie. Bug reports should be submitted on the respective issue tracker, which ironically is in the very same GitHub repo you mentioned. Not sure why you chose to overlook this possibility, as a software dev, of all the trades.
 

7 hours ago, Jeremiah Rose said:

I often see open source projects attempting to dodge responsibility for bugs, which results in many projects failing to fix basic usability errors.

FOSS enables you to help fix this for the benefit of all. The code is there.