Hummingbird Error message

[fiverair 1]

I had error message on my hummingbird app, especially while uploading file. 

'uname -a' : 
 Linux fedora.fedora 5.4.8-200.fc31.x86_64 #1 SMP Mon Jan 6 16:44:18 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Message repeated almost every minute:
Error: pktid_replay
Error: replay_error

 

[Staff 9973]

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


 

[fiverair 1]

Thanks for the kind explanation (and educating me on networking tech).  It seems another error had popped up. That of a keepalive error which commonly appeared on my embedded appliance using the old console openvpn 1 year ago.

Below is a partial log:

14:35:21.888 2020 ERROR: KEEPALIVE_TIMEOUT
14:35:21.888 2020 Session invalidated: KEEPALIVE_TIMEOUT
14:35:21.888 2020 Client terminated, restarting in 2000 ms...
14:35:23.886 2020 EVENT: RECONNECTING
14:35:23.887 2020 ERROR: Backup copy of resolv.conf not found.
14:35:23.923 2020 Network filter successfully restored
14:35:23.923 2020 ERROR: N_RECONNECT
14:35:23.923 2020 EVENT: RESOLVE
14:35:23.923 2020 WARNING: NetworkManager is running on this system and may interfere with DNS management and cause DNS leaks
14:35:23.923 2020 Network filter and lock is using iptables-legacy
14:35:23.931 2020 Successfully loaded kernel module iptable_filter
14:35:23.947 2020 Successfully loaded kernel module iptable_nat
14:35:23.950 2020 Successfully loaded kernel module iptable_mangle
14:35:23.953 2020 Successfully loaded kernel module iptable_security
14:35:23.956 2020 Successfully loaded kernel module iptable_raw
14:35:23.958 2020 Successfully loaded kernel module ip6table_filter
14:35:23.972 2020 Successfully loaded kernel module ip6table_nat
14:35:23.975 2020 Successfully loaded kernel module ip6table_mangle
14:35:23.977 2020 Successfully loaded kernel module ip6table_security
14:35:23.980 2020 Successfully loaded kernel module ip6table_raw
14:35:23.980 2020 WARNING: firewalld is running on this system and may interfere with network filter and lock
14:35:23.991 2020 Network filter successfully initialized
14:35:23.991 2020 Local IPv4 address 10.205.36.166
14:35:23.991 2020 Local IPv6 address fe80::b4d3:f6ff:fea4:4069
14:35:23.991 2020 Local interface enp3s0f0
14:35:23.991 2020 Local interface wlp1s0
14:35:23.991 2020 Setting up network filter and lock

There are the usual lines flowing further along this log allowing system dns to pass through the network filter. However, it never get to the usual text EVENT:CONNECTED indicating system dns is rejected by the network filter after EVENT:CONNECTING.

It lasted quite a few tens of minutes, before i decided to close the connection and disconnect and connect the wifi. It finally worked in the end with EVENT:CONNECTED. This is my first time seeing this error after a few days on hummingbird.

It has been relatively smooth for the past few days. Just like to let you know that i appreciate hummingbird is an asset, better than eddie because without  gui overhead. 

  Edited ... by fiverair
clarify the embedded appliance using old openvpn tech

[Staff 9973]

Hello!

A connectionless tunnel (UDP is connectionless) is kept alive with ping inside the tunnel. In our service a ping every 10 seconds and a keepalive timeout of 60 seconds. If a side does not receive any reply from the other side in 60 seconds, it assumes that the other side is no more there. The keepalive timeout is followed by a reconnection attempt, as we can see in the log.

IF you see that the reconnection attempt does not follow a keepalive timeout, please notify us and send us the log pertaining to the event.

Kind regards