Jump to content
Not connected, Your IP: 3.236.253.192

Staff

Staff
  • Content Count

    9124
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1348

Everything posted by Staff

  1. Hello! Sure, porting our software to ARM based Mac machines is an option we are seriously considering because during 2021 (and maybe 2022) Mac Apple will abandon development of x86-64 based computers completely. Stay tuned. Kind regards
  2. Hello! Through round trip times differences, discernment between geographically near locations of servers whose traffic is served by the same transit provider is very hard or not possible, because the deviation may remain inside the range of the experimental error. Anyway if you want to try, use mtr, gather a sufficiently vast set of experimental data and process it according to what statistics teaches. Tests with YouTube mean literally nothing for obvious reasons. M247 operates servers in co-owned datacenters and not. Server locations are correct to the best of our knowledge, according to M247 claims and consistent with technical verification. M247 servers in Phoenix operated by us are located in Phoenix, in the following Cogent datacenter: https://www.cogentco.com/en/cogent-phoenix Bootes (Phoenix) IP addresses are in 193.37.254.0/24, a block property of M247 (AS9009) and employed in Cogent above mentioned datacenter. https://ipinfo.io/AS9009/193.37.254.0/24 You can verify via mtr the last replying hops and check the different final route with M247 servers in Los Angeles (Teegarden,. Grrombridge). Normally traffic in Phoenix is served by Cogent while in Los Angeles mainly by NTT. Disclaimer: IX location where the provider has a POP may not match datacenter location, for example our servers in Alblasserdam (NL) are in Alblasserdam but have direct lines to AMS-IX, which is in Amsterdam. We report anyway Alblasserdam as it is the town where the servers and its high volume router(s) physically are. Kind regards
  3. @pjnsmb Hello! Yes, it runs fine in Debian stable releases. Momentarily, problems occurring in unstable distributions are not addressed, but that does not mean that they won't be addressed in the future. Furthermore, it is also possible that problems get resolved in time, while unstable distribution bugs are resolved. Kind regards
  4. @krytellan Hello! Eddie 2.12.4 is very old and is packaged with and linked against software which does not support anymore the new encryption requirements by AirVPN. Please upgrade and the problem should be resolved. NOTE: Windows 7 is an abandoned system and latest Eddie versions are no more tested in Windows 7. If you experience issues with latest Eddie release, please run Eddie 2.16.3. To download Eddie 2.16.3: browse https://airvpn.org/windows click "Other versions" click "2.16.3": you will be brought back to the download page, pointing this time to Eddie 2.16.3 select the correct system Windows 7 select the correct architecture (32 bit or 64 bit, please check) download and install as usual Kind regards
  5. @fkeriviavcxjhvjke Hello! You have three options. 1) Run AirVPN Suite 1.0.0. It will take care properly of DNS push even when systemd-resolved is configured to work in on-link mode bypassing resolv..conf and even when it works together with network-manager. Tested successfully under new Fedora 33 default settings. The suite is free and open source software by AirVPN, based also on a robust client-daemon architecture, and offers Network Lock (for traffic leaks prevention) which works fine even in Fedora 33. See here: https://airvpn.org/forums/topic/48435-linux-new-software-airvpn-suite-10-beta/ 2) Disable systemd-resolved and re-create /etc/resolv.conf file to work with global DNS as usual, instead of the questionable and dangerous per-link basis mode. After that, you can either run AirVPN Suite 1.0.0, OpenVPN with update-resolv-conf script, or Eddie. Eddie is a free and open source software by AirVPN with a GUI running in Mono. Only when systemd-resolved is disabled or re-configured to respect /etc/resolv.conf, can Eddie be used in Fedora 33. If you choose to run OpenVPN directly, remember that OpenVPN does not handle DNS push on Linux on the client side, so use the mentioned script. Please see here: https://airvpn.org/forums/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ 3) Not recommended. Run OpenVPN with script update-resolved-systemd. Again see https://airvpn.org/forums/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ Kind regards
  6. @dibble Hello! Eddie is compiled for x86-64. If you're running an ARM based Mac, you should run Eddie in Rosetta 2, can you please check? We have some reports according to which Eddie runs fine in Rosetta 2, and other reports claiming that Eddie freezes. Please send us your report as well. Kind regards
  7. @Point Zero Hello! Try to delete the default.profile file. It's Eddie configuration file. You can find its location by reading the first Eddie log entries. Make sure that Eddie is not running, then delete the file, finally re-start Eddie and check whether the problem is resolved. Eddie will re-create a profile with default settings. Note that you will need to re-enter your AirVPN credentials and custom settings. Kind regards
  8. @colorman Hello! That's great, thank you! Case dismissed. Kind regards
  9. @colorman Hello! Can you please upgrade to 1.0.0 RC 1? Check the links in this thread first message. Also, can you please clarify which version did not have this problem in your machine? You're still running Bluetit version 1.0.0 beta 1... after that, beta 2, beta 3 and RC 1 have come out. Feel free to elaborate. Anyway, you're running Bluetit beta 1 and Goldcrest beta 3. Goldcrest beta 3 expects new messages (D-Bus comms have been improved with beta 3), that did not exist in Bluetit beta 1. Jump directly to RC 1 (both Bluetit and Goldcrest, important) and check what happens, thanks! We are looking forward to hearing from you. Kind regards
  10. @colorman Hello! Can you please send us Bleutit log taken after the shell does not give you back the prompt when you stop Goldcrest with CTRL-C, and when you get the DBusConnectorException: DBusConnector: not primary owner (2) error? In both cases, from a terminal: sudo journalctl | grep bluetit Thank you in advance. Kind regards
  11. @misam We see, thank you. You can delete that file and then run Hummingbird. Fixes will be implemented in the next AirVPN-Suite release or release candidate (stay tuned in the AirVPN Suite thread after Christmas). https://airvpn.org/forums/topic/48435-linux-new-software-airvpn-suite-10-beta/ Kind regards
  12. @OpenSourcerer Hello! The following line is puzzling as we can't reproduce it: 2020-12-24 11:34:06 ERROR: Key "My Key" does not exist for user opensourcerer unless of course you typed \"My\ Key\" which is not the case, we guess. Very puzzling indeed. Can you send us the content of your IFS variable, just in case, and make sure to run Goldcrest from the very same account you print IFS content from (running Goldcrest as root is unnecessary and deprecated anyway)? Maybe it will help shed some light. od -abc <<<"$IFS" We are looking forward to hearing from you. Kind regards
  13. Hello! We will investigate more thoroughly, but if you fail to resolve the name only from some VPN servers DNS, then a very plausible explanation is that the authoritative DNS for the FQDN you try to resolve does not answer to some of our DNS servers. Each VPN server runs its own DNS server, so if the block is selective, you will be able to resolve the name from some VPN servers only. In such a case, a quick workaround is editing your hosts file and force the correct resolution, for example add the line: 185.104.45.58 sport-video.org.ua You can edit your hosts file with any text editor. You will need administrator privileges. Kind regards
  14. @colorman Hello! Thanks, we will re-open the investigation on the issue (we remember you reported it identically weeks ago and we thought it was addressed - something must have gone wrong). Can you confirm that your distribution is openSUSE 15.2? Kind regards
  15. @misam Excellent, thank you, bug detected, it will be fixed! ✌️ You should be able to start Hummingbird. If not, please read on. You will need to delete some files manually. If deletion is necessary, before you delete please let us know the directory content: ls -l /etc/airvpn Finally: sudo rm etc/airvpn/hummigbird.lock /etc/airvpn/resolv.conf.airvpnbackup /etc/airvpn/systemdns.airvpnbackup Then start Hummingbird and check whether everything is fine again. We are looking forward to hearing from you. Kind regards
  16. Hello! Space, by default, is one of the internal field separators in any shell, together with tab and newline. If you need a space in any option argument, and you have the space as IFS, you must enclose the argument in double quotes, either in the command line or in a configuration file. It will happen with any argument of course, so passwords too, nothing interesting here. Therefore, the behavior is correct and expected, and we were hunting fairies for days. However, if you already enclose the arguments in double quotes and/or you have modified your IFS environment variable to NOT consider space as an IFS, then the problem is real. We can archive the issue.now unless you tell that there's a match with one of the the mentioned cases. Kind regards
  17. Hello! We're very glad to inform you that AirVPN Suite 1.0.0 RC 1 for Linux has just been released. It addresses all the problems reported so far, except: problems reported in unstable distributions but not occurring in the same distribution stable release the specific problem reported by @OpenSourcerer as we failed to reproduce it: please report if you find anything similar to what OpenSourcerer has reported because we can't manage to reproduce the malfunction in spite of very many efforts Links to download packages have been updated in the first message of this thread. Kind regards
  18. Hello! We're very glad to inform you that Hummingbird 1.1.1 RC 1 for macOS has been released. No bugs have been found or reported during the public beta testing, Therefore, we expect that the stable release will be out soon. Please report any glitch or bug in this thread. Kind regards
  19. Hello! We're very glad to announce a special promotion on our long terms Premium plans. You can get prices as low as 2.20 €/month with a three years plan, which is a 68.6% discount when compared to monthly plan price of 7 €. You can also send an AirVPN plan as a gift: you have the option to print or send a colorful, dedicated picture with the code to activate the plan. You can do that in your account Client Area -> Your membership: Purchase and credit -> Print X-Mas after you have bought a coupon. Code shown in the above picture is an example, not a real code If you're already our customer and you wish to stay aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. Please check plans special prices on https://airvpn.org and https://airvpn.org/buy Kind regards & datalove AirVPN Staff
  20. Hello! We're very glad to inform you that a new 10 Gbit/s server located in Zurich (CH) is available: Xuange. It's the first server we propose with a dedicated 10 Gbit/s line and port. As we have now circumvented several computing limits through load balancing and improved optimization, it's time to gradually test larger bandwidth. The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other Air server, Xuange supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Xuange Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team
  21. @OpenSourcerer Thanks, that simplifies things because we can test in the same environment you have with your landline provider. EDIT: do you get the same problem both from Arch and Debian 10? Kind regards
  22. @OpenSourcerer Exactly... so it can't be that. You had better ask your ISP. Probably it has nothing to do with the malfunction but you never know. In order to cross-check that T-Mobile uses IPv6 only network with a NAT64-like implementation (464XLAT, which is considerably superior than the original NAT64) you can check the official T-Mobile documents. T-Mobile USA announced "breaking free of IPv4" and 464XLAT for IPv6-only network in Apricot 2014, see for example here: https://conference.apnic.net/data/37/464xlat-apricot-2014_1393236641.pdf From other documents such as https://together.jolla.com/question/89966/use-dual-stack-ipv4-and-ipv6-on-mobile-data-by-default/ we infer that T-Mobile Germany also adopted XLAT, but it's better that you ask directly your provider for confirmation, even because it's possible that a portion of the network is IPv6 only while a small percentage of users are still stuck to some older Dual Stack etc. Thanks, that's very important and hints to a deeper bug. Thanks for the files too, we should have now all the elements to hunt the bug down in an effective way. If we need something else we will let you know, and anyway we are going to keep you posted. Kind regards
  23. @OpenSourcerer Hello! Thank you again for your ongoing tests. Well no, the IP address you see in the log is never returned by getaddrinfo, getaddrinfo returns structure(s) where the IP address of your network interface assigned by your upstream is included. In general it is / they are not necessarily the IP address(es) which your packets reach the Internet with (in most cases, it/they will be private address(es), of course). We do not rely on getaddrinfo and the issue can't come from it. It's strange that you mention it, so if we miss something please elaborate. Furthermore,: the address returned by ipleak.net (and not by getaddrinfo) is never used by Bluetit for the VPN connection. Note that Bluetit tries to know, via ipleak.net, the country your system is in, which is relevant for the quick connection algorithm, nothing else. The returned IPv6 address we noticed led us to ask you whether you have native IPv4 support or not. We don't understand why that would be relevant. What you say does not imply that you have native IPv4 connectivity. 🤔 You would connect anyway to IPv4 services if your ISP provides you with IPv6 only,. Thanks to any NAT64-like implementation (like T-Mobile in Germany does, you know, with a special implementation of NAT64) voilà, you reach IPv4 services over IPv6, and you don't have native IPv4. 🙃 Maybe the information will give us a clue to understand the issue, because we have no networks built in such a way to perform tests from, so the the fact that the issue can't be reproduced might be explained (or it will not, but it's worth a try). So if you determine that you have or not native IPv4 let us know. Moreover, can you please (when and if you have time, of course), do the following: connect in pure IPv4 not to Kitalpha (as Kitalpha does not support IPv6) with OpenVPN 2.5 connect with Bluetit to Kitalpha through the same profile used by OpenVPN 2.5 in your example and by self connection have Bluetit generate a profile and send it to us (after you have deleted any sensitive data). Test yourself the profile with OpenVPN 2.5 and check what happens with it and Bluetit. We'll do the same and then we can compare both outcomes Thank you in advance. Kind regards
  24. @OpenSourcerer Hello! Bluetit does not try to connect in IPv6, it respects the options that force it to connect in IPv4. However, from ipleak.net you get a reply of an IPv6 address, so it seems that you have IPv6 only. Then the log shows an empty entry, which must be investigated as it is abnormal. Then Bluetit explicitly avoids IPv6, according to your command option "-V off" and your rc file. Some other questions: are you sure that you have IPv4, or might it be that you have only IPv4 over IPv6? In general, without Bluetit, how do you connect to AirVPN in pure IPv4? Kind regards
  25. @pjnsmb Hello! We already asked in the past but we don't see any reply so we ask again: what is your distribution name and version? Kind regards
×
×
  • Create New...