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

Thank you for getting back to me:

Without Cake my download speed went up to 460-610Mbit. Testet multiple times with speedtest-cli from both my Macbook Pro and Raspberry pi 4. Result are about identical.


Testing download speed................................................................................
Download: 446.86 Mbit/s
Testing upload speed................................................................................................
Upload: 16.11 Mbit/s

Perhaps this is as expected?

Rather than port things meant for a different architecture, I am in touch with mvneta and mv86xxx drivers maintainers to enable balancing the load across both cpu cores but their time is understandably limited.



If everyone would like to test upcoming lts with vanilla openwrt - to see any regression or bugs.

The easy way - Ansuel's PR #4748, or here.

Additional patch - package/kernel/mwlwifi/patches/002-mwlwifi-pcie-fix.patch

--- mwlwifi-2020-02-06-a2fd00bb.orig/hif/pcie/pcie.c
+++ mwlwifi-2020-02-06-a2fd00bb/hif/pcie/pcie.c
@@ -1292,10 +1292,14 @@
        const char filename[] = "/tmp/BF_MIMO_Ctrl_Field_Output.txt";
        char str_buf[256];
        char *buf = &str_buf[0];
+#ifdef set_fs
        mm_segment_t oldfs;

+#ifdef set_fs
        oldfs = get_fs();

        buf += sprintf(buf, "\nMAC: %pM\n", bf_mimo_ctrl->rec_mac);
        buf += sprintf(buf, "SU_0_MU_1: %d\n", bf_mimo_ctrl->type);
@@ -1315,7 +1319,9 @@
                          filename, (unsigned int)fp_data);

+#ifdef set_fs

 static void pcie_process_account(struct ieee80211_hw *hw)
@@ -1641,5 +1647,7 @@
 MODULE_AUTHOR("Marvell Semiconductor, Inc.");
 MODULE_DEVICE_TABLE(pci, pcie_id_tbl);

Hi there,

There's been good progress on solving (finding a workaround) for the WRT32* Wi-Fi issue in the thread I posted about earlier.

There's now a patch available, that should also work for master.

Can we get this tested/added for Divested as well? I am more than happy to test is needed.

Alternatively, if someone can point me into the direction of how to compile only the patched package for the current version of Divested, I can try that as well.

Edit: Seems we might be seeing the fix upstream soon as well. :ok_hand:

Edit2: Should be pushed to master now.

1 Like

I am thinking of switching to the latest build of Divested for my 3200ACM

Currently, I am running insomnia build with openWRT 19.07.

Just a quick question does Divested support ESATA? I tried David503 builds in the past but I could not get ESATA to work on that for some reason, which warranted me to switch to insomnia, as it is a critical feature for me.

awesome news!

New build is up with the fix thanks to @nbd and @cotequeiroz!


I am still struggling with getting a particular wifi client to connect on my 1900acsv2. Because the failure is happening way early in the process, I am attempting to enable lowest level debugging info on hostpad (log_level=0), but wasn't setting anything but notice and info level messages. Based on what I read, I was thinking the that low level debug messages may not be compiled into wpad.

I was only enabling log_level='0' on one radio (radio1), since thats where the client is. Today I enabled log_level=0 on both radio0 and radio1.

:~#  grep _level /var/run/hostapd-phy0.conf
:~#  grep _level /var/run/hostapd-phy1.conf

Now I am seeing hostapd debug level messages, but only on the wlan1 and wlan0 devices/interfaces associated with br-lan.

thu Nov 25 10:32:07 2021 daemon.debug hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: received EAPOL-Key frame (4/4 Pairwise)

Maybe wlan1 was always logging in this limited way and I didn't notice, but now in any case, the messages do print on specific interface, and my real problem is it that the other vlan bridge devices/ssids won't log anything but info and notice messages:

Thu Nov 25 10:32:12 2021 daemon.notice hostapd: iot_wifi: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx

as an example...

So... maybe this is a DSA config thing, and I need to configure something else to get hostapd to log_level 0 for the other vlanned ssids? or maybe this is a hardening config thing with br-lan ?

Hmm...has anyone managed to get radio2 working with this change/newist builds? If I flip back (I think to 5.10.74) radio2 works, but I can't seem to get it to start up under any config anymore.

root@OpenWrt:/etc/modules.d# hostapd  /var/run/hostapd-phy2.conf
nl80211: kernel reports: Registration to specific type not supported
Failed to initialize QoS Map
Interface initialization failed
wlan2: interface state UNINITIALIZED->DISABLED
wlan2: Unable to setup interface.
wlan2: interface state DISABLED->DISABLED
hostapd_free_hapd_data: Interface wlan2 wasn't started
nl80211: deinit ifname=wlan2 disabled_11b_rates=0
ELOOP: remaining socket: sock=18 eloop_data=0xb6c2ec30 user_data=0 handler=0x4f5c8c

I decided to bite the bullet to install this build on my WRT3200ACM.

What I loved about it, the dark mode stock theme. Felt much more responsive than other community builds. WPA3 worked like a dream. The latest version of OpenWRT and regular updates.

But unfortunately, the Achilles heel for me was that it suffers the same issue as the other community builds and that is the ESATA just does not work with endless reports in system log SATA link down error (300). Which was a shame as it is the best one that I have used so far.

If you need ESATA why not just run the latest master snapshot and install the driver pkg? There is no unique theme on this build, it uses the same bootstrap theme as master which has had a dark mode for a couple months now. Master also has the mwlwifi mac80211 fix in them from last week too.


Then just SSH in and install a bunch of relavent packages such as what I use below:

opkg update && opkg install luci irqbalance luci-app-advanced-reboot luci-app-sqm luci-app-adblock luci-app-upnp luci-app-wireguard luci-app-samba4 kmod-usb3 kmod-ata-marvell-sata kmod-usb-storage kmod-usb-storage-uas block-mount usbutils mount-utils luci-app-hd-idle kmod-fs-exfat iperf3 nano


Sounds like a plan,

The trouble I find is knowing which drivers to install, thanks for providing which ones I need.

Those are the packages I'm currently using because I couldn't get USB 3.0 for my external drive to work on Divested, it's a fantastic build otherwise. Samba4 is so fast on mvebu, I get 100-120 MB/s read-write on my USB 3.0 drive which maxes out the gigabit LAN speed. I'm not positive esata driver is on the list, it may be the marvell-sata one, if not I'll help you find the package, the OpenWrt packages don't describe esata from what I could find.

1 Like

Hi all!

Simple question: Will work if i restore backup from WRT1900ac v1 to WRT3200ACS?


No, configuration tarballs are not portable between devices (nor between major versions).

1 Like

@slh gave you the answer, but I'm curious why you don't want to the use the build for your device?

1 Like

OK, Thank you!

Currently i'm using WRT1900AC, but i wan't to replace it with WRT3200ACS. And i was trying to avoid manually configuring from scratch

Well, I never did figure out how to get the low level hostapd diags on the alternate bssid interfaces. So I moved the problematic client over to the primary radio ssid on wlan1 (log_level=0 works on wlan1 and wlan0 only ). So I debugged it there.

In the end, I got the client working. It turned out to be a physical placement issue. The client has been sitting colocated near the router for over a year and was fine on 19.x(Davidc build). I didn't touch either device before or after the upgrade ,they are in the same locations.

Post upgrade, it seems like the client was drowning out the router and I saw little actual traffic (from the routers perspective). From the Client perspective it was continually trying to connect and then getting dissociated by the router for either fielded 4 way handshakes (which only showed up in router once/twice a day) or just activity timeout disconnects. The received levels didn't really indicate an issue, I guess could have been a weird reflection null or something as well. I moved the client to the down to the floor temporarily and it immediately connected. Has been solid ever since.

I think you will find that most of your 1900AC configs will be quite portable between the two platforms with little or no tweaking. Make sure you take a backup and include anything outside of /etc/config that you may have set up.