OpenWrt 24.10.0 - First Stable Release

rseiler · February 6, 2025, 6:16am

Oh, so that ath10k model doesn't see the 5GHz issue then?

Applepie · February 6, 2025, 6:22am

Newbie here,

Works great/amazing on Zyxel M904. Easy to use and fast.

Many thanks for all contributors for replacing the bad OEM FW.

Dante · February 6, 2025, 6:25am

I had some trouble in the past with the currently default CT firmware and 5GHz + WPA3 being slow/unstable, so I switched to a more up-to-date non-CT firmware, which has been rock-solid so far.

rtoussaint · February 6, 2025, 7:03am

The files for the mediatek7622 based AX6 / AX3200 are corrupt, do not flash if you don't want to unbrick your device. Attended sysupgrade worked for me, I think owut will too, but the factory and sysupgrade images won't.

Esbeeb · February 6, 2025, 7:05am

Yay, RSS!

Schugy · February 6, 2025, 7:05am

Thank you devs for the new release. I have the (hopefully harmless) warnings on my Archer C7 V5 (ath79 non-CT-Firmware) and RE205 V3 (ramips mt76x8) running batman-adv..

WARNING: CPU: 0 PID: 407 at backports-6.12.6/net/mac80211/main.c:408 0x82902a50 [mac80211@f469e546+0x8a000]

WARNING: CPU: 0 PID: 7 at backports-6.12.6/net/mac80211/main.c:408 0x82a823e0 [mac80211@4a0c0109+0x75000]

So far NBG6617, C7 and RE205 run fine.

ChrisNL · February 6, 2025, 7:06am

Runs fine on NanoPi R3S. Thnx for supporting this new device

josteink · February 6, 2025, 7:55am

Not sure if this is "known" or not, but it seems like the ipq40xx target is missing a lof of packages?

Not critical by any means, but this is preventing me from upgrading using imagebuilder for now.

https://downloads.openwrt.org/releases/24.10.0/targets/ipq40xx/generic/packages/

itsthejb · February 6, 2025, 8:32am

Still building?

Azorean · February 6, 2025, 8:44am

Can't upgrade even via attended sysupgrade if running previous 24.10 RC7.

dugalex · February 6, 2025, 8:44am

Runs well on NanoPi R5C with a lot of extra packages installed including docker.

aboaboit · February 6, 2025, 8:54am

normally by the time of the announcement the builds should be all finished

eduperez · February 6, 2025, 9:11am

When your first comment was flagged, I think you should have realized that this is not the best attitude to get help around here.

This is an open source project, lead by volunteers on their free time. I think that these sarcastic comments are completely out of tone here.

zaggynl · February 6, 2025, 9:12am

Regarding the hardware with Atheros IPQ806X SoC, can you still manually export the config and import after the upgrade? Or run it through a converter script?

Azorean · February 6, 2025, 9:18am

On GL-iNet MT6000 using module BANIP can't load on luci the Overview page of it, displays a "Cannot read properties of undefined (reading 'trim')" Type Error. On logread no errors appear. Upgraded via sysupgrade from 23.05.5 and installed all modules from scratch.

grifo · February 6, 2025, 10:17am

With that attitude, that LAN port is likely to keep staying down for a while longer than it might otherwise have been. That's a probable fact.

And yes, I did think before writing, else you wouldn't be reading this text.

I'm not a developer, but if I were and I got that attitude back for my efforts, the last thing I would do is to expend any more efforts to solve your problem. That's a certain fact.

grifo · February 6, 2025, 10:25am

As I wrote, I'm not a developer, nor I own the hardware you have, else I'd try to help, if requested with a constructive attitude.

As it was, I was just putting some facts straight. I have a lot of respect for @eduperez as he's always extremely helpful and knowledgeable, so your post irked me. And I apologize to the community for my irked reply.

peterb99 · February 6, 2025, 10:34am

Installed on OpenWRT one device, noticed the following message in syslog

Noticed the following error in syslog
daemon.notice procd: /etc/rc.d/S95done: sh: write error: Invalid argument

Might be related to mount error messages I noticed earlier in the boot phase:

Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.542808] UBIFS (ubi0:5): un-mount UBI device 0
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.547527] UBIFS (ubi0:5): background thread "ubifs_bgt0_5" stops
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.557711] UBIFS (ubi0:5): Mounting in unauthenticated mode
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.563479] UBIFS (ubi0:5): background thread "ubifs_bgt0_5" started, PID 871
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.696996] UBIFS (ubi0:5): UBIFS: mounted UBI device 0, volume 5, name "rootfs_data"
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.704854] UBIFS (ubi0:5): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.714759] UBIFS (ubi0:5): FS size: 207859712 bytes (198 MiB, 1637 LEBs), max 1649 LEBs, journal size 10412032 bytes (9 MiB, 82 LEBs)
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.726834] UBIFS (ubi0:5): reserved for root: 4952683 bytes (4836 KiB)
Thu Feb  6 10:21:39 2025 kern.notice kernel: [   15.733439] UBIFS (ubi0:5): media format: w5/r0 (latest is w5/r0), UUID 6E6E1108-F45B-470E-9B69-753B8F24C838, small LPT model
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.070288] block: attempting to load /tmp/overlay/upper/etc/config/fstab
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.077165] block: unable to load configuration (fstab: Entry not found)
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.083977] block: attempting to load /tmp/overlay/etc/config/fstab
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.090352] block: unable to load configuration (fstab: Entry not found)
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.097084] block: attempting to load /etc/config/fstab
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.102411] block: unable to load configuration (fstab: Entry not found)
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.109141] block: no usable configuration
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.115844] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.123040] block: unable to load configuration (fstab: Entry not found)
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.129872] block: attempting to load /tmp/ubifs_cfg/etc/config/fstab
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.136374] block: unable to load configuration (fstab: Entry not found)
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.143120] block: attempting to load /etc/config/fstab
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.148397] block: unable to load configuration (fstab: Entry not found)
Thu Feb  6 10:21:39 2025 user.err kernel: [   16.155191] block: no usable configuration
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.160618] mount_root: overlay filesystem has not been fully initialized yet
Thu Feb  6 10:21:39 2025 user.info kernel: [   16.168984] mount_root: switching to ubifs overlay
Thu Feb  6 10:21:39 2025 kern.warn kernel: [   16.185816] overlayfs: null uuid detected in lower fs '/', falling back to xino=off,index=off,nfs_export=off

brada4 · February 6, 2025, 10:35am

It is this issue:

github.com/openwrt/openwrt

MSS clamping does not play nice with policy-based routing (mwan3, pbr)

opened 06:02AM - 03 Mar 23 UTC

closed 01:42PM - 03 Nov 23 UTC

patrakov

bug

### Describe the bug OpenWrt applies MSS clamping in the `firewall` and `firewa…ll4` packages, by hooking into the `FORWARD `chain of the `mangle` table, or its `nftables` equivalent. This is done on the assumption that locally generated SYN packets will never need their MSS fixed up - but I found a situation where this assumption is wrong, and packets with MSS=1460 are wrongly sent through the VPN. ### OpenWrt version 21.02.1 and 22.03.3 ### OpenWrt target/subtarget ath79/generic and mediatek/mt7622 ### Device TP-Link Archer C7 V2 and Linksys E8450 ### Image kind Official downloaded image ### Steps to reproduce Create a usual DHCP WAN connection, and a PPTP VPN. Set the metrics, as required by mwan3 which we will install at the next step: 80 on WAN, 90 on PPTP VPN. Assign both to the WAN firewall zone. At this point we have a default routing table with two default routes with different metrics, with the traffic going over WAN, because its default route has a lower metric. In the firewall settings, enable MSS clamping for the WAN zone. Install mwan3 and curl. Install luci-app-mwan3 if you want. Configure mwan3. The default policies that prefer wan over wanb, and wanb over wan, should be sufficient, when "wanb" is globally replaced with "vpn" in the config where it refers to the interface name. The default policy should be wan_wanb, thus preferring the WAN. Then create a rule in mwan3: if the destination IP is 139.59.209.225 (or whatever the current IPv4 address of openwrt.org is), then use the wanb_wan policy, thus preferring the VPN. Push the rule to the top, so that it is evaluated first. Delete the load-balancing rule. Save and apply. The result at this point should be that everything goes through the WAN, except 139.59.209.225, which goes through the VPN. The real use case is to have an ipset instead of the single IP, but for testing, a single IP will suffice. Then, on the router itself, while observing the resulting packets, run: ``` curl -4 https://openwrt.org/ ``` ### Actual behaviour The initial SYN packet indicates MSS=1460, despite the rule that fixes the MTU. If the VPN blackholes "Fragmentation Needed" packets, then the page won't load. ### Expected behaviour The initial SYN packet should have MSS clamped to 1360. ### Additional info Applying the MSS clamp in the POSTROUTING chain, in addition to FORWARD (or maybe instead of FORWARD?), would fix the issue. OUTPUT is not sufficient. Let's see why the wrong MSS exists in the first place, though. When determining the MSS for locally-created SYN packets, apparently, the kernel only looks into the default routing table. Indeed, this decision is made before running through iptables/netfilter, and therefore, the kernel cannot know that it will select a non-default routing table based on the not-yet-existing firewall mark. Therefore, as the default routing table clearly says "go through WAN, MTU=1500", it selects MSS=1460. The stock MSS-clamping rule is applied only on forward, but the packet is locally-originated, not forwarded, so it doesn't apply. End result: packet with MSS=1460 (which is wrong) goes out. The POSTROUTING chain of the mangle table would still catch it. ### Diffconfig _No response_ ### Terms - [X] I am reporting an issue for OpenWrt, not an unsupported fork.

Your referenced issue has no offloads involved, i dont think it has to do with anything adjustable by firewall config/rules.

badulesia · February 6, 2025, 10:39am

Successfull installed on a bunch of devices:

Netgear WNR3700v2, v4, R6220
Linksys EA7300v2
Cudy WR3000S

All running smoothly.
Thank you to everyone involved in the dev, testing for this major release.