Leaderboard

Hello! First of all, thank you for writing free and open source software dedicated to AirVPN. We had a quick look at both repositories. The code is careful and we did not find any telemetry and/or third-party endpoints. The client identifies itself honestly and the documentation describes our protocol accurately. We appreciate it. There are three points that affect our infrastructure, which you might like to take into account for the next releases. References are to wave-vpn-desktop at commit ce9a15fd and wave-vpn-mobile at commit 64a2be1b. 1. Periodic tunnel verification (desktop) verify_tunnel() in src/platform/linux.rs runs every 60 seconds for the whole session: the tun check for each IP family and the dns check on https://<server>_exit.airservers.org:89/check/, plus a checkdns.airvpn.org query. Any failure tears the tunnel down. Eddie runs these checks only once, right after connecting. With a 60 second loop, a short outage of the check service would disconnect every Wave VPN user at the same time, and they would all reconnect together. You might like to consider running the checks only at connection time, or much less often with some random jitter, and not disconnecting on a single failed check. 2. Latency measurement (desktop and Android) The "ping" is a TCP connection to port 443 on the first entry IPv4 of every server (src/gui.rs on desktop, vpn/Connection.kt on Android), so about 250 connections are opened and closed at every login, launch and refresh. The desktop refresh can go down to 15 seconds from the command line, and the Android manual refresh has no rate limit. A lighter probe such as ICMP echo, fewer probes in parallel, cached results with a minimum interval between refreshes, and no probes while connected (they go through the tunnel and skew the ranking anyway) would help a lot. Also, on desktop an unreachable server currently counts as 0 ms (src/documents.rs), so "Best server" ends up preferring servers that do not answer. 3. Bootstrap servers (desktop and Android) The desktop client always uses the bootstrap URLs and the RSA key from the AirVPN.json compiled into the binary and ignores the ones in the manifest (src/lib.rs, src/documents.rs). If we change bootstrap addresses or rotate the key, older builds would stop working. It might be worth storing and using the bootstrap URLs and key from the latest manifest, and keeping the embedded ones only as a first-run fallback. On Android, Protocol.kt and Session.kt send user and manifest at every refresh, always to the first URL, with no backoff while the bootstrap servers are unreachable. Trying the other URLs when one fails, with an increasing delay between retries, would make the client more robust and lighter on our side. Thank you again for your work. Feel free to ask here if anything about the protocol is unclear. Kind regards