Hummingbird 1.0: AirVPN client based on OpenVPN 3 AirVPN

[colorman 26]

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.

[Staff 9972]

8 hours ago, hawkflights said:

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!

You are using an obsolete OpenVPN 3 AirVPN, when "ncp-disable" and "cipher" were not implemented. By aligning to latest OpenVPN AirVPN 3.6.1 you should resolve the issue.

Options to link against OpenSSL or mbedTLS will be kept.

Thank you for the feedback.

Kind regards
 

[Staff 9972]

@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).

[colorman 26]

34 minutes ago, Staff said:

@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.

 

looks fine now on openSUSE 15.1
llibstdc back to original version.

Thanks!

[nexsteppe 24]

2 hours ago, Staff said:

You are using an obsolete OpenVPN 3 AirVPN, when "ncp-disable" and "cipher" were not implemented. By aligning to latest OpenVPN AirVPN 3.6.1 you should resolve the issue.

Pulling the master branch properly this time, I am now able to build successfully with mbedTLS and produce a working "dynamic" binary.  Thank you!!
 

2 hours ago, Staff said:

Options to link against OpenSSL or mbedTLS will be kept.

Turns out the version of OpenSSL I have installed is too old and doesn't include ChaCha20 (among other things).  I will report back about building hummingbird with OpenSSL once I've updated it to 1.1.1d.
 

[farquaad 14]

Works great on my Mac.
Thank you!

[333_half_evil 6]

.

[frk1337 3]

Release to AUR planned?

[farquaad 14]

Almost a cosmetic rather than a bug but if hummingbird is running, I am unable to run a second command to get help.
 

$ sudo hummingbird --help
Enter PIN for 'Certificate For PIV Authentication (Yubico PIV Authentication)':
Hummingbird - AirVPN OpenVPN 3 Client 1.0 - 27 December 2019

This program is already running (PID 14469)

[inc 3]

Been running Hummingbird for a few days on Debian Sid (Siduction) Working fine atm  fast and no bloat. ,I will give it a few more days and then purge Eddie and it's dependency on mono. Initially I was wondering why no IPV6 but have since  discovered   the advanced settings for configuring the OVPN profile. Would be nice to have some sort of system tray notification for connected but not necessary

[ezd 2]

It works well on OS X and Arch. What doesn't work is recovering the client from sllep mode. This works neither on Linux nor on OS X.

[Staff 9972]

14 hours ago, ezd said:

It works well on OS X and Arch. What doesn't work is recovering the client from sllep mode. This works neither on Linux nor on OS X.

Hello!

What are the features of the sleep mode? Specifically, is the network card turned off, applications frozen and/or the whole system hibernated?

Kind regards
 

[bm9vbmUK 7]

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.

[inc 3]

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

[Staff 9972]

@inc

Hello!

It looks like the client fails to negotiate the new Data Channel key after the old one has expired (in our service PFS is implemented and DHE occurs every 60 minutes by default). Since the old key is kept in use until the re-negotiation is not finished, the connection is not broken, but the Data Channel uses always the same encryption key. How frequently do you get those errors? Did anybody else notice them?

Kind regards
 

[inc 3]

34 minutes ago, Staff said:

@inc

Hello!

It looks like the client fails to negotiate the new Data Channel key after the old one has expired (in our service PFS is implemented and DHE occurs every 60 minutes by default). Since the old key is kept in use until the re-negotiation is not finished, the connection is not broken, but the Data Channel uses always the same encryption key. How frequently do you get those errors? Did anybody else notice them?

Kind regards
 

At least three times in last two days on different servers. Maybe more often I have no way  of knowing unless I specifically check. Also if it reconnects it scrolls  up out of the terminal window so unless I look for a change of server or scroll back down I don't see an error so it may have been more often. Now I am aware I  check quite often.

[inc 3]

Just happened again
 

ri Jan  3 17:54:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:54:56.098 2020 ERROR: CC_ERROR
Fri Jan  3 17:54:58.059 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:02.241 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:10.388 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:26.040 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:26.336 2020 ERROR: KEV_NEGOTIATE_ERROR
Fri Jan  3 17:55:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:56:11.046 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:13.064 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:17.083 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:25.388 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:26.336 2020 ERROR: KEV_NEGOTIATE_ERROR
Fri Jan  3 17:56:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:56:41.388 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:26.070 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:26.336 2020 ERROR: KEV_NEGOTIATE_ERROR
Fri Jan  3 17:57:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:57:28.076 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:32.129 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:40.378 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:56.049 2020 ERROR: CC_ERROR

[encrypted 13]

Quote

ldd hummingbird
./hummingbird: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./hummingbird)

Ubuntu 18.04 LTS and its various siblings including the Mint-flavoured ones are still very widely used. Are there plans for a compatible Hummingbird release or possible workarounds?
 

[Staff 9972]

43 minutes ago, encrypted said:

Ubuntu 18.04 LTS and its various siblings including the Mint-flavoured ones are still very widely used. Are there plans for a compatible Hummingbird release or possible workarounds?
 

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

 

[frk1337 3]

On 1/2/2020 at 12:32 PM, Staff said:

Hello!

What are the features of the sleep mode? Specifically, is the network card turned off, applications frozen and/or the whole system hibernated?

Kind regards

Eddie fails to reconnect properly after MacOS sleep too. The only client I found that handels everything correclty is Viscosity.

I think MacOS disables WiFi when going to sleep.

Hummingbird works perfectly on my ARCH PC. Already uninstalled mono and everything attached to it. 😇

[colorman 26]

15 hours ago, inc said:

Just happened again
 

ri Jan  3 17:54:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:54:56.098 2020 ERROR: CC_ERROR
Fri Jan  3 17:54:58.059 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:02.241 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:10.388 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:26.040 2020 ERROR: CC_ERROR
Fri Jan  3 17:55:26.336 2020 ERROR: KEV_NEGOTIATE_ERROR
Fri Jan  3 17:55:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:56:11.046 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:13.064 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:17.083 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:25.388 2020 ERROR: CC_ERROR
Fri Jan  3 17:56:26.336 2020 ERROR: KEV_NEGOTIATE_ERROR
Fri Jan  3 17:56:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:56:41.388 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:26.070 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:26.336 2020 ERROR: KEV_NEGOTIATE_ERROR
Fri Jan  3 17:57:26.336 2020 ERROR: HANDSHAKE_TIMEOUT
Fri Jan  3 17:57:28.076 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:32.129 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:40.378 2020 ERROR: CC_ERROR
Fri Jan  3 17:57:56.049 2020 ERROR: CC_ERROR

Sat Jan  4 10:12:20.142 2020 ERROR: KEY_STATE_ERROR
Sat Jan  4 10:12:35.128 2020 ERROR: KEV_NEGOTIATE_ERROR
Sat Jan  4 10:12:35.128 2020 ERROR: HANDSHAKE_TIMEOUT
Sat Jan  4 10:13:05.014 2020 ERROR: KEY_STATE_ERROR
Sat Jan  4 10:13:07.060 2020 ERROR: KEY_STATE_ERROR
Sat Jan  4 10:13:11.015 2020 ERROR: KEY_STATE_ERROR
Sat Jan  4 10:13:19.013 2020 ERROR: KEY_STATE_ERROR


same here today

[Staff 9972]

@inc
@colorman

Hello!

Do you both confirm that the tunnel remains active, data flow continues regularly and connection is not lost? Can you also please confirm that your system time is correct, with a maximum discrepancy of just a couple of seconds?

Kind regards
 

[colorman 26]

1 hour ago, Staff said:

@inc
@colorman

Hello!

Do you both and connection is not lost? Can you also please confirm that your system time is correct, with a maximum discrepancy of just a couple of seconds?

Kind regards
 

I confirm that the tunnel remains active, data flow continues regularly, but whether the connection has been interrupted I do not know, that depends on my provider.
I am running a NTP-server true Yast, have now changed to a local server.
Incidentally, just the same message again

GJ

[inc 3]

I can also confirm tunnel remains active well at least for an hour. I first connected at 08.31.52 the first error message was at 10.31.52 and ran for exactly an hour until the message below

Sat Jan  4 11:31:52.246 2020 ERROR: N_KEV_EXPIRE
Sat Jan  4 11:31:52.249 2020 ERROR: KEV_NEGOTIATE_ERROR
Sat Jan  4 11:31:52.249 2020 ERROR: HANDSHAKE_TIMEOUT
Sat Jan  4 11:31:52.249 2020 Session invalidated: KEV_NEGOTIATE_ERROR
Sat Jan  4 11:31:52.249 2020 Client terminated, restarting in 2000 ms...

If you say it renegotiates every hour the one at 09.31.52  and 12.31.52  have been OK. system time is set by NPT

[inc 3]

Yesterday no errors all day, today back to errors It would be good to know what the problem is. Also I can't see from Hummingbird what server I am connected to, sometimes the cert shows the server name and other time no name shown just  "O=airvpn.org, CN=server" I can check with IP/DNS but not Hummingbird. I could also see server with Eddie.