Staff

@dL4l7dY6 Hello and thank you for your tests and report! Orion does exist so the error message is surely wrong. Maybe it is triggered by a wrong key name, can you please make sure that the key name (in goldcrest.rc option "air-key") matches exactly the "device" name in your control panel (i.e. "Default")? What happens if you don't specify any key in goldcrest.rc? The suite log entry calls "profile" what your account control panel calls "device", according to the label picked in Eddie Android edition (not to be confused with an "OpenVPN profile", which is a configuration file). In reality "profiles" and "devices" in this context are all labels for client certificate/key pairs, and the suite correctly defines them as "keys" in the options.. We will work to make labels more coherent between Bluetit, the website and Eddie., and avoid calling them "profiles" to prevent confusion with OpenVPN profiles. Bluetit and Golcrest already avoid "profile" label, what you see in the log must be some "remainder" in logging. Please keep us posted. Kind regards

@Maggie144 Hello! Thanks, glad to hear the problem is resolved. The feature you mention is available in Goldcrest+Bluetit https://airvpn.org/forums/topic/48435-linux-new-software-airvpn-suite-10-beta/. They will be ported to macOS too, in 2021 first quarter. Kind regards

@Hiroo Onoda Hello! Please discard our previous message. There is no such permission on stock Android 10 versions The wrong answer was based on a customized Android version we use. We apologize for any inconvenience. Currently Eddie can not boot automatically in Android 10 and 11 unless you start it with third party boot managers etc. The issue will be addressed in the next Eddie release, stay tuned. Kind regards

Hello! We're very glad to inform you that OpenVPN AirVPN 3.6.6 is now available. It implements data-ciphers directive following the same OpenVPN 2.5 directive syntax for a more flexible and comfortable choice of Data Channel ciphers by the client side, including CHACHA20-POLY1305 whose support was added by AirVPN in 2019. OpenVPN AirVPN now handles Data Channel cipher by complying to new OpenVPN 2.5 specifications while keeping backward compatibility with older than 2.5 OpenVPN versions. For additional comfort and backward compatibility, support to ncp-disable directive implemented by AirVPN is currently kept. Please see the changelog for more details. AirVPN Suite 1.0.0 software suite for Linux is already linked against the new library. Eddie Android edition will be updated accordingly in the near future. Updated macOS software based on the new version is planned as well. Hummingbird 1.1.1 for macOS will be released soon and linked against the new library. OpenVPN AirVPN 3.6.6 is now 93 commits ahead of master branch. Source code is available on GitHub: https://github.com/AirVPN/openvpn3-airvpn Changelog 3.6.6 AirVPN - Release date: 7 December 2020 by ProMIND - [ProMIND] [2020/11/02] openvpn/ssl/proto.hpp: IV_CIPHERS is set to the overridden cipher only (both from client and/or OpenVPN profile) in order to properly work with OpenVPN 2.5 IV_CIPHERS specifications. The old method of cipher overriding by means of negotiable crypto parameters is still supported in order to maintain compatibility with OpenVPN < 2.5.0 - [ProMIND] [2020/11/24] openvpn/ssl/proto.hpp: added "data-ciphers" directive to profile config .ovpn files in order to comply to OpenVPN 2.5 negotiable data cipher specifications. In case "data-ciphers" is found in the .ovpn file IV_CIPHERS is assigned to the algorithms found in "data-ciphers". In this specific case, "cipher" directive is meant as a fallback cipher and, if not already specified in "data-ciphers", is appended to IV_CIPHERS Kind regards & datalove AirVPN Staff

@clebretonfr Hello! Please consider that dnsmasq is not supported by Blutetit or Hummingbird. If you use it, DNS resolution is up to you exclusively. If DNS queries do not reach a third party DNS server, an option to consider is that the third party DNS rejects queries from AirVPN server(s). About the problem at cold start, it will be investigated, thank you for your report! Kind regards

@Maggie144 Hello! Route check is performed by Eddie, not by Hummingbird. Can you please run Hummingbird alone, without Eddie, and check whether you still have the delay you report during a connection? If you determine that the delay is caused exclusively by Eddie route check, and you keep Network Lock enabled, you can safely disable route check and save a lot of time. Route check is redundant when Network Lock is enabled. You can disable route check in Eddie Preferences > Advanced window. De-tick "Check if tunnel works" item and click "Save". Currently, Hummingbird 1.1.1 beta 2 is being tested publicly in Linux, When a stable version is released, it will be ported to macOS too. Kind regards

@SomewhatSane Hello! Try to enlarge buffers to 1 MB or even 2 MB. Directives to set OpenVPN buffer size: rcvbuf x sndbuf y where x and y are in bytes. For example, for 1 MB buffers: rcvbuf 1232896 sndbuf 1232896 It must also be said that, in order to beat 500 Mbit/s, you need some luck, i.e. you need finding a server that in some moment has a very low bandwidth requirement by other clients. Also, if you have an AES-NI supporting system but a less powerful CPU, try AES-128-GCM. Kind regards

@Check Hello! What crashes are you referring to? In the last months we had no crashes on UK servers. Check the server monitor for several technical details that you should find useful. Kind regards

@Braguette A transaction ID is not a personal information, but a code created pseudo-randomly, so it would be an error to cover it in a Privacy Notice and Terms document. Anyway it is stored in the payment processor database forever. If a customer asks for a refund, she must provide the needed data to make the refund possible, or simply ask the payment processor for a refund via the proper procedure implemented both in 2Checkout and PayPal. If the payment was delivered directly without intermediaries (i.e. through cryptocurrency which we accept cutting out any intermediary), the customer asking for a refund must again provide us with the proper data to let us verify refund eligibility, for example transaction hash in a blockchain. Kind regards

Hello! We do not retain data on AirVPN servers. Data remains forever in your and our PayPal account,, as well as in your credit card company database, though. However that's a matter of PayPal or your credit card issuer privacy policy. In our privacy notice we address this fact here: Thank you very much for your choice. Enjoy AirVPN! Kind regards

Hello! Android 10 and 11 change slightly the apps permission scheme. Now you need to explicitly authorize, from Android settings, an app to start at boot. It's no more sufficient that an app registers itself to start. Additionally, an explicit authorization to read the storage must be given, to allow Eddie to read profiles, nothing else. Can you please check? We are looking forward to hearing from you. Kind regards

@clebretonfr Thank you very much for your tests and for the great feedback! We are investigating the issue at system start you have reported in our Raspberry systems. The Data Channel ciphers you specify in bluetit.rc are those which are allowed by the daemon, thus they are a set enforced by the superuser. The Goldcrest user can then pick any cipher inside that set. Have you noticed some discrepancy from the expected behavior?  This is a server side problem which we will have to face sooner or later. It is not relevant anyway at this stage. Kind regards

@john roberts Hello and thank you very much for your tests! Because the daemon, Bluetit, is not running.Goldcrest is just a client. We see that you run it with root privileges, therefore you destroy a part of the security model created with the new architecture. Please consider not to do so. There is no special procedure, ideally. Even a brutal reboot is fine and must not create the problem you experience. We are trying to reproduce it in Fedora 33. Can you please tell us exactly what you do to reproduce the problem, including how you shut down the system exactly, step by step? We ask because we failed to reproduce the issue in Fedora 33 even by trying a brutal "reboot" from a root terminal inside a Desktop Manager. That would not work in our case. We want to maintain the lock file because Bluetit must NOT start if its previous exit was abnormal. We are talking about firewall rules, DNS settings and routing tables here, so it is expected that the superuser intervenes manually in such cases, no automatic solution is proposed. The only automatic fix is --recover-network aimed at rescuing previouis firewall rules and DNS settings. Then the superuser must remove manually the lock file after she has ascertained that anything else is fine, for example that no other Bluetit instance is running for real. Yes, we will clarify it in the next documentation version. Also remember that Goldcrest can NOT do --recover-network or anything else, when Bluetit is not running. We are looking forward to hearing from you about the reboot procedure you follow to help us reproduce the issue in Fedora 33. Thanks again! Kind regards

@OpenSourcerer Hello! Your air-6to4 directive has an invalid argument, yes: it should be on. The returned error message "Unknown directive" is unexpected: that's another issue under investigation now. Can you confirm that air-6to4 on resolves the issue and tunnels IPv6 over IPv4 when the connection is over IPv4? Your suggestion during the internal beta testing has been adopted, but not yet implemented in beta 2. Starting from next release, yes - on - 1 - true on one side and no - off - 0 - false on the other side will be treated as equivalent arguments / synonyms by the parser. 👍 Kind regards

Thanks! For that purpose, in vanilla OpenVPN you need as usual setenv UV_IPV6=yes - in AirVPN servers only of course - since when we started to support IPv6 fully. We failed to reproduce the "unknown directive" error for air-6to4 in goldcrest.rc - can you please check which exact char is after the "4" ? Maybe it is a parsing problem with blanks. The parser expects either \n , \t, \v or blank space. Kind regards

@OpenSourcerer Yes, we are in an endless loop with Play Store. We submit for Android TV and it is rejected immediately (like, after a tenth of a second from the submission, it's like something set automatically to reject). We ask for a revision and a robot answers with a ton of conditions as pre-requisites for Android TV approval, which we already knew perfectly when we designed the application. We ask which condition is not met and a human answers that it is not allowed to open banners in an Android application. We ask which banner they talk about, and we are replied "banners in airvpn.org", with a years old screenshot, which was true years ago (the "banner" was simply the option to use that plug-in aimed at following threads more comfortably from mobile devices, we wiped it out a long ago), but not anymore since years. When we reply that it is no more true since years ago, we get silence from Google, and the app remains "incompatible with Android TV". We repeated the whole cycle with appeals and new requests at each new versio and we always experienced the identical loop (automatic rejection, bot response, human very old, identical pre-packaged response). We guess we should start a brand new project to get out of the vicious loop, maybe, and maybe we should suppress completely the web view routines in Eddie (which would be anyway not acceptable). Even if the banner was still in airvpn.org (which is not) then, according to the same logic, no browser should be approved for Android TV, because any browser can open a web site with a banner. Kind regards

@OpenSourcerer OK! That's expected behavior. You need to set air-6to4 to on and connect in IPv4 if you wish IPv6 over IPv4. Please check and verify whether everything is OK. Explanation: since 2016 or 2017 our VPN servers are customized to push IPv6 routes only if client sends a user variable IPV6 containing value yes. Otherwise no IPv6 routes are pushed: that's necessary indeed, in order to avoid older OpenVPN versions numerous bugs on IPv6 and also make IPv4 connections possible to those systems which do not support IPv6, otherwise any OpenVPN version older than 2.5 would invoke "ip route" or "route" commands which would fail and cause OpenVPN to exit immediately. Insofar, a client must include directive setenv UV_IPV6=yes for OpenVPN to get IPv6 push and tunnel IPv6 over IPv4 (see also Configuration Generator generated profiles). Bluetit and Hummingbird will have OpenVPN3 library set IPV6 variable to yes only when air-6to4 is on and by default it is off. We are considering to change 6to4 to on by default, if IPv6 is detected as supported by the system. Kind regards

Hello! That's strange because absolutely nothing changed in IPv6 detection between internal beta 1, beta 1 and beta 2. Let us know if the problem re-appears. Are IPv6 routes pushed by VPN servers and the push is ignored, or are IPv6 routes not pushed at all? Is 6to4 option on? Can we see the log and the settings pertaining to the 2nd problem. i.e.connection over IPv6 when IPv4 is expected? The expected behavior by Bluetit is: connect in IPv6 whenever user employs IPv6 remote addresses or options in Goldcrest, except when 6to4 option is active, in which case, if possible, connect in IPv4 and tunnel IPv6 over IPv4. Kind regards

Hello! Google Play Store never approved Eddie for Android TV because it opens https://airvpn.org showing banners, according to Google. Of course this is not true (it's true that Eddie may open airvpn.org upon user's request, but it's not true that airvpn.org contains banners), but the ban is permanent for each release, so we can try to re-submit Eddie for Android TV only with a different release for the 15th time and see what happens. Kind regards

Hello! For the reason we explained, common address pools in datacenters with (c) trolls. Not that it must be the case, of course. Kind regards

Hello! Just in case: if the proper option is enabled, Eddie will start and connect at (re)boot only if it was running and was connected exclusively through a profile (and not with any other method) when the device was shut down previously. Also, some Android devices (for example all the Asus ones we know) include a boot application manager which by default will not authorize any app (apart from those by the manufacturer) to start at boot. Such boot managers must be configured additionally, for Android app clearance to start at boot is not sufficient. Kind regards

@polomintus Hello! Can you take note whether the amount of peers receiving your chunks are the same both with and without VPN? If less peers ask for data chunks when you're in the VPN, it's possible that the other part of them use black lists blocking huge IP address pools common to us and copyright trolls and/or swarm poisoners (these two groups are not necessarily distinct ), hence your lower upload when in the VPN. Kind regards

@User of AirVPN Congratulations! We confirm (and anyone connecting to the server monitor can do the same) that today we have had a 1.4 Gbit/s peak on Sharatan, so you were devouring most of the bandwidth. Can you also state the CPU, if you don't mind? Kind regards

@polomintus Hello! The monitor correctly shows the amount of online sessions, not online users, connected to each VPN server (or country etc.). That said, Nash and Matar are in the same datacenter, have the same configuration and very similar hardware They are also served by the same transit providers. Therefore, so it's not easy to think of a satisfactory explanation. We could start from the fact that our servers in Alblasserdam are connected to a pool of several 10+ Gbit/s lines and more than one high volume router, but we can not see any symptom of congestion in any rack in Alblasserdam, as you indirectly noticed too. In any case, connect to the server(s) that can provide you with the best performance. Kind regards

@pjnsmb Hello and thanks! Documentation remains the one you see. It will be updated when possible and anyway not later than stable version release date. At the moment it is perfectly valid for beta 2 version, you can rely on it safely. Kind regards