Linux: AirVPN Suite 2.0.0 preview available

[183aTr78f9o 23]

 @Staff etc/airvpn/bluetit.rc from RC3 x86_64 tarball still contains the deprecated airvpnconnectivitycheck option and the new networkcheck isn't included.

Also checked ARM64 tarball: same. I guess all tarballs are affected.

[Staff 10222]

8 hours ago, 183aTr78f9o said:

 @Staff etc/airvpn/bluetit.rc from RC3 x86_64 tarball still contains the deprecated airvpnconnectivitycheck option and the new networkcheck isn't included.

Also checked ARM64 tarball: same. I guess all tarballs are affected.

Hello!

Yes, thanks a lot! It will be fixed very soon.

Kind regards
 

[Pwbkkee 0]

Bluetit 2.0.0 RC 3 no longer segfaults when disconnecting from an OpenVPN server. But it still fails with SIGABRT and "status 'core-dump'" when systemd sends it a SIGTERM, even when Bluetit is not connected to a VPN server.

[Staff 10222]

9 hours ago, Pwbkkee said:

Bluetit 2.0.0 RC 3 no longer segfaults when disconnecting from an OpenVPN server. But it still fails with SIGABRT and "status 'core-dump'" when systemd sends it a SIGTERM, even when Bluetit is not connected to a VPN server.

Hello!

Does it happen in the same environment described here? https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available/?do=findComment&comment=251565

Kind regards
 

[Pwbkkee 0]

Yes, it happens in the same environment. But Bluetit 2.0.0 RC 3 works well otherwise.

(My custom Goldcrest systemd service is a user-level service, so it runs without root privileges. I don't use WireGuard at all. Network Lock is disabled on my system; I manually activate and deactivate my own set of firewall rules that I adapted from Network Lock. I manually configure systemd-resolved to exclusively use the VPN DNS resolver each time I connect.)

[Staff 10222]

On 7/21/2025 at 2:51 AM, Pwbkkee said:

Yes, it happens in the same environment. But Bluetit 2.0.0 RC 3 works well otherwise.

(My custom Goldcrest systemd service is a user-level service, so it runs without root privileges. I don't use WireGuard at all. Network Lock is disabled on my system; I manually activate and deactivate my own set of firewall rules that I adapted from Network Lock. I manually configure systemd-resolved to exclusively use the VPN DNS resolver each time I connect.)

Hello!

Can you also send us the complete Bluetit log from the journal?

Kind regards
 

[Pwbkkee 0]

Jul 21 22:00:00 sudo[3249]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/systemctl stop bluetit.service
Jul 21 22:00:00 sudo[3249]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
Jul 21 22:00:00 bluetit[1290]: Received Terminated signal. Terminating Bluetit.
Jul 21 22:00:00 systemd[1]: Stopping bluetit.service - AirVPN Bluetit Daemon...
Jul 21 22:00:00 bluetit[1290]: AirVPN Manifest updater thread terminated
Jul 21 22:00:00 bluetit[1290]: Sending event 'event_end_of_session'
Jul 21 22:00:00 systemd[1]: bluetit.service: Main process exited, code=dumped, status=6/ABRT
Jul 21 22:00:00 systemd[1]: bluetit.service: Failed with result 'core-dump'.
Jul 21 22:00:00 systemd[1]: Stopped bluetit.service - AirVPN Bluetit Daemon.
Jul 21 22:00:00 systemd[1]: bluetit.service: Consumed 7.247s CPU time.

The rest of Bluetit's log shows nothing unusual.

[Staff 10222]

10 hours ago, Pwbkkee said:

The rest of Bluetit's log shows nothing unusual.

Hello!

Thank you, most probably you are right but please do not cut the log anyway, we want to see it integrally.

Kind regards
 

[Staff 10222]

On 7/21/2025 at 2:51 AM, Pwbkkee said:

Yes, it happens in the same environment. But Bluetit 2.0.0 RC 3 works well otherwise.

Hello!

You'll be able to avoid any problem by fixing your unit files according to our previous directions. An updated recap after extensive tests and gdb debugging which shows no problems and no crashes (again, provided that the modifications have been implemented).

1. Change permissions of /etc/airvpn.org into 755 (default is 660) to avoid systemd errors (you must have already done this, or you have used proper directives in the unit file, otherwise Bluetit wouldn't start at all but we repeat it for reader's comfort) 

chmod 755 /etc/airvpn

2. Add the following directives in Bluetit unit file:

KillSignal=SIGTERM
SendSIGKILL=no

to prevent systemd from sending an expected SIGKILL to Bluetit

3. Consider to define the dependency and  sequence criteria (systemd correctly warns you that you have not defined them, so it does not know when to start the unit). Example (taken from the default Bluetit unit file):

After=network-online.target firewalld.service ufw.service dbus-daemon.service dbus.socket
Wants=network-online.target firewalld.service ufw.service dbus-daemon.service dbus.socket

4. Just in case you will decide to use WireGuard and/or Network Lock, you must allow Bluetit to load kernel modules (WireGuard, iptables, nft, xtables...), so this directive:

ProtectKernelModules=true

must be deleted or set to false to prevent a critical error.

5. Just in case you will decide to use per app traffic splitting, the following directive must be deleted or set to false

RestrictNamespaces=true

because per app traffic splitting is based on namespace construction.

Kind regards
 

[Pwbkkee 0]

It seems unlikely to me that systemd's sandboxing would cause Bluetit to crash only when terminated and not at any other moment before termination. It also seems unlikely to me that mere sandboxing alone would cause a SIGABRT crash leading to an automatic core dump.

My Debian 12 system's kernel (currently 6.1.140) runs with the following command-line options:
 

GRUB_CMDLINE_LINUX_DEFAULT="debugfs=off hardened_usercopy=1 init_on_alloc=1 init_on_free=1 iommu.passthrough=0 iommu.strict=1 lockdown=confidentiality loglevel=0 mitigations=auto,nosmt noefi nohibernate nosgx page_alloc.shuffle=1 quiet randomize_kstack_offset=on slab_nomerge vdso32=0 vsyscall=none"

It also runs with the following sysctl options:
 

dev.tty.ldisc_autoload=0
fs.protected_hardlinks=1
fs.protected_symlinks=1
fs.suid_dumpable=0
kernel.core_pattern=|/usr/bin/false
kernel.dmesg_restrict=1
kernel.kexec_load_disabled=1
kernel.kptr_restrict=2
kernel.perf_event_paranoid=2
kernel.printk=3 3 3 3
kernel.sysrq=0
kernel.unprivileged_bpf_disabled=1
kernel.yama.ptrace_scope=3
net.core.bpf_jit_harden=2
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.default.accept_source_route=0
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.default.secure_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.icmp_echo_ignore_all=1
net.ipv4.tcp_rfc1337=1
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_timestamps=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.accept_source_route=0
vm.swappiness=1
vm.unprivileged_userfaultfd=0

Perhaps my system's hardened kernel caught an obscure bug that your test system did not catch when you were debugging Bluetit.