Optimized build for MT7621 devices (WG3526)

This is a custom ROM for the WG3625. This build contains several modifications and shares a big part of the source code with my build for IPQ40xx devices.

Warning: The full notes and download links are available inside the latest release. Read the document carefully before downloading (the page is designed to force users to read before download).

This build is currently a work in progress. As with the IPQ40xx, this build is based on OpenWrt snapshots, built with the latest tools and maximum optimization. Along with it, this is some extra features:

  • Built from master, this means that this is a snapshot.
  • Fully preemptive, tickles @ 100 Hz kernel for improved latency.
  • GNU bash as the default shell and nano with syntax highlights, for a more pleasing administration experience.
  • Enabled the latest Linux elevators for optimized NAS usage.
    • mq-kyber by default for non-rotational multi-queue.
    • mq-bfq by default for rotational multi-queue and UAS (USB to SCSI, like portable hard drives).
    • noop for single queue devices (i.e. ubiblock and the internal flash).
  • Enabled all the most common filesystems: exfat, ext4, f2fs, vfat (FAT32), msdos (FAT16)
  • Enabled the usage of the first partition of the microSD card as an external overlay by default.
  • A sensible collection of packages and kernel modules preinstalled in the ROM. A wide selection of software can be installed via LuCI as I provide some kernel modules and software.
  • zswap (lzo-rle with Sony's z3fold) and zram (zstd) for better memory usage. This allows users to run large adblock and ban-ip lists, samba4, minidlna and LuCI, at the same time, without swapping to a slow disk or without dropping the expensive SQUASHFS blocks (which are slow to read and harder to decompress).
    • A new LuCI interface to manage the compressed memory subsystem.
  • A custom set of scripts for:
    • Using the OEM partition for the external overlay and packages for extra storage... for free!
    • Configuring the firmware, things such as "branding" and using 192.168.xx.1 to avoid network collisions.
    • Fine-tuning the memory subsystem and the priorities, niceness, OOM scores, and scheduling policies of the system processes (and services) and monitoring them.
  • unbound installed and preconfigured, among with dnsmasq, for a fast (caching), secure (DNSSEC) and private (DNS over TLS) DNS resolver (currently, working as a forwarder to QUAD9. See https://quad9.net). Note: DNSSEC and DNS-over-TLS are features that totally prevent DNS spoofing, but they can degrade the performance of uncached requests because the router CPU is not precisely fast for encryption.
  • Overclocking: the PLL allows the CPU to reach up to 1.2 GHz, a patch applied to the source code unlocks all the available frequencies. This is a kernel feature and all supported devices will be overclocked to 1.2 GHz without changing the bootloader.
    • Note that overclocking will not increase the performance, it is in fact a technique for reducing latency.

Enable the "Watch" button in GitHub to get in touch with the latest improvements!

Known issues, source code, and feedback here in my GitHub clone of OpenWrt.


Would I be able to use this on my Newifi 3 D2?



Probably, yes. But I need testers willing to help me to make the software work on their devices.

I think that the most appealing characteristic is overclocking, maybe a wise user can port only that to the mainstream, but I am not going to try it. Anyway, if anybody has an MT7621 device and is willing to help me to port the build to their device, please feel welcome.

Note: this build fully supports the WG3625 devices (both versions), so people that own these devices can run the build directly.


I am just getting familiar with openWRT again, but I have a hardware hobbyist background, and 3 Newifi 3 D2's. I have one from PCWRT, one I just received from AliEx that came with openWRT but I am currently researching how to reflash, and a third in the mail that should arrive within the next week. I have already installed a three pole audio jack on the hardware uart, and while totally incompetent with them, I have openocd, urjtag, a bus pirate, goodfet42, and ft2232 available, and occasionally manage to successfully copy and paste some code. On github I am Upcycle-Electronics. How can I help?

It depends on the situation. This is, mainly, a custom version of OpenWrt snapshots with some magic added to both userland and the kernel (i.e., the ability to clock the CPU to 1.2GHz without changing the bootloader).
If the device is already ported to OpenWrt, the only work that is needed is to add it to the customized files that I maintain. If the device is not ported to OpenWrt yet, the wise decision is to port it first, and once it's mainstream add it here.

When there is a device in upstream OpenWrt, the most I need is 2 things to support it here:

  1. A collection of the logs from the running device (and answering some occasional questions)
  2. A tester that can run the "beta" firmware, test it, report any issue and have the ability to recover the device if something does wrong.

An SPI programmer is good to have because you can clone the SPI chips, store them in a safe place and re-flash them to the device if something goes wrong. Hardware damage beyond screwing a ROM is very unlikely to happen.

P.S. I am not active in the forums at the moment. Please contact me via GitHub, I am always aware of it. In my profile, you can see my email and contact me there, on Twitter or Reddit if you prefer.

Hello, people from the OpenWrt forum. It's been a long run these last months. However, I am here to say... I'm back! Yes, I didn't forget about it—the first release candidate for OpenWrt 21.02 brought me back to life!

I was waiting for 20.04 (that never appeared) because these modifications need a Linux 5.4 (or later) kernel. Now, I'm preparing to maintain a fully stable release based on the stable 21.002 and subsequent updates.

There is some other news. I will start merging my patches to the 20.02-rc1 tag and release my "release candidates" as well. When they release the official version, I'll relaunch my version to my website (so, I will redirect the traffic there, no more GitHub releases when finally launching 20.02)

I opened the notifications again from this thread if anybody wants to reach me. I am also available at software@notengobattery.com, in GitHub, and the PMs here in the forum. Please, take care during these tough times and thank you for your patience :slight_smile:

The code will be majorly refactored and I'll use the (way) sane new OpenWrt configuration instead, so I won't intrude into the user's preferences and I'll make the upgrades to preserve the settings as a proper stable release.

This is great news, as I've been interested in moving to a 21.x release for a small (dozen) fleet of ZBT WE3526 I support (friends and family). Particularly interested in anything that increases stability.

I have multiple test units, and recovery tools, so happy to help test.

I did not see much mention of WiFi in your custom build, are you planning anything for that?

I am not sure what's the matter here. Can you, please, explain it? Thanks.

I've been running 21.02-rc1 on the WE3526 as my only access point in the home for two weeks, and there are issues with the wifi signal strength and stability over time. It is slightly better than the 19.07.7 build, but there are still issues.

On first boot, the signal seems fine, but strength is lower than other APs. And after a few days, even worse.
Then the 7603 driver crashes that occur every three or four days. This is also reported by someone else: https://github.com/openwrt/mt76/issues/532

Hmmm, my device is running my v1.05 from several months ago, and it does not crash. However, now that you say so, I'm afraid that it will crash with the new versions.

I can't compare it to the OEM firmware performance, but I think that the signal is pretty standard for the radios' power. Thanks for pointing it out. I am in the process of merging the patches to 21.02-rc1 and I'll let you know when is ready if you want to give it a try.

1 Like

How does your build do with the flent test?

Hi, i own a newifi d2.
Can you build a release to this device so i can test and return a feedback ?

1 Like

@dana44 I tested it and didn't crash. I think I don't have enough bandwidth for it to crash. Maybe a netperf local server attached to an ethernet port is reproducible?

Anyway, does anybody have a kernel log of the crash? That would be a fascinating piece of debugging information.

@anonymousti sure, let's talk via DM or via my developer email.

How did the graphs look? For my test I experienced drops and ping spikes on the 2.4GHz radio, but not 5GHz