Hummingbird 1.0.1 released

[Staff 9972]

Hello!

We're glad to inform you that Hummingbird 1.0.1 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 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.1 uses new OpenVPN3-AirVPN 3.6.2 library which features various improving minor changes and fixes an annoying bug which caused "ncp-disable" directive to be ignored in profiles.

Note: command line options --ncp-disable and --cipher, when specified, override profile directives.

Please consult the following page for details, changelog, instructions and download links.
https://airvpn.org/hummingbird/readme/

Hummingbird source code is available here:
https://gitlab.com/AirVPN/hummingbird

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

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

Kind regards

[OpenSourcerer 1435]

Brand new development of the IPv6 problem. I have probably identified the bug. But here goes the story first.

---

$ sudo ./hummingbird -N off -i tls-crypt.ovpn
Hummingbird - AirVPN OpenVPN 3 Client 1.0.1 - 24 January 2020

Fri Jan 24 19:10:21.913 2020 Starting thread
Fri Jan 24 19:10:21.913 2020 OpenVPN core 3.6.2 AirVPN linux x86_64 64-bit
Fri Jan 24 19:10:21.925 2020 Frame=512/2048/512 mssfix-ctrl=1250
Fri Jan 24 19:10:21.931 2020 UNUSED OPTIONS
2 [resolv-retry] [infinite]
3 [nobind]
4 [persist-key]
5 [persist-tun]
6 [auth-nocache]
7 [route-delay] [5]
8 [verb] [3]
9 [explicit-exit-notify] [5]
17 [pull-filter] [ignore] [dhcp-option DNS]
Fri Jan 24 19:10:21.931 2020 EVENT: RESOLVE
Fri Jan 24 19:10:21.931 2020 WARNING: Network filter and lock is disabled
Fri Jan 24 19:10:21.931 2020 Contacting [2a00:c98:2050:a007:ba5e:c9f1:828f:291c]:443 via UDP
Fri Jan 24 19:10:21.931 2020 EVENT: WAIT
Fri Jan 24 19:10:21.932 2020 net_route_best_gw query IPv6: 2a00:c98:2050:a007:ba5e:c9f1:828f:291c/128
Fri Jan 24 19:10:21.932 2020 sitnl_route_best_gw result: via UNSPEC dev
Fri Jan 24 19:10:21.932 2020 Fri Jan 24 19:10:21.932 2020 Connecting to [2a00:c98:2050:a007:ba5e:c9f1:828f:291c]:443 (2a00:c98:2050:a007:ba5e:c9f1:828f:291c) via UDPv6
Fri Jan 24 19:10:21.956 2020 EVENT: CONNECTING
Fri Jan 24 19:10:21.956 2020 Tunnel Options:V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client
Fri Jan 24 19:10:21.956 2020 Peer Info:
IV_VER=3.6.2 AirVPN
IV_PLAT=linux
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
UV_IPV6=yes
IV_GUI_VER=Hummingbird - AirVPN OpenVPN 3 Client 1.0.1
IV_SSL=mbed TLS 2.16.3

Fri Jan 24 19:10:22.014 2020 VERIFY OK : depth=1
cert. version     : 3
serial number     : 8C:D8:43:EF:E4:5F:20:03
issuer name       : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
subject name      : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
issued  on        : 2014-04-11 10:15:45
expires on        : 2024-04-08 10:15:45
signed using      : RSA with SHA1
RSA key size      : 4096 bits
basic constraints : CA=true

Fri Jan 24 19:10:22.014 2020 VERIFY OK : depth=0
cert. version     : 3
serial number     : 4F
issuer name       : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
subject name      : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Serpens, emailAddress=info@airvpn.org
issued  on        : 2016-12-02 16:51:13
expires on        : 2026-11-30 16:51:13
signed using      : RSA with SHA-512
RSA key size      : 4096 bits
basic constraints : CA=false
cert. type        : SSL Server
key usage         : Digital Signature, Key Encipherment
ext key usage     : TLS Web Server Authentication

Fri Jan 24 19:10:22.306 2020 SSL Handshake: TLSv1.2/TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
Fri Jan 24 19:10:22.307 2020 Session is ACTIVE
Fri Jan 24 19:10:22.307 2020 EVENT: GET_CONFIG
Fri Jan 24 19:10:22.307 2020 Sending PUSH_REQUEST to server...
Fri Jan 24 19:10:22.633 2020 OPTIONS:
0 [route] [192.168.0.0] [255.255.0.0] [net_gateway]
1 [comp-lzo] [no]
2 [redirect-gateway] [ipv6] [def1] [bypass-dhcp]
3 [dhcp-option] [DNS] [10.11.250.1]
4 [dhcp-option] [DNS6] [fde6:7a:7d20:7fa::1]
5 [tun-ipv6]
6 [route-gateway] [10.11.250.1]
7 [topology] [subnet]
8 [ping] [10]
9 [ping-restart] [60]
10 [ifconfig-ipv6] [fde6:7a:7d20:7fa::1083/64] [fde6:7a:7d20:7fa::1]
11 [ifconfig] [10.11.250.133] [255.255.255.0]
12 [peer-id] [4]
13 [cipher] [AES-256-GCM]

Fri Jan 24 19:10:22.633 2020 PROTOCOL OPTIONS:
  cipher: AES-256-GCM
  digest: NONE
  ncp enabled: yes
  compress: LZO_STUB
  peer ID: 4
Fri Jan 24 19:10:22.633 2020 EVENT: ASSIGN_IP
Fri Jan 24 19:10:22.633 2020 exception parsing IPv4 route: [route] [192.168.0.0] [255.255.0.0] [net_gateway]  : tun_prop_route_error: tun_builder_exclude_route failed
Fri Jan 24 19:10:22.633 2020 Pushed DNS Server IPv4 10.11.250.1 ignored
Fri Jan 24 19:10:22.633 2020 Pushed DNS Server IPv6 fde6:7a:7d20:7fa::1 ignored
Fri Jan 24 19:10:22.633 2020 net_iface_mtu_set: mtu 1500 for tun1
Fri Jan 24 19:10:22.633 2020 net_iface_up: set tun1 up
Fri Jan 24 19:10:22.633 2020 net_addr_add: 10.11.250.133/24 brd 10.11.250.255 dev tun1
Fri Jan 24 19:10:22.633 2020 net_addr_add: fde6:7a:7d20:7fa::1083/64 dev tun1
Fri Jan 24 19:10:22.633 2020 net_route_add: 0.0.0.0/1 via 10.11.250.1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:22.634 2020 net_route_add: 128.0.0.0/1 via 10.11.250.1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:22.634 2020 net_route_add: ::/1 via fde6:7a:7d20:7fa::1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:22.634 2020 net_route_add: 8000::/1 via fde6:7a:7d20:7fa::1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:22.634 2020 Connected via tun
Fri Jan 24 19:10:22.634 2020 LZO-ASYM init swap=0 asym=1
Fri Jan 24 19:10:22.634 2020 Comp-stub init swap=0
Fri Jan 24 19:10:22.634 2020 EVENT: CONNECTED [2a00:c98:2050:a007:ba5e:c9f1:828f:291c]:443 (2a00:c98:2050:a007:ba5e:c9f1:828f:291c) via /UDPv6 on tun/10.11.250.133/fde6:7a:7d20:7fa::1083 gw=[10.11.250.1/fde6:7a:7d20:7fa::1]
^Creceived stop signal 2
Fri Jan 24 19:10:30.042 2020 net_route_del: 8000::/1 via fde6:7a:7d20:7fa::1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:30.042 2020 net_route_del: ::/1 via fde6:7a:7d20:7fa::1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:30.042 2020 net_route_del: 128.0.0.0/1 via 10.11.250.1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:30.042 2020 net_route_del: 0.0.0.0/1 via 10.11.250.1 dev tun1 table 0 metric 0
Fri Jan 24 19:10:30.042 2020 net_addr_del: fde6:7a:7d20:7fa::1083/64 dev tun1
Fri Jan 24 19:10:30.042 2020 net_addr_del: 10.11.250.133/24 dev tun1
Fri Jan 24 19:10:30.042 2020 net_iface_mtu_set: mtu 1500 for tun1
Fri Jan 24 19:10:30.042 2020 net_iface_up: set tun1 down
Fri Jan 24 19:10:30.043 2020 Fri Jan 24 19:10:30.074 2020 EVENT: DISCONNECTED
Fri Jan 24 19:10:30.074 2020 Thread finished
STATS:
  BYTES_IN : 5510
  BYTES_OUT : 1070916
  PACKETS_IN : 15
  PACKETS_OUT : 1416
  TUN_BYTES_IN : 1031504
  TUN_BYTES_OUT : 548
  TUN_PACKETS_IN : 1403
  TUN_PACKETS_OUT : 3

First I was a bit euphoric. Then I noticed it used tun1. I forgot I'm already connected via OpenVPN:

Fri Jan 24 19:10:21.932 2020 sitnl_route_best_gw result: via UNSPEC dev
[…]
Fri Jan 24 19:10:22.633 2020 net_iface_up: set tun1 up

When I disconnected with OpenVPN and tried to connect the same bug appeared to happen:

$ sudo ./hummingbird -N off -i tls-crypt.ovpn
Hummingbird - AirVPN OpenVPN 3 Client 1.0.1 - 24 January 2020

Fri Jan 24 19:11:33.274 2020 Starting thread
Fri Jan 24 19:11:33.275 2020 OpenVPN core 3.6.2 AirVPN linux x86_64 64-bit
Fri Jan 24 19:11:33.287 2020 Frame=512/2048/512 mssfix-ctrl=1250
Fri Jan 24 19:11:33.292 2020 UNUSED OPTIONS
2 [resolv-retry] [infinite]
3 [nobind]
4 [persist-key]
5 [persist-tun]
6 [auth-nocache]
7 [route-delay] [5]
8 [verb] [3]
9 [explicit-exit-notify] [5]
17 [pull-filter] [ignore] [dhcp-option DNS]
Fri Jan 24 19:11:33.292 2020 EVENT: RESOLVE
Fri Jan 24 19:11:33.292 2020 WARNING: Network filter and lock is disabled
Fri Jan 24 19:11:33.293 2020 Contacting [2001:ac8:20:99:fbf6:b62a:86df:b560]:443 via UDP
Fri Jan 24 19:11:33.293 2020 EVENT: WAIT
Fri Jan 24 19:11:33.293 2020 net_route_best_gw query IPv6: 2001:ac8:20:99:fbf6:b62a:86df:b560/128
Fri Jan 24 19:11:33.293 2020 sitnl_route_best_gw result: via fe80::9a9b:cbff:fe6d:a378 dev enp35s0
Fri Jan 24 19:11:33.293 2020 Fri Jan 24 19:11:33.293 2020 EVENT: DISCONNECTED
Fri Jan 24 19:11:33.293 2020 OpenVPN3 CONNECT ERROR: ipv4_exception: error parsing IPv4 address '2001:ac8:20:99:fbf6:b62a:86df:b560' : Invalid argument
Fri Jan 24 19:11:33.293 2020 Thread finished
STATS:

 

And now the funny part: I reconnected to reproduce the thing, hummingbird used a different server it seems and:

$ sudo ./hummingbird -N off -i tls-crypt.ovpn
[sudo] Passwort für gigan3rd:
Hummingbird - AirVPN OpenVPN 3 Client 1.0.1 - 24 January 2020

Fri Jan 24 19:29:04.665 2020 Starting thread
Fri Jan 24 19:29:04.665 2020 OpenVPN core 3.6.2 AirVPN linux x86_64 64-bit
Fri Jan 24 19:29:04.674 2020 Frame=512/2048/512 mssfix-ctrl=1250
Fri Jan 24 19:29:04.680 2020 UNUSED OPTIONS
2 [resolv-retry] [infinite]
3 [nobind]
4 [persist-key]
5 [persist-tun]
6 [auth-nocache]
7 [route-delay] [5]
8 [verb] [3]
9 [explicit-exit-notify] [5]
17 [pull-filter] [ignore] [dhcp-option DNS]
Fri Jan 24 19:29:04.680 2020 EVENT: RESOLVE
Fri Jan 24 19:29:04.680 2020 WARNING: Network filter and lock is disabled
Fri Jan 24 19:29:04.681 2020 Contacting [2001:ac8:20:96:226a:3a84:c3d8:dba8]:443 via UDP
Fri Jan 24 19:29:04.681 2020 EVENT: WAIT
Fri Jan 24 19:29:04.681 2020 net_route_best_gw query IPv6: 2001:ac8:20:96:226a:3a84:c3d8:dba8/128
Fri Jan 24 19:29:04.681 2020 sitnl_route_best_gw result: via fe80::9a9b:cbff:fe6d:a378 dev enp35s0
Fri Jan 24 19:29:04.681 2020 Fri Jan 24 19:29:04.681 2020 EVENT: DISCONNECTED
Fri Jan 24 19:29:04.681 2020 OpenVPN3 CONNECT ERROR: ipv4_exception: error parsing IPv4 address '2001:ac8:20:96:226a:3a84:c3d8:dba8' : Invalid argument
Fri Jan 24 19:29:04.681 2020 Thread finished
STATS:

Want it even funnier? Here ya go:

$ sudo ./hummingbird -N off -i tls-crypt.ovpn
Hummingbird - AirVPN OpenVPN 3 Client 1.0.1 - 24 January 2020

Fri Jan 24 19:31:09.398 2020 Starting thread
Fri Jan 24 19:31:09.399 2020 OpenVPN core 3.6.2 AirVPN linux x86_64 64-bit
Fri Jan 24 19:31:09.410 2020 Frame=512/2048/512 mssfix-ctrl=1250
Fri Jan 24 19:31:09.416 2020 UNUSED OPTIONS
2 [resolv-retry] [infinite]
3 [nobind]
4 [persist-key]
5 [persist-tun]
6 [auth-nocache]
7 [route-delay] [5]
8 [verb] [3]
9 [explicit-exit-notify] [5]
17 [pull-filter] [ignore] [dhcp-option DNS]
Fri Jan 24 19:31:09.416 2020 EVENT: RESOLVE
Fri Jan 24 19:31:09.416 2020 WARNING: Network filter and lock is disabled
Fri Jan 24 19:31:09.416 2020 Contacting [2a00:c98:2050:a02f:da70:5acb:fd13:14a0]:443 via UDP
Fri Jan 24 19:31:09.416 2020 EVENT: WAIT
Fri Jan 24 19:31:09.416 2020 net_route_best_gw query IPv6: 2a00:c98:2050:a02f:da70:5acb:fd13:14a0/128
Fri Jan 24 19:31:09.416 2020 sitnl_route_best_gw result: via UNSPEC dev
Fri Jan 24 19:31:09.416 2020 Fri Jan 24 19:31:09.416 2020 Connecting to [2a00:c98:2050:a02f:da70:5acb:fd13:14a0]:443 (2a00:c98:2050:a02f:da70:5acb:fd13:14a0) via UDPv6
Fri Jan 24 19:31:09.428 2020 EVENT: CONNECTING
Fri Jan 24 19:31:09.429 2020 Tunnel Options:V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client
Fri Jan 24 19:31:09.429 2020 Peer Info:
IV_VER=3.6.2 AirVPN
IV_PLAT=linux
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
UV_IPV6=yes
IV_GUI_VER=Hummingbird - AirVPN OpenVPN 3 Client 1.0.1
IV_SSL=mbed TLS 2.16.3

Fri Jan 24 19:31:09.481 2020 VERIFY OK : depth=1
cert. version     : 3
serial number     : 8C:D8:43:EF:E4:5F:20:03
issuer name       : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
subject name      : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
issued  on        : 2014-04-11 10:15:45
expires on        : 2024-04-08 10:15:45
signed using      : RSA with SHA1
RSA key size      : 4096 bits
basic constraints : CA=true

Fri Jan 24 19:31:09.481 2020 VERIFY OK : depth=0
cert. version     : 3
serial number     : 58
issuer name       : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
subject name      : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Veritate, emailAddress=info@airvpn.org
issued  on        : 2016-12-02 16:51:45
expires on        : 2026-11-30 16:51:45
signed using      : RSA with SHA-512
RSA key size      : 4096 bits
basic constraints : CA=false
cert. type        : SSL Server
key usage         : Digital Signature, Key Encipherment
ext key usage     : TLS Web Server Authentication

Fri Jan 24 19:31:09.718 2020 SSL Handshake: TLSv1.2/TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
Fri Jan 24 19:31:09.718 2020 Session is ACTIVE
Fri Jan 24 19:31:09.718 2020 EVENT: GET_CONFIG
Fri Jan 24 19:31:09.718 2020 Sending PUSH_REQUEST to server...
Fri Jan 24 19:31:09.844 2020 OPTIONS:
0 [route] [192.168.0.0] [255.255.0.0] [net_gateway]
1 [comp-lzo] [no]
2 [redirect-gateway] [ipv6] [def1] [bypass-dhcp]
3 [dhcp-option] [DNS] [10.22.198.1]
4 [dhcp-option] [DNS6] [fde6:7a:7d20:12c6::1]
5 [tun-ipv6]
6 [route-gateway] [10.22.198.1]
7 [topology] [subnet]
8 [ping] [10]
9 [ping-restart] [60]
10 [ifconfig-ipv6] [fde6:7a:7d20:12c6::10bc/64] [fde6:7a:7d20:12c6::1]
11 [ifconfig] [10.22.198.190] [255.255.255.0]
12 [peer-id] [2]
13 [cipher] [AES-256-GCM]

Fri Jan 24 19:31:09.844 2020 PROTOCOL OPTIONS:
  cipher: AES-256-GCM
  digest: NONE
  ncp enabled: yes
  compress: LZO_STUB
  peer ID: 2
Fri Jan 24 19:31:09.844 2020 EVENT: ASSIGN_IP
Fri Jan 24 19:31:09.844 2020 exception parsing IPv4 route: [route] [192.168.0.0] [255.255.0.0] [net_gateway]  : tun_prop_route_error: tun_builder_exclude_route failed
Fri Jan 24 19:31:09.844 2020 Pushed DNS Server IPv4 10.22.198.1 ignored
Fri Jan 24 19:31:09.844 2020 Pushed DNS Server IPv6 fde6:7a:7d20:12c6::1 ignored
Fri Jan 24 19:31:09.844 2020 net_iface_mtu_set: mtu 1500 for tun1
Fri Jan 24 19:31:09.844 2020 net_iface_up: set tun1 up
Fri Jan 24 19:31:09.845 2020 net_addr_add: 10.22.198.190/24 brd 10.22.198.255 dev tun1
Fri Jan 24 19:31:09.845 2020 net_addr_add: fde6:7a:7d20:12c6::10bc/64 dev tun1
Fri Jan 24 19:31:09.845 2020 net_route_add: 0.0.0.0/1 via 10.22.198.1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:09.845 2020 net_route_add: 128.0.0.0/1 via 10.22.198.1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:09.845 2020 net_route_add: ::/1 via fde6:7a:7d20:12c6::1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:09.845 2020 net_route_add: 8000::/1 via fde6:7a:7d20:12c6::1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:09.845 2020 Connected via tun
Fri Jan 24 19:31:09.845 2020 LZO-ASYM init swap=0 asym=1
Fri Jan 24 19:31:09.846 2020 Comp-stub init swap=0
Fri Jan 24 19:31:09.846 2020 EVENT: CONNECTED [2a00:c98:2050:a02f:da70:5acb:fd13:14a0]:443 (2a00:c98:2050:a02f:da70:5acb:fd13:14a0) via /UDPv6 on tun/10.22.198.190/fde6:7a:7d20:12c6::10bc gw=[10.22.198.1/fde6:7a:7d20:12c6::1]
^Creceived stop signal 2
Fri Jan 24 19:31:16.114 2020 net_route_del: 8000::/1 via fde6:7a:7d20:12c6::1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:16.114 2020 net_route_del: ::/1 via fde6:7a:7d20:12c6::1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:16.114 2020 net_route_del: 128.0.0.0/1 via 10.22.198.1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:16.114 2020 net_route_del: 0.0.0.0/1 via 10.22.198.1 dev tun1 table 0 metric 0
Fri Jan 24 19:31:16.114 2020 net_addr_del: fde6:7a:7d20:12c6::10bc/64 dev tun1
Fri Jan 24 19:31:16.114 2020 net_addr_del: 10.22.198.190/24 dev tun1
Fri Jan 24 19:31:16.114 2020 net_iface_mtu_set: mtu 1500 for tun1
Fri Jan 24 19:31:16.114 2020 net_iface_up: set tun1 down
Fri Jan 24 19:31:16.115 2020 Fri Jan 24 19:31:16.150 2020 EVENT: DISCONNECTED
Fri Jan 24 19:31:16.150 2020 Thread finished
STATS:
  BYTES_IN : 6575
  BYTES_OUT : 10912
  PACKETS_IN : 25
  PACKETS_OUT : 62
  TUN_BYTES_IN : 5350
  TUN_BYTES_OUT : 1359
  TUN_PACKETS_IN : 49
  TUN_PACKETS_OUT : 13

 

Now to summarize the IPs it connected to:

1. 2a00:c98:2050:a007:ba5e:c9f1:828f:291c – SUCCESS
2. 2001:ac8:20:99:fbf6:b62a:86df:b560 – FAIL
3. 2001:ac8:20:96:226a:3a84:c3d8:dba8 – FAIL
4. 2a00:c98:2050:a02f:da70:5acb:fd13:14a0 – SUCCESS

You think you see a pattern? Let's put it to the test. I queried AirDNS for all the servers and searched for one with specific characteristics in the first three nibbles: One with at least one letter, one with a number outside v4 range and then one inside it.

1. 2a0a:b640:1:4:bc8c:6f80:9d39:d338 – FAIL
2. 2804:5364:3100:8:8ea6:d3e3:5cb5:c248 – FAIL
3. 2001:df0:465:1085:49e:ce88:be89:43a9 – FAIL

Huh. I reconnected with OpenVPN and they ALL worked! Well, in part, because now something was wrong with the routes or so, but at least it correctly identified the address as v6! The v6detecttest.ovpn is the same as tls-crypt.ovpn from previous tests, only all remote* directives are replaced with the one I wanted to test.

$ sudo ./hummingbird -N off -i v6detecttest.ovpn
Hummingbird - AirVPN OpenVPN 3 Client 1.0.1 - 24 January 2020

Fri Jan 24 19:47:34.844 2020 Starting thread
Fri Jan 24 19:47:34.844 2020 OpenVPN core 3.6.2 AirVPN linux x86_64 64-bit
Fri Jan 24 19:47:34.853 2020 Frame=512/2048/512 mssfix-ctrl=1250
Fri Jan 24 19:47:34.859 2020 UNUSED OPTIONS
2 [resolv-retry] [infinite]
3 [nobind]
4 [persist-key]
5 [persist-tun]
6 [auth-nocache]
7 [route-delay] [5]
8 [verb] [3]
9 [explicit-exit-notify] [5]
17 [pull-filter] [ignore] [dhcp-option DNS]
Fri Jan 24 19:47:34.860 2020 EVENT: RESOLVE
Fri Jan 24 19:47:34.860 2020 WARNING: Network filter and lock is disabled
Fri Jan 24 19:47:34.860 2020 Contacting [2001:df0:465:1085:49e:ce88:be89:43a9]:443 via UDP
Fri Jan 24 19:47:34.860 2020 EVENT: WAIT
Fri Jan 24 19:47:34.860 2020 net_route_best_gw query IPv6: 2001:df0:465:1085:49e:ce88:be89:43a9/128
Fri Jan 24 19:47:34.860 2020 sitnl_route_best_gw result: via UNSPEC dev
Fri Jan 24 19:47:34.860 2020 Fri Jan 24 19:47:34.860 2020 Connecting to [2001:df0:465:1085:49e:ce88:be89:43a9]:443 (2001:df0:465:1085:49e:ce88:be89:43a9) via UDPv6
Fri Jan 24 19:47:44.860 2020 Server poll timeout, trying next remote entry...
Fri Jan 24 19:47:44.860 2020 EVENT: RECONNECTING
Fri Jan 24 19:47:44.860 2020 ERROR: N_RECONNECT
Fri Jan 24 19:47:44.860 2020 EVENT: RESOLVE
Fri Jan 24 19:47:44.860 2020 WARNING: Network filter and lock is disabled
Fri Jan 24 19:47:44.860 2020 Contacting [2001:df0:465:1085:49e:ce88:be89:43a9]:443 via UDP
Fri Jan 24 19:47:44.860 2020 EVENT: WAIT
Fri Jan 24 19:47:44.860 2020 net_route_best_gw query IPv6: 2001:df0:465:1085:49e:ce88:be89:43a9/128
Fri Jan 24 19:47:44.860 2020 sitnl_route_best_gw result: via UNSPEC dev
Fri Jan 24 19:47:44.860 2020 Fri Jan 24 19:47:44.860 2020 Connecting to [2001:df0:465:1085:49e:ce88:be89:43a9]:443 (2001:df0:465:1085:49e:ce88:be89:43a9) via UDPv6
^Creceived stop signal 2
Fri Jan 24 19:47:47.374 2020 EVENT: DISCONNECTED
Fri Jan 24 19:47:47.374 2020 Thread finished
STATS:
  BYTES_OUT : 702
  PACKETS_OUT : 13
  N_RECONNECT : 1

I'm not entirely sure what to make of it all. If it really is something with my configuration, I must test other machines…

---

Apart from that, it couldn't create custom routes via route directive, it seems, but that might be because it doesn't know the special keywork net_gateway yet:

Fri Jan 24 19:10:22.633 2020 exception parsing IPv4 route: [route] [192.168.0.0] [255.255.0.0] [net_gateway]  : tun_prop_route_error: tun_builder_exclude_route failed

I overlooked the ::/1 via fde6… route.

Then there's this line:

Fri Jan 24 19:10:22.634 2020 net_route_add: 8000::/1 via fde6:7a:7d20:7fa::1 dev tun1 table 0 metric 0

According to subnetcalc that's… 8000:: to FFFF:FFFF:…?

$ subnetcalc 8000::/1
Address       = 8000::
                   8000 = 10000000 00000000
                   0000 = 00000000 00000000
                   0000 = 00000000 00000000
                   0000 = 00000000 00000000
                   0000 = 00000000 00000000
                   0000 = 00000000 00000000
                   0000 = 00000000 00000000
                   0000 = 00000000 00000000
Network       = 8000:: / 1
Netmask       = 8000::
Wildcard Mask = 7fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Hosts Bits    = 127
Max. Hosts    = 2^127 - 1
Host Range    = { 8000::1 - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff }
Properties    =
   - 8000:: is a NETWORK address
GeoIP Country = Unknown (??)

It also seems to not set the v6 routes for all currently assigned UGAs like OpenVPN does. v4 is done right:

$ ip r
0.0.0.0/1 via 10.25.166.1 dev tun1
0.0.0.0/1 via 10.13.178.1 dev tun0
default via 192.168.110.1 dev enp35s0 proto dhcp metric 100
10.13.178.0/24 dev tun0 proto kernel scope link src 10.13.178.172
10.25.166.0/24 dev tun1 proto kernel scope link src 10.25.166.41
128.0.0.0/1 via 10.25.166.1 dev tun1
128.0.0.0/1 via 10.13.178.1 dev tun0
192.168.0.0/16 via 192.168.110.1 dev enp35s0
192.168.110.0/24 dev enp35s0 proto kernel scope link src 192.168.110.11 metric 100

v6 is.. "neglected"?

$ ip -6 r
::1 dev lo proto kernel metric 256 pref medium
::/3 dev tun0 metric 1024 pref medium
2001:ac8:20:2c:8efe:ed7:7e97:6f97 via fe80::xxxx:xxff:fexx:xxxx dev enp35s0 metric 1 pref medium
2003:xxxx:xxxx:xxxx::/64 dev enp35s0 proto ra metric 100 pref medium
2003:xxxx:xxxx:xxxx::/56 via fe80::xxxx:xxff:fexx:xxxx dev enp35s0 proto ra metric 100 pref medium
2000::/4 dev tun0 metric 1024 pref medium
3000::/4 dev tun0 metric 1024 pref medium
::/1 via fde6:7a:7d20:15a6::1 dev tun1 metric 1024 pref medium
fde6:7a:7d20:9b2::/64 dev tun0 proto kernel metric 256 pref medium
fde6:7a:7d20:15a6::/64 dev tun1 proto kernel metric 256 pref medium
fc00::/7 dev tun0 metric 1024 pref medium
fe80::/64 dev enp35s0 proto kernel metric 100 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev tun1 proto kernel metric 256 pref medium
8000::/1 via fde6:7a:7d20:15a6::1 dev tun1 metric 1024 pref medium
default via fe80::xxxx:xxff:fexx:xxxx dev enp35s0 proto ra metric 100 pref medium

[monstrocity 31]

On Linux Mint 19.3 I'm still getting TCP_OVERFLOW errors on both stand alone Hummingbird and in Eddie 2.18.6 beta.  Like with Hummingbird 1.0.0, this error appears while torrenting; the client cannot keep pace with the number of requests and throws the error - not sure if there's a fix for it.  I'm unable to use the UDP protocol, as all UDP ports are closed by default where I have internet access.

eddie.log

[pjnsmb 13]

@Staff

For the record after updating to hummingbird  1.01 :

Still the same :
ERROR: Cannot activate network filter and lock
 The first time the error appears it has dropped down a few lines in the log due to a reference to network manager and systemd-resolved .

regards

 

1.0.1 1.0.0

[Staff 9972]

@pjnsmb

Hello!

Hummingbird tries to use in sequence the first available firewall between iptables, iptables-legacy, nftables and pf. In your case, Hummingbird finds iptables-legacy. With IPv4 no errors seems to arise, but the problem comes out with IPv6. ip[6]tables-legacy is a wrapper to nftables, so IPv6 support in nftables might be the problem, or maybe it's a bug in ip6tables legacy in your unstable distribution (or you just disabled IPv6 support in your system, but you told us that you keep getting the error even when you re-enable it, can you confirm?).

Can you please re-test Humminbird without the --ipv6 no option you enforced, just in case, and check whether the problem is the same or not?

Another possible test, but it's more problematic if you need iptables syntax somewhere in your system or applications, would be removing iptables and iptables-legacy packages. In this case Hummingbird will use nftables.

We can not support unstable distributions (you're running Debian Sid according to your ticket) because we can't circumvent all the possible bugs which an unstable distribution may potentially come with: it would be a wrong approach and anyway it would be an overwhelming task.

However, we will offer in a near future release the option to force Hummingbird to use a firewall chosen by the user. When the option is available you will be able to force usage of nftables, bypassing iptables-legacy, if it's causing the issue.

Please keep us informed if you decide to perform any of the above tests.

Kind regards
 

[Staff 9972]

@monstrocity

Hello!

Bug detected and under investigation. It involves all versions of OpenVPN 3 library (not only our fork unfortunately) so it must be something we have been dragging with us since the very beginning, OR (worst case scenario) something related to asio library (hopefully not). If you have the option to use UDP, please do it, otherwise stay tuned, we have given very high priority to the bug.

Kind regards
 

[pjnsmb 13]

@Staff

After doing a fair amount of investigation and research into iptables and nftables I found that my iptables in use only covered a default  basic firewall setting without any additions that would hopefully not cause a problem to any programmes or system settings if removed.
I read up on converting iptables to nftables, did so, deleted iptables, and started using nftables.
I can now use hummingbird with network lock working correctly.
As a result of these changes there are no entries in the log anymore showing any problems with IPv6 .

I am grateful of your explanations and help 

p.s I would not have made these changes and alterations without a decent backup programme in place to use if all went 'pear-shaped'
I recommend for linux  :
https://github.com/teejee2008/timeshift


 

[Staff 9972]

@monstrocity

Please increase the maximum amount of packets allowed in the TCP queue with directive tcp-queue-limit n (n is the amount of packets) according to the amount of concurrent, global TCP connections your system needs when you run a BitTorrent software. OpenVPN 3 default limit is 64 packets.

For example, add to your profile the following line:

tcp-queue-limit 256

Please test again and check whether the problem is resolved. Of course consider to increase the amount of packets beyond 256 if you see the problem persisting.

Your feedback is very much appreciated.

Kind regards
 

[monstrocity 31]

Added tcp-queue-limit 2048 in OPVN custom directives through Eddie using Hummingbird 1.01 and so far not seeing any TCP_OVERFLOW errors.  Will report if the error returns. Thanks.

Noting other Hummingbird errors through Eddie:
ERROR: KEY_STATE_ERROR
TCP recv error: Connection reset by peer
ERROR: NETWORK_RECV_ERROR
EVENT: TRANSPORT_ERROR Transport error on '37.120.210.221: NETWORK_RECV_ERROR [ERR]
ERROR: TRANSPORT_ERROR
Client terminated, restarting in 5000 ms...
ERROR: N_RECONNECT

log.txt

[Staff 9972]

@monstrocity

Hello,

we're very glad to see that the problem is resolved. 2048 packets make the output queue huge, but actually it is proportional to the amount of concurrent connections limit you have set in your torrent software. qBittorrent comes with a limit of 500 by default.

The other error you report pertains to a disconnection, unrelated to TCP_OVERFLOW. If you get such disconnections more often when you torrent, please warn us.

For the readers: overflow in the TCP output queue is a problem that does not exist in UDP.

Kind regards
 

[monstrocity 31]

@Staff Thanks for the advice.  Setting tcp-queue-limit to 500.  Will report again about the disconnects if I still get them.  Regarding UDP, I can get a connection for about 5 minutes before it gets shutdown; I'm behind a school firewall, so there's nothing I can do with UDP.  TCP is my only viable option unfortunately.
TCP_OVERFLOW error with limit set at 500, trying 1024 instead.


On 1-2 active torrents, tcp-queue-limit 1024 still leads to the TCP_OVERFLOW error with the same errors noted earlier; at that point Eddie reconnects but doesn't crash - now on Eddie 2.18.7 beta.  Setting tcp-queue-limit to 5000 or higher appears to work.
 

[nexsteppe 24]

I recently updated my local hummingbird and openvpn3-airvpn repos to the latest commits and rebuilt a dynamic binary under the latest Slackware x86_64 current.  No problems with this.
However, I'm still encountering the key errors I reported with hummingbird 1.0 with this updated version, now typically within a few hours of connecting.  The difference from before is the tunnel not only remains up now, but will typically renegotiate the key successfully at the hour mark.  But the key error usually happens again before too long.

Should it be helpful for troubleshooting, here is the (slightly redacted) ovpn I use to connect to AirVPN Canada servers with hummingbird:

client
dev tun
mssfix 1470
remote ca3.vpn.airdns.org 443 udp
setenv UV_IPV6 yes
push-peer-info
cert keys/airvpn.crt
key keys/airvpn.key
cipher AES-256-CBC
auth SHA512
comp-lzo no
remote-cert-tls server
<ca>
... redacted ...
</ca>
<tls-crypt>
... redacted ...
</tls-crypt>