DietPi-Banner | Show warning on installed<>loaded kernel mismatch

[Camry2731]

Creating a bug report/issue

Required Information

• DietPi version | 7.5.2
• Distro version | Bullseye
• Kernel version | Linux DietPi 5.10.52-v8+
• SBC model | RPi 4 Model B (aarch64)
• Power supply used | CanaKit Power Supply
• SDcard used | Samsung 64GB

Additional Information (if applicable)

• Software title | DietPi-VPN
• Was the software title installed freshly or updated/migrated? | Fresh
• Can this issue be replicated on a fresh installation of DietPi? | Yes

• Bug report ID | 00629356-8cf8-4500-a9ab-486b31857f8f

Steps to reproduce

1. Select DietPi-VPN
2. Select IPVanish
3. Input username and password
4. Select either UDP or TCP
5. Connect to server
6. Fails (Connection failed/timeout)

Expected behaviour

1. Follow steps 1-5
2. Connects to server

Actual behaviour

1. Follow steps 1-5
2. Not connecting to server

Extra details

• I have triple checked that all login info is correct. I have tried multiple servers, both UDP and TCP. I have reinstalled the image. Nothing seems to be working. I have skimmed the current and past bug reports but don't see anything on this issue. Upon typing systemctl -l status dietpi-vpn I get this error:

dietpi-vpn.service - VPN Client (DietPi)
     Loaded: loaded (/etc/systemd/system/dietpi-vpn.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2021-09-13 01:53:31 EDT; 1min 4s ago
    Process: 28625 ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config /etc/openvpn/client.ovpn (code=exited, status=1/FAILURE)
   Main PID: 28625 (code=exited, status=1/FAILURE)
     Status: "Pre-connection initialization successful"
        CPU: 97ms

NCP: overriding user-set keysize with default
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
DietPi openvpn[28625]: net_route_v4_best_gw query: dst 0.0.0.0
DietPi openvpn[28625]: net_route_v4_best_gw result: via 192.168.50.1 dev eth0
DietPi openvpn[28625]: ROUTE_GATEWAY 192.168.50.1/255.255.255.0 IFACE=eth0 HWADDR=XX:XX:XX:XX:XX:XX
DietPi openvpn[28625]: ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
DietPi openvpn[28625]: Exiting due to fatal error
DietPi systemd[1]: dietpi-vpn.service: Main process exited, code=exited, status=1/FAILURE
DietPi systemd[1]: dietpi-vpn.service: Failed with result 'exit-code'.

[MichaIng]

Many thanks for your report.

Can you please show the whole output of the service:

journalctl -u dietpi-vpn

Of course mask any identifying elements, like public IPs or MAC addresses. Also can you show:

cat /etc/openvpn/client.ovpn

to see whether port and protocol changes have been applied as expected.

[Camry2731]

Alright, sorry for the delay, here is the log of journalctl -u dietpi-vpn with identifying elements removed

Sep 13 01:41:23 DietPi systemd[1]: Starting VPN Client (DietPi)...
Sep 13 01:41:23 DietPi openvpn[26227]: WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
Sep 13 01:41:23 DietPi openvpn[26227]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Sep 13 01:41:23 DietPi openvpn[26227]: WARNING: --keysize is DEPRECATED and will be removed in OpenVPN 2.6
Sep 13 01:41:23 DietPi openvpn[26227]: OpenVPN 2.5.1 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
Sep 13 01:41:23 DietPi openvpn[26227]: library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Sep 13 01:41:23 DietPi openvpn[26227]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 13 01:41:23 DietPi systemd[1]: Started VPN Client (DietPi).
Sep 13 01:41:23 DietPi openvpn[26227]: TCP/UDP: Preserving recently used remote address: [AF_INET]XXXXXXXXXXXXXXXXXX
Sep 13 01:41:23 DietPi openvpn[26227]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Sep 13 01:41:23 DietPi openvpn[26227]: UDP link local: (not bound)
Sep 13 01:41:23 DietPi openvpn[26227]: UDP link remote: [AF_INET]XXXXXXXXXXXXXXXXXX
Sep 13 01:41:23 DietPi openvpn[26227]: TLS: Initial packet from [AF_INET]XXXXXXXXXXXXXXXXXX, sid=0011a2fe 55e43b73
Sep 13 01:41:23 DietPi openvpn[26227]: VERIFY OK: depth=1, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=IPVanish CA, [email protected]
Sep 13 01:41:23 DietPi openvpn[26227]: VERIFY X509NAME OK: C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=iad-a37.ipvanish.com, [email protected]
Sep 13 01:41:23 DietPi openvpn[26227]: VERIFY OK: depth=0, C=US, ST=FL, L=Winter Park, O=IPVanish, OU=IPVanish VPN, CN=iad-a37.ipvanish.com, [email protected]
Sep 13 01:41:23 DietPi openvpn[26227]: Control Channel: TLSv1.2, cipher SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sep 13 01:41:23 DietPi openvpn[26227]: [iad-a37.ipvanish.com] Peer Connection Initiated with [AF_INET]XXXXXXXXXXXXXXXXXX
Sep 13 01:41:24 DietPi openvpn[26227]: SENT CONTROL [iad-a37.ipvanish.com]: 'PUSH_REQUEST' (status=1)
Sep 13 01:41:24 DietPi openvpn[26227]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 198.18.0.1,dhcp-option DNS 198.18.0.2,rcvbuf 493216,sndbuf 493216,explicit-exit-notify 5,comp-lzo no,route-gateway XXXXXXXXXXXXXXXXXX,topology subnet,ping 20,ping-restart 40,ifconfig XXXXXXXXXXXXXXXXXX 255.255.254.0,peer-id 0,cipher AES-256-GCM'
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: timers and/or timeouts modified
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: explicit notify parm(s) modified
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: compression parms modified
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sep 13 01:41:24 DietPi openvpn[26227]: Socket Buffers: R=[212992->425984] S=[212992->425984]
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: --ifconfig/up options modified
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: route options modified
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: route-related options modified
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: peer-id set
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: adjusting link_mtu to 1625
Sep 13 01:41:24 DietPi openvpn[26227]: OPTIONS IMPORT: data channel crypto options modified
Sep 13 01:41:24 DietPi openvpn[26227]: Data Channel: using negotiated cipher 'AES-256-GCM'
Sep 13 01:41:24 DietPi openvpn[26227]: NCP: overriding user-set keysize with default
Sep 13 01:41:24 DietPi openvpn[26227]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 13 01:41:24 DietPi openvpn[26227]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sep 13 01:41:24 DietPi openvpn[26227]: net_route_v4_best_gw query: dst 0.0.0.0
Sep 13 01:41:24 DietPi openvpn[26227]: net_route_v4_best_gw result: via 192.168.50.1 dev eth0
Sep 13 01:41:24 DietPi openvpn[26227]: ROUTE_GATEWAY 192.168.50.1/255.255.255.0 IFACE=eth0 HWADDR=XXXXXXXXXXXXXXXXXX
Sep 13 01:41:24 DietPi openvpn[26227]: ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
Sep 13 01:41:24 DietPi openvpn[26227]: Exiting due to fatal error
Sep 13 01:41:24 DietPi systemd[1]: dietpi-vpn.service: Main process exited, code=exited, status=1/FAILURE
Sep 13 01:41:24 DietPi systemd[1]: dietpi-vpn.service: Failed with result 'exit-code'.

And here is cat /etc/openvpn/client.ovpn

client
dev tun
proto udp
remote iad-a37.ipvanish.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
ca /etc/openvpn/ipvanish/ca.ipvanish.com.crt
verify-x509-name iad-a37.ipvanish.com name
auth-user-pass /var/lib/dietpi/dietpi-vpn/settings_ovpn.conf
comp-lzo
verb 3
auth SHA256
script-security 2
up /var/lib/dietpi/dietpi-vpn/static_up.sh
route-up /var/lib/dietpi/dietpi-vpn/up.sh
down /var/lib/dietpi/dietpi-vpn/static_down.sh
route-pre-down /var/lib/dietpi/dietpi-vpn/down.shcipher AES-256-CBC
keysize 256
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA

[MichaIng]

Good to know that some of the settings in the IPVanish configs are deprecated. A testing task when OpenVPN 2.6.x reaches Debian Bookworm.

I checked back and /dev/net/tun should be available automatically when the kernel module is loaded. Can you try to do that manually:

modprobe tun
ls -l /dev/net/tun

If there is some error, I recognised that your kernel version is not at latest version. Probably it has been upgraded already but reboot still outstanding to load it? When attempting to load a kernel module in such case, you'd see something like

modprobe: ERROR: Module tun not found.

and /lib/modules/5.10.52-v8+/kernel/drivers/net/tun.ko would not exist while /lib/modules/5.10.60-v8+/kernel/drivers/net/tun.ko does.

[Camry2731]

This is what I get when running the provided command

root@DietPi:~# modprobe tun
root@DietPi:~# ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 Sep 14 03:28 /dev/net/tun

[Camry2731]

Weird. So wiped and set back up the image again after re-downloading it, and I attempted it again and now it's working. I didn't change anything from the previous times so not sure what went different, but it seems to be working now. I appreciate the help as always. Maybe the image got corrupted somehow when I downloaded it the first time around?

[MichaIng]

Okay good that it works now. Now sure, probably for some reason OpenVPN did not loaded the tun module by itself. I'm not sure about the mechanisms, whether this is done as part of the OpenVPN internal startup process or automatically when one tries to touch certain kernel devices/tunables. Would have been interesting whether after the modprobe tun a systemctl restart dietpi-vpn would have succeeded already. Try this in case it happens a second time and if so, I'll have a closer look into how loading that module is supposed to work usually. We may even include that into the service itself, if required.

[Camry2731]

So I retested it as I swapped SD cards when I did the new image. I ran systemctl restart dietpi-vpn and it appears to be working. Odd behavior since I didn't have to do that the second time around with the other card.

[Camry2731]

At this point, maybe just keep an eye out if the issue reappears with others? Don't want you to waste time on something that isn't a problem and was just an anomaly on my end, lol.

[MichaIng]

At this point, maybe just keep an eye out if the issue reappears with others?

Definitely. I guess it was the kernel package upgrade indeed. Since this is quite a common issue, e.g. also with WireGuard, or the newly available Linux exFAT support autofs and others, I thought about showing a hint in the banner, like:

Your kernel got upgraded, please reboot your system to avoid module load failures!

The check whether loaded and installed kernel match:

[[ -d /lib/modules/$(uname -r) ]] || echo 'Kernel was upgraded'

[Joulinar]

I thought about showing a hint in the banner

That's actually quite a good idea. Could be same position as update notification

[MichaIng]

Found a way to detect whether we're running in a container, where /lib/modules/$(uname -r) naturally does not exist:

systemd-detect-virt -c

This way we can implement this warning nicely only for non-container systems. Will be done with next release.

[MichaIng]

The banner info is implemented here: #5299
It uses the same field where available DietPi and APT updates are shown, hence does not show up if such are available, but that should be fine, given that a DietPi update with this PR informs about the outstanding reboot and offers to perform it as well.