ANSWERED AirVPN Suite > Bluetit worked once. Then I rebooted...

[ltwally 0]

Fresh install of Lubuntu.  I double-checked the pre-reqs, downloaded and installed the AirVPN Linux Suite.  I configured bluetit via /etc/airvpn/bluetit.rc.  I do have 'networklockpersist' set to 'on'.

After a reboot, I was automatically connected.  Everything looked to be working correctly.

I rebooted again a few minutes later without any changes to the system, and it looks like something is very broken.  I can ping out to public IP addresses (eg. 1.1.1.1), but DNS is not resolving and it doesn't look like AirVPN is connected.

Goldcrest status
 

~/Desktop$ sudo goldcrest --bluetit-status
sudo: unable to resolve host linux: Temporary failure in name resolution
Goldcrest - AirVPN Bluetit Client 1.3.0 - 1 June 2023

2024-09-02 16:15:31 Reading run control directives from file /root/.goldcrest.rc
2024-09-02 16:15:31 Bluetit - AirVPN OpenVPN3 Service 1.3.0 - 1 June 2023
2024-09-02 16:15:31 OpenVPN core 3.8.4 AirVPN linux x86_64 64-bit
2024-09-02 16:15:31 Copyright (C) 2012-2022 OpenVPN Inc. All rights reserved.
2024-09-02 16:15:31 OpenSSL 3.0.13 30 Jan 2024
2024-09-02 16:15:31 It seems Bluetit did not exit gracefully or has been killed.
Your system may not be working properly and your network connection may not work
as expected. To recover your network settings, run this program again and use
the "--recover-network" option.
2024-09-02 16:15:31 Persistent Network Lock and Filter is enabled. (using nftables)
2024-09-02 16:15:31 Bluetit is not connected

 

I've tried 'goldcrest --recover-network' but that does not fix it.

DNS looks odd, too.
 

~/Desktop$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 10.10.102.1
       DNS Servers: 10.10.102.1

Link 2 (ens33)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 192.168.1.1
        DNS Domain: local

 

Not sure where to go from here.  I'm just glad I tried this in VM before deploying to my working linux desktop. 

Advice?

[Staff 9969]

@ltwally

Hello!

DNS remained set to VPN DNS and that's a consequence of the previous unclean exit of Bluetit. Can we see the content of /etc/airvpn directory? Can you also send us Bluetit's log please?

sudo journalctl | grep bluetit > bluetit.log

and then send us the bluetit.log file.

Kind regards
 

[ltwally 0]

I have attached the log.

bluetit.log

[Staff 9969]

@ltwally

Thanks. Can you please send us the content of /etc/airvpn as well?

sudo ls -l /etc/airvpn

Kind regards
 

[ltwally 0]

The only lines changed from default are:
 

airconnectatboot country
networklockpersist on
airusername user
airpassword pass
aircountry Japan

[Staff 9969]

@ltwally

Thanks. Can you please send us the content of /etc/airvpn as well?

sudo ls -l /etc/airvpn

Kind regards

[ltwally 0]

 

root@linux:/etc/airvpn# ll
total 180                                                                                                                                                      
drw-rw----   2 root root   4096 Sep 02 14:51 ./                                                                                                                
drwxr-xr-x 144 root root  12288 Sep 02 14:51 ../                                                                                                               
-rw-rw----   1 root root 139175 Sep 02 14:51 airvpn-manifest.xml                                                                                               
-rw-r-----   1 root root      5 Sep 04 16:53 bluetit.lock
-rw-rw----   1 root root   2639 Sep 02 15:00 bluetit.rc
-rw-rw----   1 root root   1445 Sep 02 14:51 connection_priority.txt
-rw-rw----   1 root root     48 Sep 02 14:51 connection_sequence.csv
-rw-rw----   1 root root    103 Sep 02 14:51 continent_names.csv
-rw-rw----   1 root root   1743 Sep 02 14:51 country_continent.csv
-rw-rw----   1 root root   3737 Sep 02 14:51 country_names.csv

[Staff 9969]

@ltwally

Hello!

The bluetit.lock file shows that Bluetit is right in claiming "It seems Bluetit did not exit gracefully or has been killed." etc. While Bluetit is not running delete that file and set the proper DNS for your system to restore a clean status.

If you killed Bluetit without grace this behavior is fine. But if your did not, then the reasons of the previous crash should be investigated. As soon as the problem re-surfaces please send us the complete Bluetit log from journalctl.

Kind regards
 

[ltwally 0]

On 9/5/2024 at 1:32 AM, Staff said:

@ltwally

Hello!

The bluetit.lock file shows that Bluetit is right in claiming "It seems Bluetit did not exit gracefully or has been killed." etc. While Bluetit is not running delete that file and set the proper DNS for your system to restore a clean status.

If you killed Bluetit without grace this behavior is fine. But if your did not, then the reasons of the previous crash should be investigated. As soon as the problem re-surfaces please send us the complete Bluetit log from journalctl.

Kind regards
 

Apologies if I have been unclear - this happens every time after the initial connection.  Every single time.

I have uninstalled and reinstalled the Suite three times now, with identical results:  After configuring Bluetit, it works on the first reboot.  Every reboot afterwards results in the above scenario. 

I have used the following methods for shutdown & rebooting:  LXQt menu > shutdown, LXQt menu > restart, terminal/CLI> poweroff, terminal/CLI > reboot.  These are not "unclean" shutdowns as far the operating system is concerned.

If Bluetit requires some form of manual disconnect prior to shutting down or rebooting, that would seem to be a flaw in Bluetit.
Likewise, even if there were an "unclean" exit, Bluetit should be able to recover on restart.
Respectfully, in either of these scenarios, I believe this is a developer issue. 
In its current condition, Bluetit appears to be broken and unusable.

Regards Edited ... by ltwally

[ltwally 0]

Additionally, after uninstall, I am required to manually edit or delete /etc/resolve.conf to restore DNS resolution.  This is another item for the developers to address.

Regards

[Staff 9969]

15 hours ago, ltwally said:

n its current condition, Bluetit appears to be broken and unusable.

Hello!

Bluetit works perfectly in many distributions, but this does not mean that it works perfectly in all the 800 (?) existing Linux distributions. Lubuntu is an Ubuntu derivative, so let's check first whether it is affected by this long standing bug which is still not fixed nowadays on Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1872015

To verify whether your Lubuntu system is bugged, just send us the output of

ls -l /etc/resolv.conf

while Bluetit is not running and the system is in pristine conditions. This bug is crucial in DNS management and could explain one (but not all) of the problems you reported. Of course it is not Bluetit developers' responsibility but a workaround can be found and implemented in the next Suite release as we don't think that the bug will be fixed in a reasonable time (it's still unassigned after so many years) so that no manual fix by the user will be needed. The manual fix is simple but it could be beyond the ability of some Ubuntu and Ubuntu derivative users.
 

15 hours ago, ltwally said:

Likewise, even if there were an "unclean" exit, Bluetit should be able to recover on restart.

No, sorry, this is not acceptable when the lock file is existing. This belief was popular on Windows and now it has its supporters among some of systemd zealots, and look what the Linux world of many systemd based distributions have become today (also) as a result of contamination from Windows. An unclean exit that's not inside the range of recoverable causes foreseen by the software, especially when this software is a real daemon modifying routing table, firewall rules and DNS settings, requires investigation by the superuser, otherwise the superuser might be prevented forever to spot and detect an unclean exit, and that would be a huge problem indeed.
 

15 hours ago, ltwally said:

After configuring Bluetit, it works on the first reboot.  Every reboot afterwards results in the above scenario. 

Unfortunately this is not reproducible on our testing systems and we don't have other similar cases in the tickets. We don't have Lubuntu in testing systems, though, so it might be a distribution specific problem. We will investigate.

In the meantime, if you haven't already done so, can you please remove the Suite 1.3.0 and test the 2.0.0 beta 1? Check whether any of the problems you report is solved or not, thanks in advance. To download the Suite 2.0.0 please see here:
https://airvpn.org/forums/topic/56704-linux-airvpn-suite-200-beta-available/

Suite 2.0.0 beta 1 addresses various bugs, implements reverse traffic splitting and extends compatibility to a few more distributions, but remember that Lubuntu is not among our testing systems, so your reports will be valuable again. If any problem persists, we need to see again the complete Bluetit log after any problem occurred.

Kind regards