OpenWrt 25.12.0-rc5 - Release Candidate

Release and security announcements
1

Hi,

The OpenWrt community is proud to announce the fifth release candidate of the OpenWrt 25.12 stable series.

Download firmware images using the OpenWrt Firmware Selector:

Download firmware images directly from our download servers:

Please test this version

This is not the final version, this is a test version. Please report problems and bugs in our issue tracker.

Highlights in OpenWrt 25.12

OpenWrt 25.12.0-rc5 incorporates over 4600 commits since branching the previous OpenWrt 24.10 release and has been under development for over one year.

Only the main changes are listed below. See changelog-25.12.0-rc5 for the full changelog.

General changes

The hardware requirements did not change significantly, most devices supported by OpenWrt 24.10 should also work with OpenWrt 25.12.

Switch package manager from opkg to apk

OpenWrt has transitioned from the traditional opkg package manager to apk (Alpine Package Keeper).

This change brings several advantages:

  • apk is still maintained, the OpenWrt opkg fork was not maintained any more.

apk supports most features of opkg. Only very few package names changed. The command line arguments of apk are different from the command line arguments of opkg.

For users migrating existing systems, an official opkg to apk cheatsheet is available to ease the transition and map common workflows.

Integration of attended sysupgrade

The attended sysupgrade LuCI application is now installed by default.

ASU allows devices to:

  • Upgrade to new OpenWrt firmware versions
  • Automatically rebuild firmware images with all currently installed packages
  • Preserve system configuration during upgrades

This dramatically simplifies upgrades: with just a few clicks in LuCI and a short wait, a custom firmware image is built and installed without manual intervention.

Shell history is preserved

Shell command history is now preserved across sessions by storing it in a RAM-backed filesystem.

Benefits:

  • Command history is no longer lost between logins
  • No unnecessary writes to flash storage by default

For users who prefer persistent history storage, this behavior can be changed by editing: /etc/profile.d/busybox-history-file.sh

:warning: Note: Storing history on flash will increase write cycles and may impact flash endurance over time.

Integration of video feed

The OpenWrt video feed with Qt5 and UI applications is integrated by default.

Wi-Fi scripts in ucode

The wifi scripts were rewritten in ucode.

Target changes

  • Extend realtek target with support for more switch SoCs like 10G Ethernet switches.
  • Extend qualcommax target with support for ipq50xx and ipq60xx SoCs.
  • Added siflower target for Siflower SF21A6826/SF21H8898 SoCs
  • Added sunxi/arm926ejs subtarget for Allwinner F1C100/200s SoCs

Many new devices added

OpenWrt 25.12 supports over 2240 devices. Support for over 220 new devices was added in addition to the device support by OpenWrt 24.10.

Core components update

Core components have the following versions in 25.12.0-rc5:

  • Updated toolchain:
    • musl libc 1.2.5
    • glibc 2.41
    • gcc 14.3.0
    • binutils 2.44
  • Updated Linux kernel
    • 6.12.71 for all targets
  • main packages:
    • cfg80211/mac80211 from kernel 6.18.7
    • hostapd master snapshot from August 2025
    • dnsmasq 2.91
    • dropbear 2025.89
    • busybox 1.37.0

In addition to the listed applications, many others were also updated.

Upgrading to 25.12

Upgrading from 24.10 to 25.12 should be transparent on most devices, as most configuration data has either remained the same or will be translated correctly on first boot by the package init scripts.

  • Sysupgrade from 23.05 to 25.12 is not officially supported.

  • Cron log level was fixed in busybox. system.@system[0].cronloglevel should be set to 7 for normal logging. 7 is the default now. If this option is not set, the default is used and no manual action is needed.

  • Bananapi BPI-R4: Interfaces eth1 was renamed to sfp-lan or lan4 and the interface eth2 was renamed to sfp-wan to match the labels. You have to upgrade without saving the configuration.

Scratch installs/upgrades

If you wish to start from scratch (always the safest, but also the most work), simply download the pre-built image from the downloads site or from the Firmware Selector to your device. Make sure to create and save a backup, then install the image using sysupgrade -n /tmp/firmware.bin or the LuCI Backup/Flash Firmware, being sure to set "Keep settings and retain the current configuration" to its off position. Restore or reconstruct your configuration using the contents of the backup as a template.

Attended Sysupgrade options

Attended Sysupgrade (ASU) allows you to build a custom image that retains all of your installed packages and their configuration transparently. You need to use one of the three ASU clients that interface with the ASU server to produce this custom image:

  • Firmware Selector - an online builder that requires you to manually supply it with the packages you wish to have installed. This package list is sent to the ASU server, and a new custom device image is created containing those packages. You may then download and install the image in LuCI Backup/Flash Firmware, but for this you would enable "Keep settings..."
  • Luci Attended Sysupgrade - the web interface to the ASU server. This tool allows you to choose a new OpenWrt version, then collects the names of the packages on your device and sends them up to the ASU server. LuCI ASU then downloads the created image directly to your device and allows you to install it, without having to do any of the bookkeeping tasks involved with using the Firmware Selector.
  • owut - a command line package that does the same job as LuCI ASU, but provides more diagnostics and better visibility into what's happening at the various steps before and during the build process.

Both the LuCI ASU app and owut are optional packages in 24.10, so if you have not installed them, they won't be there by default. Use either the LuCI Package Manager to install them, or you can do it from the command line with opkg:

$ opkg update
$ opkg install luci-app-attendedsysupgrade
$ opkg install owut

Note that you can install one or the other, or both together, they are completely independent packages.

Upgrades with Firmware Selector

The Firmware Selector does an excellent job of searching through the thousands of available device configurations and getting you to the right place. But, some devices have several variants and possibly different image formats, so if you're unsure about which one you need or which device you're dealing with or anything else, go to the |Firmware Selector support thread and ask away.

Upgrades with LuCI Attended Sysupgrade

The LuCI web interface should be fairly self explanatory. Since you have fairly limited options there that should be pretty obvious, but if anything is unclear or you're unsure about something, go to the LuCI Attended Sysupgrade support thread and ask.

Upgrades with owut

If you choose to use owut, the fact that it's a command line program means you'll need a little more explanation regarding best practices. In any situation, it's always safe to do a check to see what's going on.

$ owut check --verbose --version-to 25.12
... a lot of output ...

This check should show you all the details of what this upgrade entails with regards to the packages available, and will point out any issues with package versions and so on.

Assuming the results of the check look good, you can simply do an upgrade next.

$ owut upgrade --verbose --version-to 25.12
... even more output ...

If you are unsure of anything you see in the check, during the upgrade, or simply have questions, jump on over to the owut support thread on the forum and ask.

Known issues

  • Users of Zyxel EX5601-T0 devices need to check their WAN interfaces as port was renamed from eth1 to wan.

Full release notes and upgrade instructions are available at
https://openwrt.org/releases/25.12/notes-25.12.0-rc5

In particular, make sure to read the regressions and known issues before upgrading:
https://openwrt.org/releases/25.12/notes-25.12.0-rc5#known_issues

For a detailed list of all changes since 25.12.0-rc4, refer to
https://openwrt.org/releases/25.12/changelog-25.12.0-rc5

To download the 25.12.0-rc5 images, navigate to:
https://downloads.openwrt.org/releases/25.12.0-rc5/targets/
Use OpenWrt Firmware Selector to download:
https://firmware-selector.openwrt.org?version=25.12.0-rc5

As always, a big thank you goes to all our active package maintainers, testers, documenters and supporters.

Have fun!

The OpenWrt Community

To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

28 Likes
OpenWrt 25.12.0-rc4 - Release Candidate
3

ASU testing on this version was much more stable that -rc4, the builds were fast and clean.

If you encounter issues with ASU upgrades, please report them on the respective client threads:

Rockchip target

Is available in -rc5, the bug that cause it to not build for -rc4 has been long fixed.

The only known issue at present is a transient one: the imx/cortexa9 and zynq/generic targets don't have their ASU docker containers yet, so it might be a few hours until these devices appear in any ASU client.

Well, they built a lot faster than I expected, looks like they jumped the head of the queue and bypassed the 30 snapshots ahead of them, and are now tested and available.

7 Likes
4

Worked pretty well on the MT6000 and on a MX4200v1

includes the latest files needed for QoSmate autorate to work on MT6000
cakeMQ is working/enabled on the MX4200v1

2 Likes
5

Linksys EA8300 (ipq40xx/generic)
Upgraded to rc5 from rc4 just fine using owut. Everything is all good. Thank you devs as always!

To note, with v25.12 the issue that IPv6 (wan6) would not get proper address and PD due to the default DUID value generated and had to delete it and restart wan6 for IPv6 to work properly.

So, following owut using uci-defaults script and referencing /rom/etc/uci-defaults/14_network-generate-duid, I deleted the set line and replaced it with delete network.globals.dhcp_default_duid then proceeded with ā€“-init-script in owut upgrade and that took care of it this time, meaning I donā€™t need to delete the value manually and restart wan6.

Checking the rom uci-defaults folder and I now have 99-asu-defaults with:

uci -q batch <<-EOF >/dev/null
delete network.globals.dhcp_default_duid
commit network
EOF

exit 0

Again, thanks devs and everyone!

1 Like
6

Used ASU to upgrade from rc4 to rc5 on a Netgear R7450 (mt7621), it's working good with Xfinity cable. Thank yous!

7

owut fast and reliable from rc4 to rc5 with customization including openssl replacement:

on these targets: mx8500, mx4300, wrt1900, whw01, rac2v1k, dir3060.

excellent do far

thank you openwrt devs and community

1 Like
8

The Ansible collection community.openwrt has tested OK with it: :rocket:

Friendly check: what are the timeframe expectations for the release of 25.12.0 proper? The community.openwrt collection is set to have a release by Tue/Wed next week, then the next one is set to 4 weeks later. I am happy to delay the next week's release if we expect to have the system's release soon, but if there is no estimated time for that, we are happy to stick to the original schedule on our side. Thanks in Advance

1 Like
9

Hauke said in the mailing list that 25.12.0 should be released in the week after rc5.

3 Likes
10

But that, of course, depends heavily on how well the rc5 works. If there are too many issues, we might see an rc6 and a longer timeline.

9 Likes
11

Asus TUF AX-4200 OWUT upgrade from 24.10 working awesome.

12

So i should add, next week ā€œif everything goes as plannedā€

1 Like
13

Netgear WAX202: AP+STA+DFS is still not fixed. STA connects, the AP never comes up on the same channel. Here is a message containing the set of commits to be backported:

It worked in 24.05.5, it works in SNAPSHOT, but not on 25.12.0-rcX.

2 Likes
14

Unfortunately this didnā€™t work for me and I cannot connect to ipv6 websites like https://ipv6.tlund.se.

My ISP does not have native IPv6 so I am using 6to4. The router reports IPv6 addresses, just no connectivity.

EDIT: it was is a package issue; mesh11sd is the culprit. I removed it from my added packages and IPv6 connectivity is restored.

15

Updated Linksys EA8500 from rc4 - no issues

Updated WRT3200ACM from 24.10.5 - canā€™t get Wireguard working - canā€™t get Policy Based Routing to start - reverted to 24.10.5 where all works ok.

17

[Previous reply deleted as it is too verbose and can be seen as inflammatory]

This is common nowadays and is likely not related to the upgrade. 6to4 requires a public IP, an ISP that does not block protocol 41 or 192.88.99.1 traffic (many do), and a route to 192.88.99.0/24 that does not lead to an ISP that blackholes, throttles, or delays traffic. You will get a 2002::/16 address no matter what, if you have a public IPv4. If the traffic is blackholed by your ISP or a transit ISP, you will get no IPv6 connectivity.

In short: the same-time breakage likely resulted from same-time ISP-side changes, not from the OpenWrt upgrade.

I do not recommend using 6to4 at all, as it's deprecated and does not work in practice (incomplete reachability or huge delays) for many users.

If you have a public IPv4 address, 6in4 (e.g., from HE) may be fine. Alternatives include paid tunnels and VPNs, e.g., from https://hoppy.network (WireGuard, based in Chicago, gives /56 of IPv6) or https://swissvpn.net/index.php?lang=en (PPtP, based in Switzerland, limited to 30 Mbps if you order a speed upgrade and 15 Mbps otherwise, gives /64 of IPv6 if you ask for a static IP). Even though PPtP encryption is broken, that's OK for your use case specifically, as the goal is obtaining IPv6 connectivity, not hiding anything from traffic snoopers. As a reminder, we are comparing this with 6to4, which is completely unencrypted.

18

The RC5 seems that fixed my problem with radios donā€™t starting at boot. I closed the issue https://github.com/openwrt/openwrt/issues/21814

I will keep an eye on it, but for the rest, it seems itā€™s working without problem.

3 Likes
19

I have dual stack and the steps I mentioned for that script only automates the manual task of removing DUID value via LuCI or via ssh (uci delete and commit network) after an upgrade on first boot so I donā€™t have to do so.

You might need to do more on your case like patrakov's reply

20

I still have that issue. The APs come up fine, but Client connections are disabled after every reboot.

21

Is there a way to pre edit the configure files? I.e. update configure, do sys upgrade with keep settings then be happy :grin:

Just a matter of changing eth0 and eth1 in the network file, save it then upgrade, or does that not work?

1 Like