Hello,
Since upgrading my GL-AX1800 / Flint to Firmware 4.7.0, several OpenWrt (opkg) packages were missing for a while. However, many of the packages I need are now returning (though not all of them yet).
Recently, cryptsetup and its related packages, which are necessary for dm-crypt (encrypted storage), were finally released. This package was highly anticipated as I share dm-crypt/LUKS encrypted storage via Samba on my LAN.
However, when I tried to use it, most of cryptsetup's functions do not work.
root@META-Flint:~# lsblk /dev/sdc -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sdc
└─sdc1 crypto_LUKS a4d000c1-1b34-406d-a6e0-79695cdee6c2
root@META-Flint:~# cryptsetup luksOpen /dev/sdc1 luks-data
Cannot initialize crypto backend.
Device /dev/sdc1 is not a valid LUKS device.
root@META-Flint:~#
Even when running cryptsetup benchmark:
root@META-Flint:~# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
Cannot initialize crypto backend.
PBKDF2-sha1 N/A
Cannot initialize crypto backend.
PBKDF2-sha256 N/A
Cannot initialize crypto backend.
PBKDF2-sha512 N/A
Cannot initialize crypto backend.
PBKDF2-ripemd160 N/A
Cannot initialize crypto backend.
PBKDF2-whirlpool N/A
Cannot initialize crypto backend.
argon2i N/A
Cannot initialize crypto backend.
argon2id N/A
Cannot initialize crypto backend.
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b N/A N/A
Cannot initialize crypto backend.
serpent-cbc 128b N/A N/A
Cannot initialize crypto backend.
twofish-cbc 128b N/A N/A
Cannot initialize crypto backend.
aes-cbc 256b N/A N/A
Cannot initialize crypto backend.
serpent-cbc 256b N/A N/A
Cannot initialize crypto backend.
twofish-cbc 256b N/A N/A
Cannot initialize crypto backend.
aes-xts 256b N/A N/A
Cannot initialize crypto backend.
serpent-xts 256b N/A N/A
Cannot initialize crypto backend.
twofish-xts 256b N/A N/A
Cannot initialize crypto backend.
aes-xts 512b N/A N/A
Cannot initialize crypto backend.
serpent-xts 512b N/A N/A
Cannot initialize crypto backend.
twofish-xts 512b N/A N/A
root@META-Flint:~#
All the packages listed in the OpenWrt Wiki / Disk Encryption, namely kmod-crypto-ecb, kmod-crypto-xts, kmod-crypto-seqiv, kmod-crypto-misc, kmod-crypto-user and cryptsetup, are present and were correctly installed via opkg:
root@META-Flint:~# opkg list_installed | grep kmod-crypto
kmod-crypto-acompress - 5.4.164-1
kmod-crypto-aead - 5.4.164-1
kmod-crypto-cbc - 5.4.164-1
kmod-crypto-crc32c - 5.4.164-1
kmod-crypto-ecb - 5.4.164-1
kmod-crypto-gf128 - 5.4.164-1
kmod-crypto-hash - 5.4.164-1
kmod-crypto-hmac - 5.4.164-1
kmod-crypto-manager - 5.4.164-1
kmod-crypto-misc - 5.4.164-1
kmod-crypto-null - 5.4.164-1
kmod-crypto-rng - 5.4.164-1
kmod-crypto-seqiv - 5.4.164-1
kmod-crypto-sha1 - 5.4.164-1
kmod-crypto-sha256 - 5.4.164-1
kmod-crypto-sha512 - 5.4.164-1
kmod-crypto-user - 5.4.164-1
kmod-crypto-xts - 5.4.164-1
root@META-Flint:~#
Despite the above, it seems that the kernel's crypto-related functions are not working correctly.
I understand that this is a non-standard configuration and may not be a high priority, but I hope this issue will be fixed by the GL.iNet staff.
P.S. I'm also a bit concerned that FW 4.7.0 has disappeared from Flint's firmware page, 4.6.8 is now listed as the latest, and Flint is not mentioned in the 4.8.x roadmap... Surely this doesn't mean it's heading for End-of-Life (EoL), right?