Leaderboard

Hello! It's a packet ID error: a packet failed authentication. Only one packet error every minute is irrelevant for practical purposes, it means that only one packet per minute needs to be re-transmitted. Bad packet IDs suggest: - replay attacks (OpenVPN is very strong against replay attacks, impossible to inject forged packets) - bad line - MTU size (of your network interface) that can't fit TCP packets inside the UDP stream. "mssfix" is supported (*) (*) "mssfix n", where n is in bytes, is a directive which tells OpenVPN to split (in the UDP flow) TCP packets larger than n bytes. You can try for example "mssfix 1400" and check whether packet errors disappear or become less frequent, then go down at little steps if necessary. Anyway if you get only one error per minute maybe you don't need it. The lower the mssfix value, the more you can harm performance, as you enforce packet splitting of smaller and smaller packets. Kind regards

Hello! Thanks for the link. Nice that they talk about it, while it's sad to see that some people "suspect" about something weird when the code is open and a simple diff will tell you everything, even in relation to the bug fixes and new features. If you read our forum you already know why the major changes and critical bug fixes are not in the main branch: AirVPN commits have been refused with pathetic motivations which have NEVER been technical reasons. Arne Schwabe even talked about coding standards when the code he (or OpenVPN 3 maintainers) approved previously is infested by "goto" (!!!), "break", wrong indentations and totally crazy stuff, while AirVPN code is very elegant even according to the Art of Computer Programming books. Therefore, now OpenVPN 3 library is bugged, obsolete, without CHACHA20 support and unusable in Linux (just verify the critical bug in re-connections inside a session, which has been patched by us), while OpenVPN 3 AirVPN fork has CHACHA20 support (in Data Channel too), ncp-disable, a new class to handle AEAD ciphers, and works nicely in Android, Linux x86-64 - ARM 32 - ARM 64 and macOS. Kind regards

@inc @hawkflights Hello! The remote, destination server connection is always logged. Of course it may report exclusively an IP address and not an FQDN with its resolution: that depends on the profile. In case of Air VPN servers, the CN can be either the server name or a generic "server" string (we need to make that consistent, yes). A full integration with the AirVPN "bootstrap" servers will come with the future frontend(s) directing the daemon we mentioned in our previous message (you may have a sort of idea by looking at Eddie Android edition source code). We will disclose an estimated release date of the Hummingbird daemon beta version soon. Your request has been well understood: in Linux several community members asked us to drop Mono and required software "10x" faster than Eddie, and we think that we have made some important steps in the right direction, according to the general feedback (thanks!). Remember, furthermore, that even Eddie 2.18.5 piece running as root is completely written in C++ and does not require Mono (Eddie GUI does). Please keep reporting the problem (we still think it has to do with the re-keying), and also a comparison with OpenVPN 2 from the very same system of yours, if you can and if possible. Kind regards

Hello! Currently you need to build Hummingbird directly on your system. Please follow the instructions in GitLab: https://gitlab.com/AirVPN/hummingbird#building-hummingbird-from-sources Kind regards

Seem to be getting these error messages, still connected though. Fri Jan 3 16:24:24.240 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:24:40.294 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:24:42.345 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:24:46.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:24:54.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:25:10.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:25:24.239 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:25:24.239 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:25:55.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:25:57.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:26:01.296 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:26:09.292 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:26:24.240 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:26:24.240 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:26:25.282 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:27:10.028 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:27:12.028 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:27:16.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:27:24.240 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:27:24.240 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:27:24.284 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:27:40.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:28:24.240 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:28:24.240 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:28:25.283 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:28:27.283 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:28:31.278 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:28:39.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:28:55.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:29:24.241 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:29:24.241 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:29:40.304 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:29:42.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:29:46.042 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:29:54.034 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:30:10.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:30:24.241 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:30:24.241 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:30:55.292 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:30:57.323 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:31:01.292 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:31:09.303 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:31:24.240 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:31:24.240 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:31:25.283 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:32:10.292 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:32:12.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:32:16.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:32:24.241 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:32:24.241 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:32:24.283 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:32:40.293 2020 ERROR: KEY_STATE_ERROR Fri Jan 3 16:33:24.240 2020 ERROR: KEV_NEGOTIATE_ERROR Fri Jan 3 16:33:24.240 2020 ERROR: HANDSHAKE_TIMEOUT Fri Jan 3 16:33:25.284 2020 ERROR: KEY_STATE_ERROR

This is very exciting to me. I've been trying to find a good openvpn cli for Docker (with network lock, reconnects, etc), and upon initial testing I think this might be it. The Eddie cli has always been painful and unreliable in Docker. This doesn't appear to be a great desktop solution, though I did set it up to run in a tmux session at boot. It's nice to have a status icon either via Eddie or Gnome's vpn interface. That said, this is a great addition to my VPN client arsenal.

@AirVPNconsumer @containermalt Hello! Please test Hummingbird binary now available on GitLab, it has been rebuilt in a different environment and now it requires older libraries. Please keep us informed. EDIT: the binary is now available in our repository too and replaces the previous build. https://gitlab.com/AirVPN/hummingbird/tree/master/binary Kind regards P.S. Radical solution is simply building Hummingbird directly in your system (detailed instructions on GitLab).

same problem on openSUSE 15.1 ldd hummingbird ./hummingbird: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./hummingbird) linux-vdso.so.1 (0x00007fffd21f7000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007ff4a24d8000) libm.so.6 => /lib64/libm.so.6 (0x00007ff4a21a0000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff4a1f88000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff4a1d6a000) libc.so.6 => /lib64/libc.so.6 (0x00007ff4a19b0000) /lib64/ld-linux-x86-64.so.2 (0x00007ff4a2862000) * tested on openSUSE Tumbleweed (virtualbox), no problems there! * After update to gcc9 (9.2.1+r279103 ) it works! That is the version on Tumbleweed.

I've the same output trying to run the precompiled 'hummingbird' binary on Slackware Linux 14.2 stable (x86-64) — my version of libstdc++ was fine for RC2 but unexpectedly this 1.0 Stable binary requires a newer version than I've installed. Figuring I could just build a binary I could run on my system from source, I cloned AirVPN's repo of OpenVPN3 and installed some missing dependencies (asio 1.14.1, mbedtls 2.16.2, liblz4 1.9.2) to attempt a "dynamic" build of the hummingbird binary; alas, it seems I'm still missing something. I've attached the redirected compiler warning/error output. building-hummingbird_20191228.txt Any thoughts on how I can get this to build on my system would be appreciated. N.B. I appreciate the option to build against openssl (-DUSE_OPENSSL -lssl) instead of mbedtls (-DUSE_MBEDTLS -lmbedtls -lmbedx509 -lmbedcrypto) should I want to, and hope this feature is retained in future versions of OpenVPN3 (and hummingbird).

Hello! NEWS We have a name for the software! Stable version of Hummingbird has just been released! Please check the first post in this thread for updated links, instructions and changelog. Kind regards

I have just downloaded and successfully tested the RC2 on a PureOS 10 (debian 10 testing derivative) system. Works wonderfully and super fast on server Chamaeleon (US) with a cha-cha-20 cipher. Thank you very much for the hard work you put into this.

Hello! OpenVPN AirVPN 1.0 Release Candidate 2 has just been released! A new version for Linux ARM 64 bit is now available, tested successfully in Ubuntu 19.10 running in a Raspberry Pi 4 with 4 GB RAM. Please check the first post in this thread for updated links, instructions and changelog. Kind regards

Hello! OpenVPN AirVPN 1.0 Release Candidate 1 has just been released! Please check the first post in this thread for updated links, instructions and changelog. Kind regards 

Hello! OpenVPN AirVPN 1.0 beta 2 has just been released! Please check the first post in this thread for updated links, instructions and changelog. Kind regards

@giganerd Thank you! We will have to dig deeply. Who knows, it might be one of those bugs that stayed there for years in the main branch, we have already hunted down and fixed many of them. Step by step we are determined to resolve everything. In the Android app, in "Settings", you have the option "Use IPv6 over IPv4". When it's on, it enforces "yes" to the same class member in the Android OpenVPN 3 AirVPN library. If you enable "Use IPv6 over IPv4", do you see the same error? We will get informed about Mono debugging tools. Just to avoid any confusion to the readers we remind that OpenVPN 3 AirVPN client and library have nothing to do with Mono, they are entirely written in C++ Kind regards