Staff

@zurround Hello! If the problem persists, can you please send us the output of the following commands before you run the suite (when everything works) during the connection (while the system is connected successfully to the VPN) after the connection (while the problem is ongoing) cat /etc/resolv.conf resolvectl Open a terminal, and enter the above commands (in each of the above situations), then select and copy everything, finally paste into your message. Kind regards

@Aghinix Thank you! We will send this thread to Eddie developer. Kind regards

@kbps Hello! However, mega.nz operates servers in Luxembourg (at least from what we can see on the web site). We think that New Zealand poses no privacy problems at all. The issue is just finding a suitable datacenter. Kind regards

@OpenSourcerer Oh, OK, so it is impossible to identify someone in practice in the ATM described by @Mad_Max. We had the impression that you wanted to imply otherwise. About masks and other protections which make facial recognition fail, they are mandatory (in many countries in the EU you can be severely fined if you don't wear them outdoors and you don't have a medically motivated exemption, or even criminally prosecuted) or strongly recommended nowadays, so it's not a big deal, even if they were necessary. Kind regards

@Aghinix Hello! Can you tell us whether the AppImage's eddie-tray fails with the identical error, or you get a different one? What is your current Desktop Environment? Apart from the minimization problem, is anything else fine? What is your version of libappindicator? Can you please re-check whether libindicator is available? Kind regards

@OpenSourcerer Hello! It's a good idea. Actually we already have it (it is shown only to special users, we don't know if you can see it) so it would be simple to make it available to anyone. We will consider it seriously. Kind regards

@OpenSourcerer So, how is it possible that the ATMs described by @Mad_Max (which actually exist for sure) can be used in Germany to aggregate ex-post all the anonymous transactions of each person performing them, and provided that this is possible, how is it possible to link that video footage to an identity (for example if the aggregated withdrawals total exceeds some anti-laundering limit by law). This is technically very interesting and raises questions on the fundamental right to privacy. If confirmed, it may be advisable to use ATM with facial masks, glasses and adequate hats, which make facial recognition impossible (currently). Kind regards

Hello! You can add Estonia and update the list: we have a 1 Gbit/s server in Tallinn, Estonia: https://airvpn.org/servers/Alruba/ New Zealand would be great, especially when you consider the infamous and outrageous anti-encryption law which prevents us from operating in Australia: we have been and we are struggling to find the right infrastructure. We'll keep searching. Kind regards

Hello! From a private message from @monstrocity we understand that he/she has not understood what we wrote. If that was the case for other readers, here comes some more explicit clarification. Iskandar load at 86% means that it has still 858 Mbit/s free Okab load at 34% means that it has still 1360 Mbit/s free In general, 100% load means that you have 700 Mbit/s free on Japan servers. Re-read our messages to understand why. Furthermore, the CPU load is not heavy. These servers can achieve 1.7 Gbit/s with just four OpenVPN instances (experimentally confirmed, so it's for sure). The problem might be different: you experience congestion in the weakest hop or interconnection between your ISP and our ISP during specific peak times your ISP network is congested (or traffic shaping is enforced) in the peak times you mentioned our datacenter (*) is congested in the peak times you mentioned a combination of two or all of the above points In the first two cases, we can't do anything. In the third case, we can't do anything on that datacenter (adding servers would be mainly useless, of course) except pushing legally for the bandwidth we must have by contract (8 Gbit/s total, or 4 Gbit/s full duplex, as you prefer). However, since we do not experience the problems you mention, not even from Italy or other dedicated servers, we tend to exclude the third option. Thread will remain locked for 24 hours to avoid looping around the same biased arguments over and over. (*) Our Tokyo servers are in Equinix TY8 dc https://www.equinix.com/locations/asia-colocation/japan-colocation/tokyo-data-centers/ty8/ Kind regards

Hello! We don't understand this last message of yours. We have just shown you with clear data that there is no overload at all. During the peak times you have defined there's plenty of free bandwidth and CPU time. We closely monitor all servers, not only Japan ones, and when necessary we add servers or bandwidth. Kind regards

Hi, since when in Germany ATMs perform identification via facial recognition without informing the citizen? What facial database are they authorized to access to have a match? Kind regards

@monstrocity Thank you! Round trip time shown by Eddie is very unreliable and must not be taken as an absolute value, but has its usefulness as a relative value. We will keep an eye on Japan. Currently there's still a lot of free bandwidth 24/7 as you may easily verify (check the average bandwidth over a day, a week, a month etc. on each Japan server from https://airvpn.org/status ), On average, Japan servers are still busy only 50% during a weekend. Let's see the next ones. However, we must keep into account CPU load, because those servers are not able to use full 2 Gbit/s (that's why we report, for maximum transparency, only 1 Gbit/s). Iskandar - Picture shows that Iskandar bandwidth is on a weekly average 58% free on a 500 Mbit/s full duplex basis and that on peak times it reached 1.6 Gbit/s (out of 1 Gbit/s full duplex), which is not yet 100% CPU (these servers' hardware can reach a maximum of 1.7 Gbit/s) Kind regards

@Agrock Hello! We can see two possible explanations, which need a verification. 1) It could be some form of traffic shaping enforced by your ISP (or your router, but it would be so refined that we doubt that your router enforces it without your knowledge). It can't be against UDP tout court, because Wireguard works in UDP. It might be a fuzzy logic based shaping against BitTorrent: when it detects a specific pattern in UDP to specific ports, for example 443 Even if you use a VPN, torrent traffic pattern may be recognized, although with a low degree of reliability. Traffic shaping based on encrypted traffic patterns was widespread about 15-18 years ago, then it was dropped because it was unreliable and caused a plethora of negative side effects unexpected by the ISPs themselves. Traffic shaping is not triggered: when you use Wireguard in UDP, maybe because you connect Wireguard to some other port (which one?) when you use OpenVPN in TCP + tls-crypt, maybe because traffic shaping is not triggered anyway when UDP does not enter into play Counter-check to validate or falsify the assumptions may be based on using Wireguard in UDP to port 443, or connecting OpenVPN in UDP + tls-crypt to the same port Wireguard connects to (if possible) and then running torrent software. 2) Another potential explanation is that you have Windows, and you use the TAP driver with OpenVPN. Windows OpenVPN TAP driver is infamous to cause various bandwidth bottleneck problems in Windows, even (but not limited to) with torrents and/or UDP. If that was the case, you can now use wintun even with OpenVPN (2.5 or higher version required). Kind regards

@busybee911 Hello! After you have stopped and disabled systemd-resolved you should generate your own resolv.conf file before running Eddie, or restart networking and let network-manager do that (via DHCP etc.) if you wish to query the router. The new resolv.conf file will then be the file that Eddie will restore when its job is finished. Kind regards

@triggerdingus Hello! Can you confirm that you run some Linux distribution? If so, developer managed to reproduce the crash, so the matter is under investigation. Kind regards