Jump to content
Not connected, Your IP: 18.119.106.66
Staff

Linux new software: AirVPN Suite 1.0 beta

Recommended Posts

@OpenSourcerer
 
Quote

I don't even get to connect anymore. --air-ipv6, --ipv6 and --air-6to4 are set to off via rc, but it seemingly uses IPv6 for connection.


Hello!

Bluetit does not try to connect in IPv6, it respects the options that force it to connect in IPv4. However, from ipleak.net you get a reply of an IPv6 address, so it seems that you have IPv6 only. Then the log shows an empty entry, which must be investigated as it is abnormal. Then Bluetit explicitly avoids IPv6, according to your command option "-V off" and your rc file.

Some other questions: are you sure that you have IPv4, or might it be that you have only IPv4 over IPv6? In general, without Bluetit, how do you connect to AirVPN in pure IPv4?

Kind regards
 

Share this post


Link to post
4 hours ago, Staff said:
@pjnsmb

Hello!

We already asked in the past but we don't see any reply so we ask again: what is your distribution name and version?

Kind regards


from my post 22.11.20 :

for your information my system is linux unstable :

System:
Host: desktop Kernel: 5.9.9-towo.2-siduction-amd64 x86_64 bits: 64
Desktop: Cinnamon 4.6.7
Distro: siduction 18.3.0 Patience - cinnamon - (202010261730)


😁😁

regards
pjnsmb

Share this post


Link to post
4 hours ago, Staff said:

However, from ipleak.net you get a reply of an IPv6 address, so it seems that you have IPv6 only.


Well, no, if I disabled IPv4 I would cut myself from half the internet. The more plausible answer is that my system simply prefers IPv6. You know, getaddrinfo is asked, v6 returned, Bluetit asks for IP using that, voila, IPv6 result. Unless you explicitly programmed it to show both. But I never witnessed it print both.
 
4 hours ago, Staff said:

are you sure that you have IPv4, or might it be that you have only IPv4 over IPv6?


Well, as written, I would've noticed right away if I ever lost the native v4 connection. In fact, I'm connected to Kitalpha right now over v4 only.
 
4 hours ago, Staff said:

In general, without Bluetit, how do you connect to AirVPN in pure IPv4?


I've got this Kitalpha profile for that, and I use with with OpenVPN 2.5.0:

client
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
verb 3
explicit-exit-notify 5
remote-cert-tls server
data-ciphers AES-256-GCM #:CHACHA20-POLY1305
data-ciphers-fallback AES-256-CBC
comp-lzo no
proto udp4
auth SHA512
fast-io
rcvbuf 524288
sndbuf 131072
remote 91.214.169.71 443
route 192.168.0.0 255.255.0.0 net_gateway
<ca, cert, key, tls-crypt>

</ca, cert, key, tls-crypt>

.

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post
@OpenSourcerer

Hello!

Thank you again for your ongoing tests.
Quote

Well, no, if I disabled IPv4 I would cut myself from half the internet. The more plausible answer is that my system simply prefers IPv6. You know, getaddrinfo is asked, v6 returned, Bluetit asks for IP using that, voila, IPv6 result.



Well no, the IP address you see in the log is never returned by getaddrinfo,

getaddrinfo returns structure(s) where the IP address of your network interface assigned by your upstream is included. In general it is / they are not necessarily the IP address(es) which your packets reach the Internet with (in most cases, it/they will be private address(es), of course). We do not rely on getaddrinfo and the issue can't come from it. It's strange that you mention it, so if we miss something please elaborate.

Furthermore,: the address returned by ipleak.net (and not by getaddrinfo) is never used by Bluetit for the VPN connection. Note that Bluetit tries to know, via ipleak.net, the country your system is in, which is relevant for the quick connection algorithm, nothing else. The returned IPv6 address we noticed led us to ask you whether you have native IPv4 support or not.
Quote


Well, as written, I would've noticed right away if I ever lost the native v4 connection. In fact, I'm connected to Kitalpha right now over v4 only.



We don't understand why that would be relevant. What you say does not imply that you have native IPv4 connectivity. 🤔 You would connect anyway to IPv4 services if your ISP provides you with IPv6 only,. Thanks to any NAT64-like implementation (like T-Mobile in Germany does, you know, with a special implementation of NAT64) voilà, you reach IPv4 services over IPv6, and you don't have native IPv4. 🙃

Maybe the information will give us a clue to understand the issue, because we have no networks built in such a way to perform tests from, so the the fact that the issue can't be reproduced might be explained (or it will not, but it's worth a try). So if you determine that you have or not native IPv4 let us know.

Moreover, can you please (when and if you have time, of course), do the following:
  • connect in pure IPv4 not to Kitalpha (as Kitalpha does not support IPv6) with OpenVPN 2.5
  • connect with Bluetit to Kitalpha through the same profile used by OpenVPN 2.5 in your example and by self connection
  • have Bluetit generate a profile and send it to us (after you have deleted any sensitive data). Test yourself the profile with OpenVPN 2.5 and check what happens with it and Bluetit. We'll do the same and then we can compare both outcomes

Thank you in advance.

Kind regards

Share this post


Link to post
1 hour ago, Staff said:

We do not rely on getaddrinfo and the issue can't come from it. It's strange that you mention it, so if we miss something please elaborate.


I was assuming you resolve the server IPs everytime you connect to them, in which case you either use your own DNS client in Bluetit or something or that of the system. Because if you let the system resolve it, practically all applications are letting the system resolve a name and then take the very first result they get back, which in case of v6 preference is a v6 address. But I see now that all IPs are in the manifest file, so this will not considered further. Carrying on.
 
1 hour ago, Staff said:

What you say does not imply that you have native IPv4 connectivity.


But being able to forward v4 ports does, doesn't it? In case of NAT64, wouldn't I have some hints in my router or OS, like a private v4 assigned to the router or something like 64:ff9b::10.20.30.40? I've never had any of that.
Further, how would I go about and verify if what you say about T-Mobile DE utilizing NAT64 is true?

Furthermore, I feel slightly confused because of all this, because: Why would Bluetit show such behavior whereas OpenVPN never did?
 
1 hour ago, Staff said:

Moreover, can you please (when and if you have time, of course), do the following:

  • connect in pure IPv4 not to Kitalpha (as Kitalpha does not support IPv6) with OpenVPN 2.5
  • connect with Bluetit to Kitalpha through the same profile used by OpenVPN 2.5 in your example and by self connection
  • have Bluetit generate a profile and send it to us (after you have deleted any sensitive data). Test yourself the profile with OpenVPN 2.5 and check what happens with it and Bluetit. We'll do the same and then we can compare both outcomes

 


Bluetit AirVPN connections don't work with any server right now.
But the profiles do. Both, in fact: Mine and the generated one via --air-save.

Generated with same rc as previously, options -O Kitalpha -W <somename>:

#
# OpenSourcerer, key <key name here>
#
# OpenVPN profile for AirVPN server Kitalpha
#

client
dev tun
remote 91.214.169.71 443
proto udp
push-peer-info
setenv UV_IPV6 no
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
verb 3
explicit-exit-notify 5
remote-cert-tls server
cipher AES-256-GCM
comp-lzo no
auth SHA512
<ca,cert,key,tls-crypt>
[…]
</ca,cert,key,tls-crypt>


Goldcrest logs, my config, then the generated:
Bluetit-Kitalpha-ovpn
Bluetit-test-ovpn

Bluetit logs only contain those six lines in addition to the same logs in both cases:

Dez 14 23:34:25 l bluetit[362937]: Requested method "version"
Dez 14 23:34:25 l bluetit[362937]: Requested method "openvpn_info"
Dez 14 23:34:25 l bluetit[362937]: Requested method "bluetit_status -> Bluetit is ready"
Dez 14 23:34:25 l bluetit[362937]: Requested method "reset_bluetit_options -> Bluetit options successfully reset"
Dez 14 23:34:25 l bluetit[362937]: Requested method "set_openvpn_profile -> OK"
Dez 14 23:34:25 l bluetit[362937]: Requested method "start_connection"

.

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post
@OpenSourcerer
 
Quote

But I see now that all IPs are in the manifest file, so this will not considered further. Carrying on.


Exactly... so it can't be that.
 
Quote

Further, how would I go about and verify if what you say about T-Mobile DE utilizing NAT64 is true?


You had better ask your ISP. Probably it has nothing to do with the malfunction but you never know.

In order to cross-check that T-Mobile uses IPv6 only network with a NAT64-like implementation (464XLAT, which is considerably superior than the original NAT64) you can check the official T-Mobile documents. T-Mobile USA announced "breaking free of IPv4" and 464XLAT for IPv6-only network in Apricot 2014, see for example here:
https://conference.apnic.net/data/37/464xlat-apricot-2014_1393236641.pdf

From other documents such as https://together.jolla.com/question/89966/use-dual-stack-ipv4-and-ipv6-on-mobile-data-by-default/ we infer that T-Mobile Germany also adopted XLAT, but it's better that you ask directly your provider for confirmation, even because it's possible that a portion of the network is IPv6 only while a small percentage of users are still stuck to some older Dual Stack etc.
 
Quote

Bluetit AirVPN connections don't work with any server right now.
But the profiles do. Both, in fact: Mine and the generated one via --air-save.


Thanks, that's very important and hints to a deeper bug. Thanks for the files too, we should have now all the elements to hunt the bug down in an effective way. If we need something else we will let you know, and anyway we are going to keep you posted.

Kind regards
 

Share this post


Link to post

I think none of this has any relevance to the problem in Bluetit/Goldcrest. I strongly consider it a software issue.

  • DTAG DSL, the landline internet, still uses the usual dual-stack operation wherein every router gets one public v4 and one v6 /56 prefix. And I definitively would've noticed a change here if I ever got a v6 prefix only, which seems to be the indicator for 464-XLAT. But no, DHCPv4 assigns a public v4 to the router.
  • Telekom Mobile on the other hand started experimenting with 464-XLAT in 2018 and rolled it out productively in January this year. It's something only Android needs because Apple requires store apps to be capable of using v6, so no need for CLAT there.
Didn't need to ask them – they answer it themselves (German).

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post
@OpenSourcerer

Thanks, that simplifies things because we can test in the same environment you have with your landline provider.

EDIT: do you get the same problem both from Arch and Debian 10?

Kind regards
 

Share this post


Link to post

Hello!

We're very glad to inform you that AirVPN Suite 1.0.0 RC 1 for Linux has just been released. It addresses all the problems reported so far, except:

  • problems reported in unstable distributions but not occurring in the same distribution stable release
  • the specific problem reported by @OpenSourcerer as we failed to reproduce it: please report if you find anything similar to what OpenSourcerer has reported because we can't manage to reproduce the malfunction in spite of very many efforts
Links to download packages have been updated in the first message of this thread.

Kind regards
 

Share this post


Link to post
3 hours ago, Staff said:

the specific problem reported by @OpenSourcerer as we failed to reproduce it: please report if you find anything similar to what OpenSourcerer has reported because we can't manage to reproduce the malfunction in spite of very many efforts 


I found the problem. It was invisible to you because I redacted that info for privacy: Try a key name with a space in it… :)
Now the interesting thing is: Does this also happen to passwords containing spaces?…

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post
On 12/12/2020 at 12:20 PM, colorman said:

I have two issues, first when I quit goldcrest with Ctrl-C, it hangs and won't go back to **** @ localhost: / usr / local / bin>

2020-12-12 12:16:48 EVENT: DISCONNECTED
2020-12-12 12:16:48 Successfully restored DNS settings
2020-12-12 12:16:48 Network filter successfully restored
2020-12-12 12:16:48 VPN session terminated


Second, when I shut down the console and then want to restart the console to log in to goldcrest I get this, (restart need)

****@localhost:~> cd /usr/local/bin                                  
****@localhost:/usr/local/bin> ./goldcrest AirVPN_Netherlands_TCP-443-Entry3.ovpn
2020-12-12 12:17:51 Reading run control directives from file /home/****/.config/goldcrest.rc
Goldcrest 1.0.0 Beta 3 - 11 December 2020

2020-12-12 12:17:51 DBusConnectorException: DBusConnector: not primary owner (2)
****@localhost:/usr/local/bin>

 

This problem not solved in AirVPN Suite 1.0.0 RC 1 for Linux.
Or am I doing something wrong?

Share this post


Link to post
13 hours ago, OpenSourcerer said:

I found the problem. It was invisible to you because I redacted that info for privacy: Try a key name with a space in it… :)
Now the interesting thing is: Does this also happen to passwords containing spaces?…

Hello!

Space, by default, is one of the internal field separators in any shell, together with tab and newline. If you need a space in any option argument, and you have the space as IFS, you must enclose the argument in double quotes, either in the command line or in a configuration file. It will happen with any argument of course, so passwords too, nothing interesting here.

Therefore, the behavior is correct and expected, and we were hunting fairies for days. However, if you already enclose the arguments in double quotes and/or you have modified your IFS environment variable to NOT consider space as an IFS, then the problem is real. We can archive the issue.now unless you tell that there's a match with one of the the mentioned cases.

Kind regards
 

Share this post


Link to post
1 minute ago, Staff said:

However, if you already enclose the arguments in double quotes and/or you have modified your IFS environment variable to NOT consider space as an IFS, then the problem is real. We can archive the issue.now unless you tell that there's a match with one of the the mentioned cases.


That's what I was getting at, escaping it doesn't work. I tried " ", ' ', \, _ and without space, the entry is read as-is. Log output of one try below. If I input MyKey, the log reads "Key MyKey does not exist for user opensourcerer", which is true because the key is called My Key. "My Key", 'My Key', My\ Key and My_Key are printed with the special characters, too.

[…]
2020-12-24 11:34:06 ERROR: Key "My Key" does not exist for user opensourcerer
[…]


I have not configured anything IFS, the variable is not set anywhere.

Don't know why it worked before. Maybe you broke it when implementing the truthy/falsy value parsing?

NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post
@colorman

Hello!

Thanks, we will re-open the investigation on the issue (we remember you reported it identically weeks ago and we thought it was addressed - something must have gone wrong). Can you confirm that your distribution is openSUSE 15.2?

Kind regards
 

Share this post


Link to post
@OpenSourcerer

Hello!

The following line is puzzling as we can't reproduce it:
 
2020-12-24 11:34:06 ERROR: Key "My Key" does not exist for user opensourcerer

unless of course you typed
 
\"My\ Key\"



which is not the case, we guess. Very puzzling indeed. Can you send us the content of your IFS variable, just in case, and make sure to run Goldcrest from the very same account you print IFS content from (running Goldcrest as root is unnecessary and deprecated anyway)? Maybe it will help shed some light.
 
od -abc <<<"$IFS"

We are looking forward to hearing from you.

Kind regards
 

Share this post


Link to post
1 hour ago, Staff said:
@colorman

Hello!

Thanks, we will re-open the investigation on the issue (we remember you reported it identically weeks ago and we thought it was addressed - something must have gone wrong). Can you confirm that your distribution is openSUSE 15.2?

Kind regards
 
Operating System: openSUSE Leap 15.2
KDE Plasma Version: 5.18.6
KDE Frameworks Version: 5.71.0
Qt Version: 5.12.7
Kernel Version: 5.3.18-lp152.57-preempt
OS Type: 64-bit
Processors: 8 × AMD Ryzen 5 3400G with Radeon Vega Graphics
Memory: 15,3 GiB

In the first and second beta, I didn't have this problem.

 

Share this post


Link to post
@colorman

Hello!

Can you please send us Bleutit log taken after the shell does not give you back the prompt when you stop Goldcrest with CTRL-C, and when you get the DBusConnectorException: DBusConnector: not primary owner (2) error?

In both cases, from a terminal:
sudo journalctl | grep bluetit

Thank you in advance.

Kind regards
 

Share this post


Link to post
1 hour ago, Staff said:
@colorman

Hello!

Can you please send us Bleutit log taken after the shell does not give you back the prompt when you stop Goldcrest with CTRL-C, and when you get the DBusConnectorException: DBusConnector: not primary owner (2) error?

In both cases, from a terminal:

sudo journalctl | grep bluetit

Thank you in advance.

Kind regards
 

localhost:~ # journalctl | grep bluetit
Dec 24 17:48:15 localhost bluetit[1165]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.0.0 Beta 1 - 18 November 2020
Dec 24 17:48:15 localhost bluetit[1165]: OpenVPN core 3.6.6 AirVPN linux x86_64 64-bit
Dec 24 17:48:15 localhost bluetit[1165]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
Dec 24 17:48:15 localhost bluetit[1213]: Bluetit daemon started with PID 1213
Dec 24 17:48:15 localhost bluetit[1213]: Successfully connected to D-Bus
Dec 24 17:48:15 localhost bluetit[1213]: Reading run control directives from file /etc/airvpn/bluetit.rc
Dec 24 17:48:15 localhost bluetit[1213]: IPv6 is not available in this system

Dec 24 17:48:15 localhost bluetit[1213]: Bluetit successfully initialized and ready

Dec 24 17:48:15 localhost bluetit[1213]: AirVPN Manifest updater thread started
Dec 24 17:48:15 localhost bluetit[1213]: AirVPN Manifest update interval is 15 minutes
Dec 24 17:48:15 localhost bluetit[1213]: Updating AirVPN Manifest
Dec 24 17:48:15 localhost bluetit[1213]: AirVPN Manifest successfully retrieved from server
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "version"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "openvpn_info"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "bluetit_status -> Bluetit is ready"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "reset_bluetit_options -> Bluetit options successfully reset"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "set_openvpn_profile -> OK"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "start_connection"
Dec 24 17:48:53 localhost bluetit[1213]: OpenVPN3 client successfully created and initialized.
Dec 24 17:48:53 localhost bluetit[1213]: Successfully set OpenVPN3 client configuration
Dec 24 17:48:53 localhost bluetit[1213]: Starting OpenVPN3 connection thread
Dec 24 17:48:53 localhost bluetit[1213]: OpenVPN3 connection successfully started
Dec 24 17:48:53 localhost bluetit[1213]: OpenVPN core 3.6.6 AirVPN linux x86_64 64-bit
Dec 24 17:48:53 localhost bluetit[1213]: Frame=512/2048/512 mssfix-ctrl=1250
Dec 24 17:48:53 localhost bluetit[1213]: UNUSED OPTIONS
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: RESOLVE
Dec 24 17:48:53 localhost bluetit[1213]: Network filter and lock is using iptables-legacy
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_filter
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_nat
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_mangle
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_security
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_raw
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_filter
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_nat
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_mangle
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_security
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_raw
Dec 24 17:48:53 localhost bluetit[1213]: WARNING: firewalld is running on this system and may interfere with network filter and lock
Dec 24 17:48:53 localhost bluetit[1213]: Network filter successfully initialized
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv4 address 192.168.178.11
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv6 address 2001:1c04:3a18:0:4986:c702:8e01:fbe6
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv6 address 2001:1c04:3a18:0:aaa1:59ff:fe2f:523e
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv6 address fe80::aaa1:59ff:fe2f:523e
Dec 24 17:48:53 localhost bluetit[1213]: Local interface eth0
Dec 24 17:48:53 localhost bluetit[1213]: Setting up network filter and lock
Dec 24 17:48:53 localhost bluetit[1213]: Allowing system DNS 84.116.46.20 to pass through the network filter
Dec 24 17:48:53 localhost bluetit[1213]: Allowing system DNS 84.116.46.21 to pass through the network filter
Dec 24 17:48:53 localhost bluetit[1213]: Resolved server nl3.vpn.airdns.org into IPv4 109.202.107.12
Dec 24 17:48:53 localhost bluetit[1213]: Adding IPv4 server 109.202.107.12 to network filter
Dec 24 17:48:53 localhost bluetit[1213]: Network filter and lock successfully activated
Dec 24 17:48:53 localhost bluetit[1213]: Contacting 109.202.107.12:443 via TCPv4
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: WAIT
Dec 24 17:48:53 localhost bluetit[1213]: net_route_best_gw query IPv4: 109.202.107.12/32
Dec 24 17:48:53 localhost bluetit[1213]: sitnl_route_best_gw result: via 192.168.178.1 dev eth0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 109.202.107.12/32 via 192.168.178.1 dev eth0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: Connecting to [nl3.vpn.airdns.org]:443 (109.202.107.12) via TCPv4
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: CONNECTING
Dec 24 17:48:53 localhost bluetit[1213]: Tunnel Options:V4,dev-type tun,link-mtu 1604,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-
256-CBC,auth SHA512,keysize 256,key-method 2,tls-client
Dec 24 17:48:53 localhost bluetit[1213]: Creds: UsernameEmpty/PasswordEmpty
Dec 24 17:48:53 localhost bluetit[1213]: Peer Info:
Dec 24 17:48:53 localhost bluetit[1213]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.
org, signature: RSA-SHA1
Dec 24 17:48:53 localhost bluetit[1213]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Alphard/emailAddress=info@airvpn.org, s
ignature: RSA-SHA512
Dec 24 17:48:53 localhost bluetit[1213]: SSL Handshake: peer certificate: CN=Alphard, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 T
LSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
Dec 24 17:48:53 localhost bluetit[1213]: Session is ACTIVE
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: WARN TLS: received certificate signed with SHA1. Please inform your admin to upgrade to a
stronger algorithm. Support for SHA1 signatures will be dropped in the future
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: GET_CONFIG
Dec 24 17:48:53 localhost bluetit[1213]: Sending PUSH_REQUEST to server...
Dec 24 17:48:53 localhost bluetit[1213]: OPTIONS:
Dec 24 17:48:53 localhost bluetit[1213]: PROTOCOL OPTIONS:
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: ASSIGN_IP
Dec 24 17:48:53 localhost bluetit[1213]: VPN Server has pushed IPv4 DNS server 10.7.47.1
Dec 24 17:48:53 localhost bluetit[1213]: Setting pushed IPv4 DNS server 10.7.47.1 in resolv.conf
Dec 24 17:48:53 localhost bluetit[1213]: VPN Server has pushed IPv6 DNS server fde6:7a:7d20:32f::1
Dec 24 17:48:53 localhost bluetit[1213]: Setting pushed IPv6 DNS server fde6:7a:7d20:32f::1 in resolv.conf
Dec 24 17:48:53 localhost bluetit[1213]: net_iface_mtu_set: mtu 1500 for tun0
Dec 24 17:48:53 localhost bluetit[1213]: net_iface_up: set tun0 up
Dec 24 17:48:53 localhost bluetit[1213]: net_addr_add: 10.7.47.34/24 brd 10.7.47.255 dev tun0
Dec 24 17:48:53 localhost bluetit[1213]: net_addr_add: fde6:7a:7d20:32f::1020/64 dev tun0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 0.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 128.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: ::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 8000::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: Connected via tun
Dec 24 17:48:53 localhost bluetit[1213]: LZO-ASYM init swap=0 asym=1
Dec 24 17:48:53 localhost bluetit[1213]: Comp-stub init swap=0
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: CONNECTED nl3.vpn.airdns.org:443 (109.202.107.12) via /TCPv4 on tun/10.7.47.34/fde6:7a:7d2
0:32f::1020 gw=[10.7.47.1/fde6:7a:7d20:32f::1]
Dec 24 17:48:53 localhost bluetit[1213]: Server has pushed its own DNS. Removing system DNS from network filter.
Dec 24 17:48:53 localhost bluetit[1213]: System DNS 84.116.46.20 is now rejected by the network filter
Dec 24 17:48:53 localhost bluetit[1213]: System DNS 84.116.46.21 is now rejected by the network filter
Dec 24 17:49:51 localhost bluetit[1213]: Requested method "bluetit_status -> Bluetit is connected to VPN"
Dec 24 17:49:51 localhost bluetit[1213]: Requested method "stop_connection"
Dec 24 17:49:51 localhost bluetit[1213]: Stopping OpenVPN3 connection thread
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 8000::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: ::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 128.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 0.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_addr_del: fde6:7a:7d20:32f::1020/64 dev tun0
Dec 24 17:49:51 localhost bluetit[1213]: net_addr_del: 10.7.47.34/24 dev tun0
Dec 24 17:49:51 localhost bluetit[1213]: net_iface_mtu_set: mtu 1500 for tun0
Dec 24 17:49:51 localhost bluetit[1213]: net_iface_up: set tun0 down
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 109.202.107.12/32 via 192.168.178.1 dev eth0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: EVENT: DISCONNECTED
Dec 24 17:49:51 localhost bluetit[1213]: Successfully restored DNS settings
Dec 24 17:49:51 localhost bluetit[1213]: Network filter successfully restored
Dec 24 17:49:51 localhost bluetit[1213]: VPN session terminated
Dec 24 17:49:51 localhost bluetit[1213]: OpenVPN3 connection thread finished
Dec 24 17:49:51 localhost bluetit[1213]: OpenVPN3 connection thread successfully terminated
Dec 24 17:49:51 localhost dbus-daemon[1174]: [system] Rejected send message, 3 matched rules; type="error", sender=":1.75" (uid=1000 pid=4
647 comm="./goldcrest AirVPN_Netherlands_TCP-443-Entry3.ovpn") interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error
.UnknownMethod" requested_reply="0" destination=":1.1" (uid=0 pid=1213 comm="/sbin/bluetit ")
localhost:~ #


localhost:~ # journalctl | grep bluetit
Dec 24 17:48:15 localhost bluetit[1165]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.0.0 Beta 1 - 18 November 2020
Dec 24 17:48:15 localhost bluetit[1165]: OpenVPN core 3.6.6 AirVPN linux x86_64 64-bit
Dec 24 17:48:15 localhost bluetit[1165]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
Dec 24 17:48:15 localhost bluetit[1213]: Bluetit daemon started with PID 1213
Dec 24 17:48:15 localhost bluetit[1213]: Successfully connected to D-Bus
Dec 24 17:48:15 localhost bluetit[1213]: Reading run control directives from file /etc/airvpn/bluetit.rc
Dec 24 17:48:15 localhost bluetit[1213]: IPv6 is not available in this system
Dec 24 17:48:15 localhost bluetit[1213]: Bluetit successfully initialized and ready
Dec 24 17:48:15 localhost bluetit[1213]: AirVPN Manifest updater thread started
Dec 24 17:48:15 localhost bluetit[1213]: AirVPN Manifest update interval is 15 minutes
Dec 24 17:48:15 localhost bluetit[1213]: Updating AirVPN Manifest
Dec 24 17:48:15 localhost bluetit[1213]: AirVPN Manifest successfully retrieved from server
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "version"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "openvpn_info"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "bluetit_status -> Bluetit is ready"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "reset_bluetit_options -> Bluetit options successfully reset"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "set_openvpn_profile -> OK"
Dec 24 17:48:53 localhost bluetit[1213]: Requested method "start_connection"
Dec 24 17:48:53 localhost bluetit[1213]: OpenVPN3 client successfully created and initialized.
Dec 24 17:48:53 localhost bluetit[1213]: Successfully set OpenVPN3 client configuration
Dec 24 17:48:53 localhost bluetit[1213]: Starting OpenVPN3 connection thread
Dec 24 17:48:53 localhost bluetit[1213]: OpenVPN3 connection successfully started
Dec 24 17:48:53 localhost bluetit[1213]: OpenVPN core 3.6.6 AirVPN linux x86_64 64-bit
Dec 24 17:48:53 localhost bluetit[1213]: Frame=512/2048/512 mssfix-ctrl=1250
Dec 24 17:48:53 localhost bluetit[1213]: UNUSED OPTIONS
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: RESOLVE
Dec 24 17:48:53 localhost bluetit[1213]: Network filter and lock is using iptables-legacy
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_filter
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_nat
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_mangle
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_security
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module iptable_raw
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_filter
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_nat
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_mangle
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_security
Dec 24 17:48:53 localhost bluetit[1213]: Successfully loaded kernel module ip6table_raw
Dec 24 17:48:53 localhost bluetit[1213]: WARNING: firewalld is running on this system and may interfere with network filter and lock
Dec 24 17:48:53 localhost bluetit[1213]: Network filter successfully initialized
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv4 address 192.168.178.11
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv6 address 2001:1c04:3a18:0:4986:c702:8e01:fbe6
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv6 address 2001:1c04:3a18:0:aaa1:59ff:fe2f:523e
Dec 24 17:48:53 localhost bluetit[1213]: Local IPv6 address fe80::aaa1:59ff:fe2f:523e
Dec 24 17:48:53 localhost bluetit[1213]: Local interface eth0
Dec 24 17:48:53 localhost bluetit[1213]: Setting up network filter and lock
Dec 24 17:48:53 localhost bluetit[1213]: Allowing system DNS 84.116.46.20 to pass through the network filter
Dec 24 17:48:53 localhost bluetit[1213]: Allowing system DNS 84.116.46.21 to pass through the network filter
Dec 24 17:48:53 localhost bluetit[1213]: Resolved server nl3.vpn.airdns.org into IPv4 109.202.107.12
Dec 24 17:48:53 localhost bluetit[1213]: Adding IPv4 server 109.202.107.12 to network filter
Dec 24 17:48:53 localhost bluetit[1213]: Network filter and lock successfully activated
Dec 24 17:48:53 localhost bluetit[1213]: Contacting 109.202.107.12:443 via TCPv4
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: WAIT
Dec 24 17:48:53 localhost bluetit[1213]: net_route_best_gw query IPv4: 109.202.107.12/32
Dec 24 17:48:53 localhost bluetit[1213]: sitnl_route_best_gw result: via 192.168.178.1 dev eth0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 109.202.107.12/32 via 192.168.178.1 dev eth0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: Connecting to [nl3.vpn.airdns.org]:443 (109.202.107.12) via TCPv4
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: CONNECTING
Dec 24 17:48:53 localhost bluetit[1213]: Tunnel Options:V4,dev-type tun,link-mtu 1604,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-
256-CBC,auth SHA512,keysize 256,key-method 2,tls-client
Dec 24 17:48:53 localhost bluetit[1213]: Creds: UsernameEmpty/PasswordEmpty
Dec 24 17:48:53 localhost bluetit[1213]: Peer Info:
Dec 24 17:48:53 localhost bluetit[1213]: VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.
org, signature: RSA-SHA1
Dec 24 17:48:53 localhost bluetit[1213]: VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Alphard/emailAddress=info@airvpn.org, s
ignature: RSA-SHA512
Dec 24 17:48:53 localhost bluetit[1213]: SSL Handshake: peer certificate: CN=Alphard, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 T
LSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
Dec 24 17:48:53 localhost bluetit[1213]: Session is ACTIVE
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: WARN TLS: received certificate signed with SHA1. Please inform your admin to upgrade to a
stronger algorithm. Support for SHA1 signatures will be dropped in the future
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: GET_CONFIG
Dec 24 17:48:53 localhost bluetit[1213]: Sending PUSH_REQUEST to server...
Dec 24 17:48:53 localhost bluetit[1213]: OPTIONS:
Dec 24 17:48:53 localhost bluetit[1213]: PROTOCOL OPTIONS:
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: ASSIGN_IP
Dec 24 17:48:53 localhost bluetit[1213]: VPN Server has pushed IPv4 DNS server 10.7.47.1
Dec 24 17:48:53 localhost bluetit[1213]: Setting pushed IPv4 DNS server 10.7.47.1 in resolv.conf
Dec 24 17:48:53 localhost bluetit[1213]: VPN Server has pushed IPv6 DNS server fde6:7a:7d20:32f::1
Dec 24 17:48:53 localhost bluetit[1213]: Setting pushed IPv6 DNS server fde6:7a:7d20:32f::1 in resolv.conf
Dec 24 17:48:53 localhost bluetit[1213]: net_iface_mtu_set: mtu 1500 for tun0
Dec 24 17:48:53 localhost bluetit[1213]: net_iface_up: set tun0 up
Dec 24 17:48:53 localhost bluetit[1213]: net_addr_add: 10.7.47.34/24 brd 10.7.47.255 dev tun0
Dec 24 17:48:53 localhost bluetit[1213]: net_addr_add: fde6:7a:7d20:32f::1020/64 dev tun0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 0.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 128.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: ::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: net_route_add: 8000::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:48:53 localhost bluetit[1213]: Connected via tun
Dec 24 17:48:53 localhost bluetit[1213]: LZO-ASYM init swap=0 asym=1
Dec 24 17:48:53 localhost bluetit[1213]: Comp-stub init swap=0
Dec 24 17:48:53 localhost bluetit[1213]: EVENT: CONNECTED nl3.vpn.airdns.org:443 (109.202.107.12) via /TCPv4 on tun/10.7.47.34/fde6:7a:7d2
0:32f::1020 gw=[10.7.47.1/fde6:7a:7d20:32f::1]
Dec 24 17:48:53 localhost bluetit[1213]: Server has pushed its own DNS. Removing system DNS from network filter.
Dec 24 17:48:53 localhost bluetit[1213]: System DNS 84.116.46.20 is now rejected by the network filter
Dec 24 17:48:53 localhost bluetit[1213]: System DNS 84.116.46.21 is now rejected by the network filter
Dec 24 17:49:51 localhost bluetit[1213]: Requested method "bluetit_status -> Bluetit is connected to VPN"
Dec 24 17:49:51 localhost bluetit[1213]: Requested method "stop_connection"
Dec 24 17:49:51 localhost bluetit[1213]: Stopping OpenVPN3 connection thread
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 8000::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: ::/1 via fde6:7a:7d20:32f::1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 128.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 0.0.0.0/1 via 10.7.47.1 dev tun0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: net_addr_del: fde6:7a:7d20:32f::1020/64 dev tun0
Dec 24 17:49:51 localhost bluetit[1213]: net_addr_del: 10.7.47.34/24 dev tun0
Dec 24 17:49:51 localhost bluetit[1213]: net_iface_mtu_set: mtu 1500 for tun0
Dec 24 17:49:51 localhost bluetit[1213]: net_iface_up: set tun0 down
Dec 24 17:49:51 localhost bluetit[1213]: net_route_del: 109.202.107.12/32 via 192.168.178.1 dev eth0 table 0 metric 0
Dec 24 17:49:51 localhost bluetit[1213]: EVENT: DISCONNECTED
Dec 24 17:49:51 localhost bluetit[1213]: Successfully restored DNS settings
Dec 24 17:49:51 localhost bluetit[1213]: Network filter successfully restored
Dec 24 17:49:51 localhost bluetit[1213]: VPN session terminated
Dec 24 17:49:51 localhost bluetit[1213]: OpenVPN3 connection thread finished
Dec 24 17:49:51 localhost bluetit[1213]: OpenVPN3 connection thread successfully terminated
Dec 24 17:49:51 localhost dbus-daemon[1174]: [system] Rejected send message, 3 matched rules; type="error", sender=":1.75" (uid=1000 pid=4
647 comm="./goldcrest AirVPN_Netherlands_TCP-443-Entry3.ovpn") interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error
.UnknownMethod" requested_reply="0" destination=":1.1" (uid=0 pid=1213 comm="/sbin/bluetit ")
localhost:~ #


 

Share this post


Link to post
@colorman

Hello!

 
Quote
Dec 24 17:48:15 localhost bluetit[1165]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.0.0 Beta 1 - 18 November 2020


Can you please upgrade to 1.0.0 RC 1? Check the links in this thread first message.
 
Quote


In the first and second beta, I didn't have this problem.


Also, can you please clarify which version did not have this problem in your machine? You're still running Bluetit version 1.0.0 beta 1... after that, beta 2, beta 3 and RC 1 have come out. Feel free to elaborate.

Anyway, you're running Bluetit beta 1 and Goldcrest beta 3. Goldcrest beta 3 expects new messages (D-Bus comms have been improved with beta 3), that did not exist in Bluetit beta 1.

Jump directly to RC 1 (both Bluetit and Goldcrest, important) and check what happens, thanks!

We are looking forward to hearing from you.

Kind regards
 

Share this post


Link to post

Sorry, did not see that 🙄
Very strange, have really updated.
First done an uninstall and reinstalled.
Now good version, see log.
And the problems are solved.

I think it went wrong after update to beta 3

2020-12-25 07:52:00 EVENT: DISCONNECTED
2020-12-25 07:52:00 Successfully restored DNS settings
2020-12-25 07:52:00 Network filter successfully restored
2020-12-25 07:52:00 VPN session terminated
gerrit@localhost:/usr/local/bin>


localhost:~ # journalctl | grep bluetit
Dec 25 07:50:22 localhost bluetit[1137]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.0.0 RC 1 - 22 December 2020
Dec 25 07:50:22 localhost bluetit[1137]: OpenVPN core 3.6.6 AirVPN linux x86_64 64-bit
Dec 25 07:50:22 localhost bluetit[1137]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
Dec 25 07:50:22 localhost bluetit[1153]: Bluetit daemon started with PID 1153
Dec 25 07:50:22 localhost bluetit[1153]: Successfully connected to D-Bus
Dec 25 07:50:22 localhost bluetit[1153]: Reading run control directives from file /etc/airvpn/bluetit.rc
Dec 25 07:50:22 localhost bluetit[1153]: IPv6 is not available in this system
Dec 25 07:50:22 localhost bluetit[1153]: Bluetit successfully initialized and ready
Dec 25 07:50:22 localhost bluetit[1153]: AirVPN Manifest updater thread started

Share this post


Link to post
22 hours ago, Staff said:

Can you send us the content of your IFS variable, just in case, and make sure to run Goldcrest from the very same account you print IFS content from


od outputs the following for both my user and root:

$ od -abc <<<"$IFS"
0000000  sp  ht  nl  nl
        040 011 012 012
             \t  \n  \n
0000004

.
22 hours ago, Staff said:

unless of course you typed


If I type this, goldcrest/bluetit take the value literally like before:

[…]
2020-12-25 11:22:31 ERROR: Key \"My\ Key\" does not exist for user opensourcerer
[…]


NOT AN AIRVPN TEAM MEMBER. USE TICKETS FOR PROFESSIONAL SUPPORT.

LZ1's New User Guide to AirVPN « Plenty of stuff for advanced users, too!

Want to contact me directly? All relevant methods are on my About me page.

Share this post


Link to post

Dell XPS 9365 13"  Fedora 33 Cinnamon installed into an external, portable Seagate Expansion 4TB USB 3 hdd.  AirVPN Hummingbird install

[noddy@localhost ~]$ su
Password:
[root@localhost noddy]# cd AirVPN-Suite
[root@localhost AirVPN-Suite]# ldd bin/bluetit
    linux-vdso.so.1 (0x00007ffd4f65d000)
    libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007fcdd35f0000)
    libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fcdd3465000)
    libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fcdd33c9000)
    libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fcdd30dc000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fcdd30d5000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fcdd2eed000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fcdd2da5000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcdd2d8a000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcdd2d68000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fcdd2b9d000)
    libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007fcdd2add000)
    libz.so.1 => /lib64/libz.so.1 (0x00007fcdd2ac3000)
    liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fcdd2a95000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcdd3c31000)
    librt.so.1 => /lib64/librt.so.1 (0x00007fcdd2a8a000)
    libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fcdd29b5000)
    liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fcdd2997000)
    libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fcdd2872000)
    libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fcdd284b000)
[root@localhost AirVPN-Suite]# ldd bin/goldcrest
    linux-vdso.so.1 (0x00007ffd8e6fe000)
    libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f689c210000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f689c1ee000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f689c006000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f689bec0000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f689bea5000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f689bcda000)
    libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f689bc18000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f689c49d000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f689bc0d000)
    liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f689bbe1000)
    libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f689bb0c000)
    liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f689baee000)
    libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f689b9c9000)
    libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f689b9a2000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f689b99b000)
[root@localhost AirVPN-Suite]# ldd bin/hummingbird
    linux-vdso.so.1 (0x00007ffc4b189000)
    libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f518b6f7000)
    libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f518b40a000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f518b403000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f518b21b000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f518b0d5000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f518b0ba000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f518b096000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f518aecb000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f518aeb1000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f518bd24000)
[root@localhost AirVPN-Suite]# sh ./install.sh

AirVPN suite installation script

Do you want to install AirVPN Suite? [y/n] y

System is using systemd

Installing bluetit to /sbin
Installing goldcrest to /usr/local/bin
Installing hummingbird to /usr/local/bin
Installing bluetit configuration files
Installing D-Bus configuration files
Installing systemd bluetit.service unit

Do you want to enable bluetit.service unit? [y/n] y
Created symlink /etc/systemd/system/multi-user.target.wants/bluetit.service → /etc/systemd/system/bluetit.service.
Bluetit service enabled

Do you want to start Bluetit service now? [y/n] y
Bluetit service started

Do you want to create airvpn user? [y/n] y
y
Please set a password for user airvpn
Changing password for user airvpn.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

User airvpn added to group airvpn

Done.
[root@localhost AirVPN-Suite]# dnf upgrade
Last metadata expiration check: 1:31:31 ago on Sat 26 Dec 2020 12:58:27.
Dependencies resolved.
Nothing to do.
Complete!
[root@localhost AirVPN-Suite]#
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Note about Hummingbird & SELinux-use Bluetit daemon & to control it by using one of its clients, such as Goldcrest. In case the user wants to run
Hummingbird from a systemd unit and the system has SELinux.  

Not sure how to deal with this?   tks



 

Share this post


Link to post
On 12/23/2020 at 5:16 PM, Staff said:

@staff
Hello

Quote :

We're very glad to inform you that AirVPN Suite 1.0.0 RC 1 for Linux has just been released. It addresses all the problems reported so far, except:

  • problems reported in unstable distributions but not occurring in the same distribution stable release
  •  




For the record I still have to restart bluetit.rc as per my previous messages before I can get goldcrest to work.

From your exception described above, as I run debian unstable, does that mean that my problem cannot be solved , but it would run ok without needing a restart in debian stable ?

thanks as always
regards
 

Share this post


Link to post
@pjnsmb

Hello!

Yes, it runs fine in Debian stable releases. Momentarily, problems occurring in unstable distributions are not addressed, but that does not mean that they won't be addressed in the future. Furthermore, it is also possible that problems get resolved in time, while unstable distribution bugs are resolved.

Kind regards
 

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...