Jump to content
Not connected, Your IP: 3.227.239.160
Staff

Hummingbird 1.0: AirVPN client based on OpenVPN 3 AirVPN

Recommended Posts

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.

Share this post


Link to post
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
 

Share this post


Link to post
@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).

Share this post


Link to post
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!

Share this post


Link to post
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.
 

Share this post


Link to post

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)

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
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
 

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
@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
 

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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?
 

Share this post


Link to post
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

 

Share this post


Link to post
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. 😇

Share this post


Link to post
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

Share this post


Link to post
@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
 

Share this post


Link to post
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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...