@Bartvz have you tried these wireless drivers?
Not yet, but it is on my to-do list.
Nossiac said that the driver does not follow mac80211 architecture and is possible remove these components, including rt2x00, mt76, mac80211, cfg80211, wpad-mini, compat-wireless...
The build boots but wifi is not coming up due to the mt7621 kernel module not loading. Loads of kmodloader: failed to mmap /lib/modules/4.9.73/mt7612.ko in the system and kernel logs. However, this is with the master branch. Might do a build with the 17.01 branch if I have time.
1 Like
Anybody has issues with USB3.0 flash drives on DIR-860L? When I first upgraded it from openwrt, flash drives worked but as soon as I reboot the device, USB3.0 flash drives are not recognized any more. USB2.0 flash drives work without any issues. And I have two devices, the same happened to both of them with different USB3.0 flash drives. Any ideas?
Thanks
Hmm, sounds like automount is not working. Have you tried mounting them manually?
To manually mountā¦
mount /dev/sda1 /mnt
To automount, see this section in the LEDE User Guideā¦
https://lede-project.org/docs/user-guide/usb-drives#automount_the_partition
Hi, thanks for the replies but it is not a question of mounting the devices. I tried manual mount but it canāt be mounted when a device doesnāt exist. fdisk -l and lsusb -t doesnāt show any attached drives and attached devices. I tried this with 2 usb3.0 devices and they show the same behaviour. On the other hand any usb2.0 device works without any issues. Including the automount.
Any ideas?
A bit late, but...
I did a very quick test, formated a usb 2 flash drive with luks and was able to mount it, did a samba share and got around 8mb/sec upload. I should be able to get a usb 3.0 hdd in couple of days and will report back.
I'm mostly concerned if the cpu will be able to handle to encryption. Did some tests with tp-link 1043nd v1 with the idea of being a ssh gateway (socks proxy) but it can handle around 15mbit (cpu 100%) with tweaked ciphers and openssh server.
big thanks!
1 Like
Better late than never 
Interested to hear what you find.
The 1043ND V1 only has a single core MIPS 24K 400 MHz cpu, the 860 has a double core MIPS 1004K 880MHz cpu so my guesstimate would be that it performs at least 2-2.5 x better.
OP updated with a fresh new build. Enjoy!
1 Like
whats new in latest built?
r5762: Added support for LUKS encryption. Upstream changes most notably a few bugfixes6 to cake.
It is written in the first post....you can find there also the link to the commit related to cake.
I got my usb 3 hdd enclosure today so I did some tests on r5678-0b28cc56d4
basically it is slow, tried a lot of options and coping file over smb gets me around 14mb/sec;
hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 140 MB in 3.03 seconds = 46.13 MB/sec
will check with normal ext4 (no luks) partition tomorrow but CPU seems fine so far (top says around 40% idle (which might be a single core at 100% + 10% more from the other not sure))
Tried some dd testing but not sure if results are correct (basically 500mb for 26 seconds):
time sh -c "sync; dd if=/dev/zero of=tempfile bs=1M count=500; sync"
500+0 records in
500+0 records out
real 0m 26.48s
user 0m 0.00s
sys 0m 11.04s
time sh -c "sync; dd if=tempfile of=/dev/null bs=1M count=500; sync"
500+0 records in
500+0 records out
real 0m 31.50s
user 0m 0.02s
sys 0m 4.90s
Will check more things hopefully soon, thanks
This might explain it
cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 35617 iterations per second for 256-bit key
PBKDF2-sha256 52851 iterations per second for 256-bit key
PBKDF2-sha512 20352 iterations per second for 256-bit key
PBKDF2-ripemd160 36008 iterations per second for 256-bit key
PBKDF2-whirlpool N/A
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1.1 MiB/s 11.9 MiB/s
serpent-cbc 128b 8.8 MiB/s 9.7 MiB/s
twofish-cbc 128b 11.6 MiB/s 13.1 MiB/s
aes-cbc 256b 9.1 MiB/s 9.3 MiB/s
serpent-cbc 256b 9.6 MiB/s 9.7 MiB/s
twofish-cbc 256b 12.8 MiB/s 13.1 MiB/s
aes-xts 256b 12.0 MiB/s 11.9 MiB/s
serpent-xts 256b 9.3 MiB/s 9.7 MiB/s
twofish-xts 256b 12.5 MiB/s 13.0 MiB/s
aes-xts 512b 9.2 MiB/s 9.2 MiB/s
serpent-xts 512b 9.8 MiB/s 9.7 MiB/s
twofish-xts 512b 13.1 MiB/s 13.1 MiB/s
cryptsetup status gosho
/dev/mapper/gosho is active and is in use.
type: LUKS1
cipher: aes-xts-plain64
keysize: 256 bits
device: /dev/sdb3
offset: 4096 sectors
size: 197261529 sectors
mode: read/write
So aes-xts 256b --> 12.0 MiB/s 11.9 MiB/s
The MediaTek MT7621 should have some "HW Crypto Engine 200Mbps" but i doubt it can be enabled or used in Lede/OpenWRT
@Bartvz is "Crypto acceleration support" enabled in the kernel ?
Now that this question popped up about HW crypto, maybe Bartvz can take a look at this branch:
I wonder why is this not merged yet? Maybe it worth a try and see what the performance gain is.
Probably because it's simply not ready yet. A few things got merged from it though and I was hoping more would be merged eventually. Of course I can experiment with cherry picking it
@pivanov84 to answer your question directly, not at the moment because the driver for it just isn't there
The hw crypto driver at the moment is only for IPSEC. As soon as I have the crypto engine working with OpenVPN for the MT7628 I am willing to try and write an AES crypto driver for the IP93. That means, if Mediatek did a full implementation on the MT7621 (which is not clear from their documentation).
The IPSec driver will never merge with Lede/OpenWRT because it patches some hooks inside the network stack as far as I understand the reason behind this.
1 Like
It seems the alternative MTK driver will have the 4.9 kernel support soon:
https://github.com/Nossiac/mtk-openwrt-feeds/issues/5
The 7602 driver was added 5 days ago.
Would be interesting to try.