Leaderboard

@eburom Thank you very much! The problem you found and kindly reported has been fixed and you'll see the fix in the next, imminent version. From the developer: you can't build the Suite now because OpenVPN3 has recently changed ClientAPI::Config definition. They replaced member ipv6 with allowUnusedAddrFamilies which is basically used for the very same purpose. The change has been already imported into OpenVPN3-AirVPN 3.7.1 fork and Bluetit/Hummingbird code has been updated accordingly in the development branch which is to be released very soon, along with some other minor fixes and changes [including the aforementioned one}. Kind regards

Hello @Staff , I tried running this command in Monterey 12.1 and I got sysctl: unknown oid 'kern.ipc.maxsockbuf' and I tried this command Also : sudo sysctl -w kern.ipc.maxsockbuf=33554432 and I got this : sysctl: kern.ipc.maxsockbuf=33554432: Result too large any ideas ? maybe try smaller buffer ? Edit : I tried sudo sysctl -w kern.ipc.maxsockbuf=16554432 and I got : kern.ipc.maxsockbuf: 8388608 -> 16554432 it's seems that 16mb was accepted unlike the 32 I'll test and report back.

Not entirely sure it's possible. This one is Alya. Its primary TLS-Auth IP is .170 and comes up if you query ca.all.vpn.airdns.org. Well, it's not forbidden to run exit nodes behind AirVPN servers, only recommended against to avoid exactly these kinds of incidents. But egoists gotta be egoists. I can neither confirm nor deny it, but it's a strong indication that it is triggering it. Also, please don't try to use VPNs at your workplace if they are expressly forbidden or you can otherwise be held accountable for using one.

Hello everybody, can you please re-perform all of your tests and report back? We have found a bug which potentially might have caused the reported names resolution failures under rare circumstances on a few servers. We have fixed the code. Please let us know whether the problems keeps occurring or not, as our automated DNS testing sentinels deployed on the reported flag servers have stopped reporting resolution failures since when the fix was deployed. A couple of hours ago the fix has been deployed. Kind regards

Hello! We confirm that it's not possible for Eddie to start during the bootstrap of any un-rooted device running Android TV 10, 11 and 12, and this is not an Eddie-specific limitation, simply because "Always on VPN" has become mandatory for the purpose, but at the same time Android TV has always had this feature removed. Should we find a solution to circumvent this deliberate limitation on un-rooted devices, we will be willing to implement it, but at the moment we are not aware of any solution. OpenVPN connect, OpenVPN for Android and other apps undergo the very same limitation. Kind regards