Staff

Hi! We're glad to know that the problem is solved. This is not an Eddie bug and never was in OS X or macOS. In Windows, Eddie 2.10.3 or older version had a bug for which the original DNS settings of a network interface missing one or both DNS settings could be not restored under certain circumstances, but it was fixed in 2.11. When the system is shut down without closing first Eddie, or in any case when Eddie is killed without grace, it can't of course restore settings, but this not a bug (no program can do anything when killed without grace). However Eddie keeps a safety backup and it will restore such settings at the next run/shut down cycle. Kind regards

Hello! We will be working on it, in the meantime follow the "News and Announcement" forum. An RSS feed is available. On that forum new topics are posted only by Air staff, so you can safely subscribe: the traffic is minimal. Kind regards

Hello! Of course, that's a very important feature of our servers monitor. Click on a server name and watch the various stats and graphs over time. Change the time resolution for every and each graph between 1 day, 1 week, 1 month and 1 year. Kind regards

Hello! Thank you, the feature you recommended will be available on the next (2.12.4) Eddie version. Kind regards

Hello! Let's underline that performance in the VPN has nothing to do with Eddie, while the handshake time is due to two factors: OpenVPN TLS handshake and key negotiation, and then Eddie testing routes and DNS. This second part has been greatly improved but it can actually be slower of some seconds. Since it is a procedure which occurs only once per connection it is inessential to discuss about it but you may disable both route and DNS check if you keep Network Lock enabled, because if the tunneling does not occur you will realize the issue anyway with Network Lock. Finally, a slightly lower TLS handshake speed can occur while we replace SHA1 signed certificates with SHA512 signed certificates, but this time difference is really minimal. Kind regard

Definitely, yes. Furthermore, in addition to the partition of trust (which by itself hugely strengthen the anonymity layer) Tor will not break a previous stream when establishing a new circuit, which makes the whole process "transparent" while each time you switch VPN server all the previous connections are lost, with a lot of inconveniences. Kind regards

Hi, what do you mean? Eddie talks with OpenVPN management. "killall openvpn" and Eddie will re-run OpenVPN and order it to connect to a server (in the white list if defined) in just a few seconds. However "killall openvpn" in your crontab every x minutes does not guarantee that Eddie will connect to a different server. Some custom directives are needed for this (remote-random and a series of remote entries in "AirVPN" > "Preferences" > "OVPN Directives"). About the original question @matrix_sec, you need to consider that every time you change VPN your connections will be reset. Kind regards

Hello! Top users speed range from 166 to 100 Mbit/s at the moment of this writing. Remember that guaranteed allocated bandwidth per client is 8 Mbit/s according to the Terms of Service and that 166 Mbit/s for the client translates into 166*2=332 Mbit/s on the server. Even 60 Mbit/s (i.e. 120 Mbit/s on the server) is a good performance in our infrastructure. We are very clear in our Terms of Service and in spite of them we provide great redundancy. We can't do anything else to make things clearer. Even if apparently you still fail to get it, we really can't do anything else to make things clearer. Kind regards

Version 2.12.3 (Sat, 04 Mar 2017 00:00:31 +0000) [bugfix] Windows - Error "Bad Access"[change] Windows - Better tooltip

Hello! All curl related errors seem to provide the same pattern: curl returns 'Bad Access' or 'Operation timed out after 10002 milliseconds with 0 bytes received'. This is not reproducible in any OS of our labs, we are still investigating the issue. In a Windows 10 machine with Comodo Firewall, Comodo prompts about allowing 'curl' process, and if we reply 'No' Eddie throws a similar error. In the meantime to those who have this kind of issue: please disable temporarily your firewall to understand at least if it's some packet filtering tool that blocks curl or it's a totally different issue. Kind regards

Eddie virtual RAM fingerprint is maximum 110 MB, not 5 GB (!). Please see and/or continue here https://airvpn.org/topic/21611-high-ram-usage-and-disk-io/ Kind regards

It's incorrect and you're right. We prevented displaying the IP address on the web site client area some time ago. Kind regards

Hello! This is currently not possible but it is planned. It will take time though, it's not for the very near future. Some privileges modulation and drop could be implemented in Eddie 3, the next major branch. However, this change has not yet been approved for Eddie 3, we can't guarantee it will not be postponed. Kind regards

Version 2.12.2 (Thu, 02 Mar 2017 11:52:35 +0000) [change] Proxy with Tor - Continue in any case if Guard IP can't be determined.[bugfix] Windows - Error "The given key was not present in the dictionary." when installing OpenVPN driver[bugfix] Windows - WFP issue under Vista (netsh wfp unavailable)[bugfix] Windows - WFP better rule about IPv6 block[bugfix] Proxy none auth conflict@puff-m-d - Your issue is fixed in the new version.@5YmkoLQZ - Still under investigation@blaHbluBB, @Keksjdjdke, @techocity - Please retry with the new version. Otherwise, please report your OS and if you normally use a proxy or not, thanks.

We have opened a subforum for all people using Eddie with other providers, including AirVPN competitors. If anyone is interested in experimenting this 'alpha' feature of Eddie, please read the pinned topic, and report here any feedback/issue. Thanks.

This is correct, expected and appropriate. This looks like either a problem in your system or in your line (for example, if the disconnection is caused by a real, momentary uplink outage) - but if you find a reliable way to reproduce the issue please feel free to publish it. We do not think that 150-200 systems out of 25-35000 (the amount of machines where Eddie runs almost every day) can justify your words. Quite the contrary. Even if we sum up all the tickets pertaining to problems with Eddie of all of our customers we have a rate of complaints lower than 0.3% in any fixed time frame, maybe 0.6% in specific periods of the year. It all depends on points of view but for a technical service like ours a range between 99.4% to 99.7% of "no complaining with Eddie at all" customers is a percentage that's simply outstanding, even fantastic. And then, of those 0.3-0.6%, in an overwhelming majority of cases the problem is in the system of the customer, not in Eddie. If you find any bug remember to include log, system report and a reliable way to reproduce the bug. Otherwise your words are useless and your time is wasted. Kind regards

Hello! UPDATE 16-03-17: EDDIE 2.12.4 HAS BEEN PROMOTED TO "STABLE VERSION" We're very glad to inform you that a new Eddie Air client version has been released: 2.12beta. It is ready for public beta testing and we consider it a Release Candidate of the 2.12 stable version. Anyway, remember that it's still a beta version, so if you don't feel adventurous you might like to stay with 2.11.15 (latest stable release). To download Eddie 2.12beta please select "Other versions" > "Experimental" from the download page. Latest release: 2.12.4 (Sun, 12 Mar 2017 19:39:02 +0000) This version features several bug fixes and a completely new way to handle http and https requests, now exclusively managed by curl. Please see the changelog: https://eddie.website/changelog/?software=client&format=html Do not hesitate to write in this thread if you decide to test Eddie 2.12beta and you find some glitch or bug. Kind regards & datalove Air Staff

In the near future there will be NO shift from HMAC SHA1 to HMAC SHA512. There is no reason for it. The change has been on some servers from SHA1 to SHA512 for VPN keys. All the other servers will be upgraded in a few weeks. Again, this has nothing to do with OpenVPN Data and Control channels authentication cipher, which is HMAC SHA, not SHA. Kind regards

Hello, the following paper is extremely important, because provides mathematical proof that HMAC is a PRF under the sole assumption that the compression function is a PRF. As long as the assumption holds true, as it is until now, after 10 years the paper was written, there is really no reasonable argumentation to grade "security" of HMAC SHA2 over HMAC SHA1. Or even HMAC MD5! https://cseweb.ucsd.edu/~mihir/papers/hmac-new.pdf Kind regards

Totally wrong. You can't access another user account. You can use the connection slots of that account (which, from a key, you obviously don't know anything of). And what's the point to perform a huge job, spend up to 800'000 USD, when you can have three connection slots for 54 EUR per year? When a collision successful attack will cost less than 54 EUR, then it will become more attractive than a regular subscription. For that time, though, all of our servers (and not only some) and clients will have already keys and certificates signed with SHA512. Actually, the upgrade will be completed in a matter of a few weeks, even if currently it is technically useless. About OpenVPN Data and Control channels authentication ciphers, it is HMAC SHA1, which is not SHA1. See zhang answer and link for more details.

Hello, new WFP based Network Lock does not "break port forwarding". It just sets WFP rules without touching the Windows Firewall. If you set Network Lock to work with Windows Firewall, Windows Firewall rules will be modified. Therefore, if you have Windows Firewall rules blocking incoming packets to the torrent client, Network Lock based on WFP will not modify them, obviously. Kind regards

AirVPN uses SHA1 to hash clients VPN keys and servers keys. Nothing else. Authentication digests for OpenVPN Data and Control Channel are HMAC SHA1 (or HMAC SHA384) where the mentioned problem is obviously irrelevant, not applicable. Some servers keys already use SHA512. A complete migration is due in some week. User will soon be able to regenerate directly a brand new set of features on devices management, currently under testing. It would cost around $500,000-$800,000 to replicate the computational effort Google did to find one SHA1 collision. Even if anyone wants to try it, the worst damage he/she can do is using the VPN access subscription of the targeted user. A regular subscription is astronomically cheaper. It would not even affect the ability to decrypt targeted user data or log in website. Not realistic. Kind regards

Very useful. Even for someone coming from Kepler 452b. Kind regards

The Investigatory Powers Bill scope is not applicable to our company, and it can be challenged after it has been found by the Europen Union Court of Justice incompatible with human rights and EU legal framework (EUCJ decision of December 21, 2016). After the defeat at the EUCJ, various parts of the Act pertaining to data retention are not operative and the technical implementation has been frozen. UK government announced "an appeal" against the decision. The Act provides three main lines of investigation: interception, interference and retention. The first two methods may cover datacenters in the UK, but they do not pose new challenges. The same can happen, and has happened, legally or illegally, virtually in any country in the world (see our article from 2011 about partition of trust). About retention, our policy does not change and any interferences with that will cause us to discontinue any server in the UK, just like we already did in France.. Kind regards