Divested-WRT: No-nonsense hardened builds for Linksys WRT series

Thanks @SkewedZeppelin, so if I was to summarize both the -mthumb and -O2 switches lead to decreased code size (thus useful for the mamba kernel)...

On a somewhat unrelated note, I see you generated a new build today (Jan 14) and removed all previous ones... Aside from what's captured in the changelog, would you say this is any better than the one from Jan 10?

And lastly, I read through the thread but not sure I have this figured out - did you apply (or plan to) any patch for the cpu frequency scaling for any of the WRT targets? Reason I'm asking is when I loaded your build on mamba, I was able to run "cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq" and it would show 600MHz most of the time with the occasional jump to 1200MHz. I can't find any the equivalent since I moved to your build on cobra...



In this instance, both of those options have no effect on the kernel.
They are for compiling the programs.

-O2 actually increases code sizes.

would you say this is any better than the one from Jan 10

hostapd and wpa_supplicant no longer run as root!

cpu frequency scaling

I see no reason to change those defaults.

Hi @SkewedZeppelin
Something strange is going on when I flash your latest factory.img for the 1900AC v2... I do not use the sysupgrade at all, always factory.img and restore a previously saved config file. After loading the configuration file I end up with a corrupt bootloader environment, all I get when running fw_printenv is:

root@OpenWrt:~# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm

I was able to restore the bootloader environment by factory resetting the router (and frantically saved it) so that made me think it's not destructive.

WOW... while I was writing this it struck me that this config originated from an 1900AC v1, so perhaps this is what's causing the issue. Which file in the config backup should I remove, so I won't experience this any more?


Factory images are only meant to be flashed from the stock firmware.
Sysupgrade images are meant to be used from within OpenWrt.

There is no reason to wipe config when updating.

I also recommend you start fresh with a new config for your device.
You can extract the backup and browse the files using standard tools if you want
to reference the old configs.

@SkewedZeppelin I keep one partition on stock firmware and always flash the other one from it, that's what I meant when I said "I do not use sysupgrade at all, always factory image..."

My point was it seems like the config backup archive includes some files that are specific to the HW version (/etc/fw_env.config, /etc/config/bootenv, etc) so I should not backup the config on v1 and restore on v2

I recreated a new config for the v2 box and I'm now back in business :slight_smile:

Hi @SkewedZeppelin hope you following this and plan to build as soon as the fix is pushed upstream


The 20210120-00 builds include the patched dnsmasq.

It is why I made the 20210120-00 so soon after 20210118-00 builds.

Edit: I have updated the changelog to better reflect such changes.

thanks for your work.
btw, I am trying to build mine on yours and about patch, do you have some steps to proceed.
if I want to add one of yours ie: 0020-DNM-kconfig_hardening.patch
? patch -p 1 -i 0020-DNM-kconfig_hardening.patch ? thats it and after ''make nconfig'' etc


Use git am *.patch

1 Like


May I ask if you can create a link to the latest builds? (I'm specifically interested in the config file)

wget -O .config https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/latest/config

1 Like


A latest symlink has been added.

1 Like


btw, what about make menuconfig and the one you wrote on your page ; make nconfig?

If you have the requisite bits installed in your environs
make menuconfig == make nconfig == make xconfig
just a different interface, nconfig harkens back a few decades to ncurses, the follow up to curses; them were the days.



Thank you for providing this information. I was trying to build on my own and I wasn't able to get the performance that I was getting on the Davidc502 builds. I didn't have the knowledge to get where you are at and your sharing and openness is so greatly appreciated. Now with your documentation and patches my custom builds are working great. I have 24 hours in and all is good, I am maxing out my ISP bandwidth over wireless with no problems 500 down 30 up on my WRT3200ACM.

An added bonus is that the https://github.com/jerrykuku/luci-theme-argon I was using on older builds didnt load the login pages correctly and now they do.

1 Like

I was able to update my kernel to 5.4.93 by running a make kernel_menuconfig after my make nconfig using directions available at https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/

Dear @SkewedZeppelin,
Hello and I hope that you are safe and well. I have a simple request. I am getting ready to take my first spin with your No-nonsense Linksys WRT builds. I ran the command openssl engine -t -c
in order to check if Crypto accelerator is enabled. It was not. If at all possible, would you please enable the

(devcrypto) /dev/crypto engine

I really would appreciate it and I think that this issue has been resolved in the new kernels. Thanks in advance - and I look forward to being an active member of the Community.
Peace and God Bless - Stay Safe All

1 Like

I did not realize mvebu had any such hardware accel. Thanks!
I have enabled OpenSSL devcrypto support in the 20210131-00 release.
Please make sure you uncomment it in /etc/ssl/openssl.cnf under the [engine] block.
Further documentation is here


Hi @SkewedZeppelin and many thanks for continuing to provide this! I noticed in today's build you included "bmon" - I'm just curious what made you select it compared with other bandwidth monitoring packages?

I think I tried bmon recently and found screen wasn't very well laid out and a little difficult to read, ended up installing bwm-ng instead...

Also iperf3 is now included - are you using it to test your LAN or WAN performance (or both)? Just curious about the use case that made you include it permanently


1 Like

Is it related to usb drive ?

It is about getting the CESA cryptographic engine in play, check:

root@bsaedgy:~# dmesg | grep -i crypt
[    0.013616] cryptd: max_cpu_qlen set to 1000
[    1.680464] marvell-cesa f1090000.crypto: CESA device successfully registered
[   11.525081] cryptodev: driver 1.11 loaded.

should be some old threads to be found in forum. But I suppose if you encrypt things on your drive...