Hummingbird 1.0.2 released

[Staff 9973]

Hello!

We're glad to inform you that Hummingbird 1.0.2 has just been released.

Hummingbird is a free and open source software by AirVPN for:

• Linux x86-64
• Linux ARM 32 (example: Raspbian for Raspberry Pi)
• Linux ARM 64
• macOS (Mojave or higher version required)

based on OpenVPN3-AirVPN 3.6.3 library supporting CHACHA20-POLY1305 cipher on OpenVPN Data Channel and Control Channel. Hummingbird is very fast and has a tiny RAM footprint. AES-CBC and AES-GCM are supported as well.

Version 1.0.2 uses new OpenVPN3-AirVPN 3.6.3 library. Important: if you build Hummingbird please make sure to align to AirVPN library 3.6.3. You can't build Hummigbird 1.0.2 with library versions older than 3.6.3.

Hummingbird is not aimed to Android but you can have CHACHA20-POLY1305 on Android too: please run our software Eddie Android edition, which uses our OpenVPN3-AirVPN library.
 

TCP queue limit

If you connect over TCP, Hummingbird will set by default a minimum TCP outgoing queue size of 512 packets to avoid TCP_OVERFLOW errors. If you need a larger queue in TCP, the following option is now available from command line, in addition to profile directive tcp-queue-limit:
 

--tcp-queue-limit n

where n is the amount of packets. Legal range is 1-65535.

We strongly recommend you to allow at least 512 packets as queue limit (default value). Larger queues are necessary when you connect in TCP and need a lot of open connections with sustained (continuous) but not necessarily high throughput, for example if you run a BitTorrent software. In such cases you can enlarge the queue as much as you need, until you stop getting TCP_OVERFLOW.

It's not uncommon from our community as well as our internal tests to set 4000 packets queue limit to prevent any TCP overflow.

If you connect over UDP, you can ignore all of the above.
 

Network Lock

Network Lock prevents traffic leaks outside the VPN tunnel through firewall rules. Hummingbird 1.0.2 widens --network-lock option arguments. The following arguments are now accepted:
on  | off  | iptables | nftables | pf  (default: on).

If you specify on argument, or you omit --network-lock option, Hummingbird will automatically detect and use the infrastructure available on your system. Hummingbird picks the first available infrastructure between iptables-legacy, iptables, nftables and pf.



Note: command line options, when specified, override profile directives, when options and profile directives have the same purpose.
 

Binaries download pages
Linux: https://airvpn.org/linux/#Hummingbird
macOS: https://airvpn.org/macos/#Hummingbird

Complete instructions
https://airvpn.org/hummingbird/readme/

 

Hummingbird source code

https://gitlab.com/AirVPN/hummingbird

 

OpenVPN3-AirVPN library source code
https://github.com/AirVPN/openvpn3-airvpn

 

Changelog

Changelog 1.0.2 - 4 February 2020

- [ProMIND] Updated to OpenVPN3-AirVPN 3.6.3
- [ProMIND] Added --tcp-queue-limit option
- [ProMIND] --network-lock option now accepts firewall type and forces hummingbird to use a specific firewall infrastructure


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0.1 - 24 January 2020

- [ProMIND] Updated to OpenVPN3-AirVPN 3.6.2


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0 - 27 December 2019

- [ProMIND] Production release


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0 RC2 - 19 December 2019

- [ProMIND] Better management of Linux NetworkManager and systemd-resolved in case they are both running
- [ProMIND] Log a warning in case Linux NetworkManager and/or systemd-resolved are running



*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0 RC1 - 10 December 2019

- [ProMIND] Updated asio dependency


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0 beta 2 - 6 December 2019

- [ProMIND] Updated to OpenVPN 3.6.1 AirVPN
- [ProMIND] macOS now uses OpenVPN's Tunnel Builder
- [ProMIND] Added --ignore-dns-push option for macOS
- [ProMIND] Added --recover-network option for macOS


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0 beta 1 - 28 November 2019

- [ProMIND] Added a better description for ipv6 option in help page
- [ProMIND] --recover-network option now warns the user in case the program has properly exited in its last run
- [ProMIND] NetFilter class is now aware of both iptables and iptables-legacy and gives priority to the latter


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0 alpha 2 - 7 November 2019
 
- [ProMIND] DNS resolver has now a better management of IPv6 domains
- [ProMIND] DNS resolver has now a better management of multi IP domains
- [ProMIND] Minor bug fixes


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Changelog 1.0 alpha 1 - 1 November 2019

- [ProMIND] Initial public release

Kind regards & datalove
AirVPN Staff

[misam 9]

getting again same key error messages

 

ed Feb  5 20:27:12.853 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:27:56.830 2020 ERROR: KEV_NEGOTIATE_ERROR
Wed Feb  5 20:27:56.830 2020 ERROR: HANDSHAKE_TIMEOUT
Wed Feb  5 20:27:57.850 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:27:59.508 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:28:03.602 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:28:11.851 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:28:27.505 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:28:56.830 2020 ERROR: KEV_NEGOTIATE_ERROR
Wed Feb  5 20:28:56.830 2020 ERROR: HANDSHAKE_TIMEOUT
Wed Feb  5 20:29:12.491 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:29:14.564 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:29:18.843 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:29:26.503 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:29:42.864 2020 ERROR: KEY_STATE_ERROR
Wed Feb  5 20:29:56.830 2020 ERROR: KEV_NEGOTIATE_ERROR
Wed Feb  5 20:29:56.830 2020 ERROR: HANDSHAKE_TIMEOUT

[Staff 9973]

@misam

Thank you. We are aware of the problem and we are investigating. It affects OpenVPN 3 main library as well, so we have dragged it into our fork. By searching the web, we have seen that the problem is very sporadic (we are failing to reproduce it, but we are analyzing every aspect anyway) but it has been reported on the main line library since 2014.

The fact that we can't manage to reproduce it makes the whole investigation very hard.

On your side, can you please verify whether you get the issue when you connect to entry-IP address THREE, both in TCP and UDP, and report your findings?

We will inform the community on any news on the issue.

Kind regards
 

[nexsteppe 24]

I'm not the user you asked, but I  see the same problems connecting to entry IP three (tls-crypt) with udp.  I'll try tcp at the next opportunity to see if I can replicate the problem on that side.

[Staff 9973]

Hello!

Quick update: it is not very useful to compare OpenVPN 2 behavior because we have just ascertained that OpenVPN 2 completely lacks any implementation for such an error. Under this aspect, it's a very good thing that OpenVPN 3 is stricter.

Kind regards


 

[NinjaThunderbolt 4]

20 hours ago, Staff said:

@misam

Thank you. We are aware of the problem and we are investigating. It affects OpenVPN 3 main library as well, so we have dragged it into our fork. By searching the web, we have seen that the problem is very sporadic (we are failing to reproduce it, but we are analyzing every aspect anyway) but it has been reported on the main line library since 2014.

First few days using Hummingbird and I have the same problem as well.

Hummingbird also seems to disconnect/reconnect itself a lot more. I have Network Lock disabled because it seems to interfere with my existing iptables/ip6tables setup.

[Staff 9973]

@NinjaThunderbolt

Hello and thank you for your report!

Yes, Network Lock, either on Eddie or Hummingbird, will set its own rules, otherwise it could not guarantee traffic leaks prevention outside the VPN tunnel.

When you write "a lot more" disconnections, is it compared to OpenVPN 2? Can you also post the log showing the disconnections?

Kind regards
 

[NinjaThunderbolt 4]

9 hours ago, Staff said:

When you write "a lot more" disconnections, is it compared to OpenVPN 2? Can you also post the log showing the disconnections?

I don't know how I would log that, but it just seems that way.

[misam 9]

@Staff

I have sent you a full log via support request.

[Staff 9973]

@misam
@hawkflights

We are still struggling to reproduce the issue. We have been testing for dozens of hours with a forced re-keying every 5 minutes, initiated by the client side, and no problems have arisen.

Can you please do the same on your machines, where the problem seems to occur frequently, with the same profile you have been using so far, but with the addition of the following directive:

reneg-sec 300

In this way it's the client that starts the re-keying request (every 300 seconds), so you should see a re-keying every 5 minutes.

You can put the directive anywhere (as a single line, followed by RETURN) within the first block of directives.

We would like to compare whether in your systems the problem occurs with the same frequency (or at all) when it's the client to ask for re-keying.

Thank you in advance.

Kind regards



 

[misam 9]

ok will do and report back. What is the keyring neg default time?

What do you mean for first block of directive?

[Staff 9973]

@misam

Default value is 3600 seconds (1 hour). And actually you can see that you always get the error you mentioned exactly n hours after your initial connection, with n a positive integer, an additional confirmation that the problem specifically occurs just before or during a re-keying.

The first block of directives is placed on the top of the text file. We mean, do not insert the directives somewhere in the middle of certificates, keys or <> blocks.

Kind regards


 

[monstrocity 31]

Several times during the day, I'm seeing the following errors, and the connection needs to reset.  Is there anything I can add to OPVN directives within Eddie?
ERROR: KEEPALIVE_TIMEOUT
Session invalidated: KEEPALIVE_TIMEOUT
Client terminated, restarting in 2000 ms...
ERROR: N_RECONNECT

log.txt

[Chris Wyatt 0]

On 1/30/2020 at 7:26 AM, misam said:

Sometimes I am getting a bunch of KEY_STATE_ERROR messages, however connection is still on.

Same here. I'm using the Europe configuration. I don't think they go away until I restart the connection. Edited ... by Chris Wyatt

[Staff 9973]

@monstrocity

Please upgrade to Hummingbird 1.0.2, use it alone (without Eddie) and check whether the same problems occur.

Also compare with Eddie + OpenVPN 2.4: do you see the same errors or not?

Kind regards
 

[monstrocity 31]

13 hours ago, Staff said:

@monstrocity

Please upgrade to Hummingbird 1.0.2, use it alone (without Eddie) and check whether the same problems occur.

Also compare with Eddie + OpenVPN 2.4: do you see the same errors or not?
 

The errors occurred using Hummingbird 1.0.2 via Eddie 2.18.7 beta.  I have not seen similar errors using Eddie with OpenVPN 2.4.  The errors appear using Hummingbird 1.0.2 by itself 4 hours into the session.

log1.txt

[Staff 9973]

@monstrocity

Thanks. Can you add now reneg-sec 300 directive, run Hummingbird alone, and check whether anything changes? See also:

Kind regards
 

[monstrocity 31]

I tried adding that parameter at the beginning of the session.  This is from the top of the log I previously attached: root@buddha:/home/buddha/Downloads/hummingbird-linux-x86_64-1.0.2# sudo ./hummingbird --tcp-queue-limit 5000 --reneg-sec 300 --persist-tun AirVPN_Japan_TCP-443.ovpn
Hummingbird - AirVPN OpenVPN 3 Client 1.0.2 - 4 February 2020

./hummingbird: unrecognized option '--reneg-sec'

--reneg-sec isn't listed as an option for Hummingbird, and I don't know how else to add it.
 

[Staff 9973]

@monstrocity

Please add it in the first block of directives of the ovpn file "AirVPN_Japan_TCP-443.ovpn"

Open the file with a text editor, add the following line, FOR EXAMPLE just under the line beginning with "remote":

reneg-sec 300 

(press ENTER after it, it must be a stand alone line)

and save the file. Then re-run Hummingbird like you already did, but without the --reneg-sec option. Note whether the re-keying error occurs as usual or not. Thanks in advance!

Kind regards
 

[misam 9]

ok now these instructions are clear 😆

[monstrocity 31]

Well, that was interesting.  I couldn't kill Hummingbird with sudo kill -9 PID of hummingbird or pkill commands.  Even after rebooting, I was getting a message that the Hummingbird connection was still active - it wasn't.  I deleted /etc/airvpn/hummingbird.lock.  When I started Hummingbird again, it wouldn't really connect (just kept spinning) - no tun0 interface.  It was using eno instead and had no connection.  Not sure what I did wrong, but after another reboot I was able to re-establish an internet connection using Eddie.  I'll try hummingbird by itself again tomorrow.  Just to verify my OVPN file reads:
client
dev tun
remote jp.vpn.airdns.org 443
reneg-sec 300
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
route-delay 5
verb 3
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
proto tcp
key-direction 1
Is the reneg-sec 300 correct here?

[Staff 9973]

@monstrocity
 

36 minutes ago, monstrocity said:

Is the reneg-sec 300 correct here?

Yes, correct!

Kind regards
 

[monstrocity 31]

Testing Hummingbird alone and in Eddie with the reneg-sec 300 parameter, I had one instance of ERROR: N_KEV_EXPIRE in 14 hours.  No other errors / disconnects / reconnects noted. 
One question, though, how can I kill Hummingbird stand-alone gracefully and restore my internet connection on Linux Mint 19.3?  My setup has iptables, resolved, and UFW (installed but not active).

[Staff 9973]

@monstrocity

Thank you for your report. Interesting outcome.

To kill Hummingbird gracefully send it a kill signal 15 (SIGTERM):

sudo kill `pidof hummingbird`

If Hummingbird is not detached from a terminal emulator you can also press CTRL-C on that to stop Hummingbird gracefully.

Please see also:
https://airvpn.org/hummingbird/readme/

Kind regards
 

[monstrocity 31]

Thanks. I tried sudo kill 'pidof hummingbird' and sudo pkill hummingbird.  CTRL+C didn't work - I think I did it outside the terminal.  Anyway, I prefer to use Eddie due to needing a higher port most of the time, such as 41185.  OVPN files are restricted to port 443, and I tend to get throttled using it.