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

It has been dropped upstream.


Hi @SkewedZeppelin been a while since I posted here, only because everything worked so well for me :slight_smile: I finally got around to set up my own build environment, and managed to create my own builds following yours and others' excellent guides (@ambrosa in particular), many thanks everyone.

Here's my instruction set on a fresh Ubuntu bare metal 20.04 LTS installation:

sudo apt update
sudo apt upgrade
sudo reboot

# install OpenWRT dependencies
sudo apt install build-essential ccache ecj fastjar g++ java-propose-classpath
sudo apt install libelf-dev libncurses5-dev libncursesw5-dev libssl-dev
sudo apt install python python2.7-dev python3-dev
sudo apt install subversion swig xsltproc
sudo apt install asciidoc-base flex help2man intltool libusb-dev

# get divested config file and patches
mkdir divested
cd divested
wget -nd https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/latest/config
wget -r -l 1 -nd -np -A "0*.patch" https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/patches/

# from https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/#selfBuild
# but based on https://openwrt.org/docs/guide-developer/toolchain/use-buildsystem
cd ~/
git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
git config pull.rebase true
./scripts/feeds update -a -f
./scripts/feeds install -a -f
# copy in the config from the latest divested build here, name it .config
cp ~/divested/config .config

# git am the .patches from /patches
git am ~/divested/*.patch

# make any changes you want, then save and exit
make nconfig

make -j $(($(nproc)+1)) download
make -j $(($(nproc)+1))

# build files are in ~/openwrt/bin/ (firmware and packages)

Now for the question:

  1. How do I know I'll end up with the EXACT same image as yours? Compare SHA256 checksums? I did once, but they didn't match :frowning: Is this because of being built on different computers or somehow have different settings from yours?

  2. Your latest build from Oct 27 uses kernel 5.10.76 while my build from the latest Master today (r17883+9-fd717f54be) looks like still using 5.10.75 - why would that be? This solely based on (didn't flash the image yet):

ls -la openwrt/bin/targets/mvebu/cortexa9/packages/

Many thanks in advance for helping me stand on my feet :slight_smile:

1 Like


  1. Only if you use all of the identical versions and configs as I provide in my releases will you possibly get a matching hash. You'd have to checkout the main repo to the commit in version.buildinfo and the feeds to the commits in feeds.buildinfo. Order of patches applied shouldn't matter.
  2. Per the changelog, a patch is cherrypicked to get to 5.10.76. I always include cherrypicked patches in the dated release folder, not the /patches folder. In this case: 20211027-00/4724.patch

Thank you @SkewedZeppelin, unfortunately I'm a total noob at the git workings... Would you be so kind and provide a detailed way to do 1 above? I tried:

git checkout r17859+10-70c12d26ca

with r17859+10-70c12d26ca matching what's in version.buildinfo for your Oct 27 build but that didn't work. Could it be because I cloned the repo today thus this commit is no longer there?

Re 2 above - is this optional? And if I want to include it - what command needs modified in my list above?

Many thanks again, and apologies if my questions are dumb (they most definitely are)

@SkewedZeppelin we can also have an update version for Multi CPU_DSA ?


wget -r -l 1 -nd -np -A "4*.patch" https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/latest/	# get any cherrypicked patches

There's usually a good reason to cherrypick patches.

Good on you to actually document your workflow.

1 Like

Hi @SkewedZeppelin I see you just created a new build, and I was trying to replicate it when I realized the "config" file is missing in both "/latest" as well as " /20211101-00" folders. Is that accidental, or the build procedure changed and that's no longer needed?

Thanks in advance,

Managed to forget it. It is up now. Thanks!

I tested the multi dsa patch on caiman and mine shows interrupts on both eth0 and eth1

           CPU0       CPU1
 45:       7194        445      MPIC   8 Level     eth0
 46:       8249       1137      MPIC  12 Level     eth1

Did someone checkout the new qosify package?
I have it running for a day now. Seems quite good?
Expect that it doesn't autostart at boot.

There is not that much of a difference in CPU utilisation.
Most interrupts still land on CPU0.

Interrupts for me are always pegged to CPU0 (mamba, rango). Been wondering as to any potential differential of performance / throughput RE. round-robin vs assigning user ports to particular CPU port.

Built and flashed qosify yesterday but have not gotten around to configuring and running quite yet.

1 Like

By default the patch maps one CPU to the lan ports and the other CPU the wan port.
So I expected that the interrupts would have been spread more evenly between the CPUs.

I guess the problem is still the mvneta driver? And the hardware queue mapping...?

Yes, the reason I haven't keep those patches is that I didn't see any actually benefit.
Something is missing.

Hi @SkewedZeppelin the master snapshot from a few days ago shows:

selinux-policy: update to version 1.0

Any chance you could look at this again?



Yes, I've been watching it.
I'll give it a try soon, but I still think there are some bits missing.

Hi @SkewedZeppelin, putting more effort in trying to replicate your builds and came across the following:

  • On Oct 27 I built an image but did not include 4724.patch since it was a "cherrypick" and not in your regular /patches folder, and found my build was made for kernel 4.10.75 (your build was already at 4.10.76)

  • Today I built again using the latest repo and 4724.patch is again NOT in your /latest folder, but I now ended up with 4.10.76

Question - can I conclude from the above that the repo master snapshot has now incorporated the patch thus kernel is at 4.10.76?



the number on the patch is the pull request ID on the OpenWrt GitHub:

You can see it was picked into master per the last comment.
The next build I do will likely include

as you see it is still open, not closed meaning it isn't included yet.


what is qosify please



@SkewedZeppelin I downloaded your Multi-CPU image (thank you) however I found my upload was stuck at 89Mbps :frowning: on my WRT1900ACSv2

Looks like I need to either add kmod-sched or remove a commit as I previously found here -

I will build my own multi-CPU image using your config as a base however I am not sure what I need to do with the various patches - are you able to advise please?

Appreciate your and everyone else's time.

@oli - what hardware are you running or do you have your own build? As it appears you're not affected by this upload limit as I... :confused:

Cheers. :beers:

Edit: I should have read the thread more thoroughly as I missed this - seems I should wait

wrt1900acs v2 I gave all the details above!