Staff

Hello! You are capped through traffic shaping. either enforced by yourself (check any filtering tool on your router and system) or more likely by your ISP. Note how TCP is faster than UDP. This makes no sense in an agnostic network because OpenVPN is much faster in UDP, so it's a strong clue hinting to traffic shaping. Test an "OpenVPN over SSL" connection to port 443 (a good approximation of HTTPS so to say), or a tls-crypt featured connection to entry-IP 3 or 4 to see whether they can mitigate or bypass the throttling techniques. Also consider to change ISP if possibile. You can change connection mode in Eddie Preferences > Protocols. Remember to click "Save" and restart a connection each time you change setting to apply the change onto OpenVPN. Kind regards

Hello! An additional information for those who need larger buffers when using Eddie: you can enter custom directives rcvbuf and sndbuf in "Preferences" > "OVPN Directives" custom directives field. Click "Save" after you have entered them and restart a connection to apply the change onto OpenVPN. The syntax is: rcvbuf receive_buffer_size sndbf send_buffer_size where receive_buffer_size and send_buffer_size are in bytes. Example: rcvbuf 1048576 will tell OpenVPN to create a 1 MB (1048575 bytes) receive socket buffer. Kind regards

Hello! We would like to investigate, your specific case is interesting. Your node is behind DSLite stack, with only IPv6 connection (IPv4 is encapsulated in IPv6), but you appear to have only IPv4 in the tunnel. Can you post a system report taken just after the problem has occurred to check Eddie settings (in particular about how it must handle IPv6)? "Logs" > life belt icon > copy all > paste into your message. Kind regards

Hello! Confirmed and reproduced in RC1 and Oreo. We are currently testing internally a fixed version. If everything goes well you will see RC2 quite soon. Kind regards

Hello! Yes, that's the option you look for. In the option comment you should be able to read: "Pause VPN when the screen is off. When this option is enabled, no traffic will be generated by the VPN when the screen is off. This also saves battery when the screen is off." Kind regards

Hello and thank you for your report! Can you please make sure that the option "Show notification" is ON? If it's turned off, Android can put the application to sleep according to its own resources management, causing VPN disconnection (Eddie displays a warning about that anyway). Please feel free to keep us posted. Kind regards

Hello! It surely can lower you anonymity layer and even for other, somehow more serious reasons. That's why we don't log the port history and you can delete a forwarded port anytime. Also, it is very important that you keep Network Lock enabled when you remotely forward port. Really important. Not that someone needs to worry about copyright trolls and similar bums, but if you need to listen to a port for some very sensitive activity in some hostile to human rights environment, keeping Network Lock enabled and deleting the port soon after the usage may help you sleep slightly more comfortably. Note that for "deleting the port" we mean that you delete it from your account panel as well as you change it from the configuration of your listening service(s). Kind regards

Hello! Of course. Documentation and instructions will be published before the release of the stable version. Kind regards

Hello! A 100% safe traffic leak prevention outside the VPN tunnel (we guess you mean that with "kill switch", is this right?) is impossible on a machine you don't control as root (administrator) but Eddie will perform a best effort to prevent leaks just like any other OpenVPN based application on Android. Please make sure that "TUN persist" and "Pause VPN ..." options are both active for this purpose. About the event you report, can you please add some more details? When you switched from WiFi to LTE, did OpenVPN disconnect and then never re-connected until you restarted Eddie? Can you reproduce the issue and post the full OpenVPN log taken after the problem has occurred? Kind regards

Hello! We're very glad to inform you that Eddie 1.0 Release Candidate 1 has just been released. RC1 has been linked against mbedTLS (formerly known as "PolarSSL") instead of OpenSSL. This decision has been taken because, according to our tests, performance with OpenSSL and mbedTLS is identical, while mbedTLS ensures a longer battery life under intensive usage: approximately a 10% improvement. This change also makes the package lighter. We warmly invite you to test as much as you can and report any glitch and bug you should find. We would like to thank all the beta testers so far: thanks to them the development cycle has been very fast and we are so near to release a stable version. Thank you! As usual Eddie is free and open source software released under GPLv3. You can participate to the beta testing by joining the beta community in the Google Play Store here https://play.google.com/apps/testing/org.airvpn.eddie Alternatively, if you don't want to access (or you have no access to) the Google Play Store, the apk can be downloaded from our Eddie web site here: https://eddie.website/repository/eddie/android/1.0rc1/org.airvpn.eddie.apk Kind regards and datalove AirVPN Staff ChangeLog.txt ChangeLog-1.0RC1.txt

It should not be a problem to extract a string with the IP address of the default gateway of the tun (or whatever) interface, with something like: pingip=$(ip route list dev tun0 | grep link | awk -F '/' {'print $1'} | sed 's/\.0/\.1/g') ping $pingip Fix and refine it according to your needs and pfSense nomenclature, interface names... Note that the last "sed" invocation is gross because it just replaces any ".0" with a ".1" so it will not work if you have a gateway with a 0 octet that's not the last one. Kind regards

Hello, why can't you get the VPN gateway address at each connection and automatically use it for your purposes? Kind regards

Hello! As a first check, please make sure that in Preferences > Network Lock the combo box Mode is NOT set to None. Kind regards

Hello! It's a delicate matter because GPL (and other licenses) are incompatible with Apple policy. Executive summary: Apple will not approve free and open source software, and we like to release only free and open source software. Apple business model on mobile devices is heavily based on restricting customers freedom (even the most trivial operations are locked in Apple devices). It would be irrational to allow software released with a license that's a major menace to a business model which works great. Longer analysis of the aforementioned incompatibility can be found in FSF articles and others. Kind regards

Hello, now it's very clear, thank you. Notifications on the issue will be sent shortly. Kind regards

Hello! Probably we're missing something here so we will leave the discussion to the developers with an invitation to clarify in the meantime: since plink.exe has been included in Eddie package for Windows since many years ago with its MIT license, with the correct digital signature (Simon Tatham is the author https://www.chiark.greenend.org.uk/~sgtatham/) what is the change that's causing any issue? Kind regards

You can ping the VPN default gateway address as usual. Kind regards

Hello! Our Configuration Generator will generate any profile according to your preferences. It's available in your account "Client Area" in our web site. Next Eddie version will feature servers choice (similarly to the desktop edition), so that you will not even need to import profiles (Eddie will create them for you dynamically according to your preferences). Kind regards

Hello! List of Gen2 servers as of 14-July-18. Total: 87 servers. WRONG LIST - DELETED Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.16beta. It is ready for public beta testing. How to test our experimental release: Go to download page of your OSClick on Other versions Click on Experimental Look at the changelog if you wishDownload and installPlease see the changelog: https://eddie.website/changelog/?software=client&format=html

Hello! Thanks, this could be a bug. When you set a timeout value in Eddie, Eddie passes it to OpenVPN 3. However, our servers push "ping-restart 60", to decide when a connection must be considered "over" in UDP. This directive seems to override the Eddie setting. We will investigate. Overview: UDP is connectionless, so when you connect in UDP two OpenVPN nodes, each party can NOT know whether the other one is still alive. That's why each party "pings" the other (in our service every 10 seconds, inside the tunnel) and if no reply is received in 60 seconds to any "ping", a party considers that the other party is no more there. Lowering the keepalive from our side is an option, as well as fixing the possible override on Eddie settings, however this is a delicate matter because too low values can cause (especially in mobility) a bunch of disconnections which could be avoided. Consider that the OpenVPN default setting is 120 seconds, we already lowered it a lot. We will study the problem carefully. In the meantime, if you need an immediate reaction to a loss of connection, please connect in TCP. Only TCP can detect in a very quick time that the other party is no more there. UDP can not, simply because it's connectionless. Thank you again. Kind regards

Hello! We confirm that we can't see any problem with RAI. About Mediaset, we should have sorted the issue out, can you please try now? Kind regards

Hello! It's a good choice to have flexible and always up bootstrap servers. Bootstrap servers just pass encrypted data through, they do not store anything, but if they are all down Eddie will not work. So the priority is having several machines which can be duplicated on different addresses in a matter of seconds inside an infrastructure which is hard to black list as a whole. Kind regards

Hello! We do not see this problem with RAI (tested from a few random servers around the world). Can you list the server(s) you experience this problem on? Mediaset problem is confirmed and we're checking. Kind regards

Hello! You can use Network Lock with Tor over OpenVPN. However you can't use it with OpenVPN over Tor, because the Tor guard entry-IP can't be known before the Tor circuit is established. Kind regards