build: upgrade OpenWrt base to 25.12 (kernel 6.12)#43
Open
ispyisail wants to merge 18 commits into
Open
Conversation
added 16 commits
July 9, 2026 21:40
branch_name/branch_id/packages_branch repointed from openwrt-24.10 to openwrt-25.12 -- confirmed the openwrt-25.12 branch exists in both openwrt/openwrt and openwrt/packages, matching build.sh's existing checkout convention exactly. openwrt_commit pinned to f0a60eee2f (the v25.12.5 tag's dereferenced commit, not branch head) for reproducibility -- same convention as the prior 24.10 pin. 24.10 security support ends 2026-09-05; this is Stage 1 of a two-stage bump (base first with USE_APK=n, apk flip separately) -- see docs/openwrt-2512-bump-plan.md in gargoyle-tools for the full track plan.
004-fix_postinst_prerm_scripts, 027-wireguard_tools_bump, and 101-gargoyle_ssid_override needed re-anchoring against the 25.12 tree (context drift, not logic changes). targets/mediatek/patches/001-uboot needed the same treatment: 25.12 dropped the --enable SERIAL_RX_BUFFER line the patch modified from UBOOT_CUSTOMIZE_CONFIG; re-derived against the new block, adds back both the enable and the 256-byte size.
…nned versions Discovered live during a real B2 build (Gargoyle's netfilter-match-modules integration script, netfilter-match-modules/integrate_netfilter_modules.sh, downloads the exact package-Makefile-pinned nftables/libnftnl source and re-applies package/.../patches/*.patch against it as part of preparing to layer Gargoyle's own custom NFT match modules on top) -- both patches failed against the real, current 25.12-pinned versions (nftables 1.1.6, libnftnl 1.3.1), non-fatally to the overall build but a real correctness gap worth fixing properly rather than ignoring. 023-nftables-remove-patch-files.patch deleted a stray tests/shell/ run-tests.sh.rej file that shipped in nftables' own 24.10-era source tarball. Verified directly against the real nftables-1.1.6.tar.xz: that file no longer exists in the tarball at all -- upstream's own release process cleaned it up. Nothing left for this patch to do. 024-backport_nftables_bitwise_mask_xor.patch backported a specific upstream libnftnl commit (12bd1aea5, Jeremy Sowden, "add new bitwise boolean attributes to nf_tables.h") into an older libnftnl's headers. Verified directly against the real libnftnl-1.3.1.tar.xz's include/linux/netfilter/nf_tables.h: every field this patch adds (NFT_BITWISE_MASK_XOR, NFT_BITWISE_AND/OR/XOR, the NFT_BITWISE_BOOL backwards-compat define, NFTA_BITWISE_SREG2) is already present natively. libnftnl 1.3.1 ships with zero patches at all in package/libs/libnftnl/patches/ once these two are removed. This is exactly the "check whether upstream absorbed the change natively" scenario from the 24.10 bump's own patch-024 lesson -- these two patches needed deleting, not re-deriving. Verified via a fresh v25.12.5 scratch clone + the real scripts/patch-kernel.sh: all 22 remaining patches apply clean, and the nftables/libnftnl patches/ directories end up containing only upstream's own native patches (3 for nftables, none for libnftnl) with nothing left over from us to fail.
On 24.10, USE_APK "depends on BROKEN" with no explicit default -- structurally unselectable, so no existing Gargoyle diffconfig ever needed to mention it. On 25.12, that "depends on BROKEN" is gone, replaced with "default y". An existing diffconfig that stays silent on USE_APK would pick up y automatically on a fresh make defconfig against the new base -- exactly the violation the whole two-stage bump strategy (base bump first with the legacy opkg backend unchanged, apk flip separately once #39's backend is proven on-target) depends on avoiding. Added "# CONFIG_USE_APK is not set" to all 9 diffconfig-format profiles across the 4 targets the ericpaulbishop#1028 port already converted (x86 x5 profiles, mediatek x2, ath79 x2, ipq40xx x1), alphabetically placed immediately before the existing USE_FS_ACL_ATTR line already present in every one of them. The 7 remaining full-config targets are untouched here -- they stay in their existing full-config form until B5 converts them against a real 25.12 buildroot, per the ericpaulbishop#1028 port's own original sequencing decision. Not yet verified that this override survives a real make defconfig against a genuine 25.12 buildroot -- that needs full feeds/toolchain setup and is the first thing the next phase (B2, x86 full build) must confirm.
…kage tree make defconfig -> scripts/diffconfig.sh -> byte-identical round-trip verify for each profile (default, alix, vnet-wifi, x64, x64-wifi), per the established ericpaulbishop#1028-port method -- never hand-edited. Every diff is explained by real 25.12-era Kconfig drift, confirmed via the resolved .config, not a functional change: - CONFIG_KERNEL_EROFS_FS_POSIX_ACL: new kernel option in 25.12's Config-kernel.in, resolves to off (matches every other *_POSIX_ACL default in these profiles). - CONFIG_PACKAGE_apk-mbedtls: new package (apk's own mbedtls crypto backend), resolves to off -- consistent with Stage 1's USE_APK=n. - kmod-video-async/kmod-video-cpia2/kmod-video-fwnode: these Kconfig symbols no longer exist anywhere in the 25.12 kernel tree (confirmed via grep -- upstream media-subsystem restructuring between 6.6 and 6.12), so the old "not set" lines were pure noise referencing nonexistent options. - ucode-mod-uloop / ucode-mod-digest: both remain enabled in the real resolved .config for every profile that had them before (confirmed via grep) -- diffconfig.sh's minimizer just picked a different implied-vs-explicit split of which lines are needed to reproduce the same resolved state, not a package selection change. - kmod-i2c-core (alix only): newly appears as an explicit `=y` line; also confirmed present and enabled in the resolved .config. CONFIG_USE_APK is not set survived in all 5 re-derived profiles, confirming Stage 1's diffconfig fix from B1 is still correctly resolved.
CMake 4.x (bundled in the 25.12 host toolchain) hard-rejects any package whose own CMakeLists.txt declares cmake_minimum_required below 3.5 (hit libid3tag, lzo; likely more packages carry the same old CMakeLists.txt pattern). Fixed globally via -DCMAKE_POLICY_VERSION_MINIMUM=3.5 in include/cmake.mk's target and host cmake invocations, rather than patching every package individually as each one surfaces.
…reakage
mbedtls-clu and https-dns-proxy: PKG_MIRROR_HASH no longer matches a
fresh git-archive of the exact pinned commit -- the archive-generation
mechanism itself changed between 24.10 and 25.12, not the source
content. Verified by re-checking out each pinned commit fresh and
confirming the new hash is reproducible. Updated the hash constants.
libffi: PKG_FIXUP:=autoreconf regenerates the build system with this
toolchain's newer host autoconf/automake, which introduces a
build-vs-host triplet mismatch ("No rule to make target
'all-configured'"). libffi 3.4.6's release tarball already ships a
working, upstream-tested ./configure; removed the fixup rather than
chasing the newer autoconf's behavior change.
unarchive.c calls seek_by_read() with no prior prototype (2007-era code extracted from busybox with the declaration left behind). GCC 14 (first used by this toolchain as of the 25.12 bump) makes implicit function declarations a hard error by default, where GCC <= 13 only warned -- breaking this package's build outright and, with it, image assembly for every x86 profile in the B2 full build. Same root cause and same fix already validated for the host-side gapk dev-loop build (tests/gapk/build-host.sh in gargoyle-tools); applying the identical workaround here rather than trying to source/restore the real prototype from 2007-era upstream busybox code.
package/zip's stock "generic" build target runs unix/configure's
feature-detection probes, which try to compile+link+run tiny test
programs -- impossible under cross-compilation, so every probe
silently assumes the worst and falls back to a batch of "-DNO_*"/
"-DZMEM" defines selecting zip's own bundled 2008-era K&R-style
fallback implementations (memset/mktime/etc), each guarded by a
hand-written prototype that assumes no real ANSI <string.h>/<time.h>
exists. musl provides working, conformant versions of every one of
these, so the whole batch has always been a false positive for this
cross build -- GCC <= 13 only warned about the resulting conflicts;
GCC 14 (new in this toolchain, 25.12) makes them hard errors
("conflicting types for 'memset'", "invalid use of undefined type
'struct tm'").
Split Build/Compile into two steps (generate flags, strip the whole
-DNO_*/-DZMEM batch, then build) instead of patching zip's own
Makefile/configure or whack-a-moling one define at a time as each
newly becomes a hard error. Added a matching Build/Install since the
override replaces the stock MAKE_FLAGS-based generic+install combo.
Verified via a real scoped compile: zip_3.0-r5_x86_64.ipk now builds
clean.
…nclude) Two unrelated GCC14-newly-fatal issues found compiling this legacy (3.6.25) samba build: - smbd/vfs.c: samba's own libreplace shim conditionally redefines mkdir(dir, mode) -> mkdir(dir) when its own configure probe decides the target's real mkdir() doesn't support a mode argument. That probe's test program (lib/replace's HAVE_MKDIR_MODE check) never includes <sys/stat.h>, so mkdir() has no visible prototype in the probe itself -- GCC <= 13 only warned on the resulting implicit declaration, letting the probe "succeed"; GCC 14 makes it a hard error, flipping the cached result to "no" and activating the 2-arg replacement macro. That macro then collides at the token level with an unrelated 3-arg handle->fns->mkdir(handle, path, mode) vfs member-function call elsewhere in the same file (C macros don't respect struct member access syntax). Fixed the same way this Makefile already works around many other broken cross-compile probes: supply the known-correct answer directly via CONFIGURE_VARS (libreplace_cv_mkdir_has_mode=yes), rather than patching samba's own probe source. - utils/owrt_smbpasswd.c (an OpenWrt-authored file, not upstream samba, created via patches/111-owrt_smbpasswd.patch): calls mdfour() with no declaration in scope anywhere it includes -- an implicit-declaration warning under GCC <= 13, a hard error under GCC 14. Added the missing `#include "../lib/crypto/md4.h"` (the same relative include path used elsewhere in this samba tree, e.g. rpc_server/netlogon/srv_netlog_nt.c) to the patch, bumping its new-file hunk header from +1,249 to +1,250 to match. Verified via a real full scoped compile: samba36-server_3.6.25-r14_x86_64.ipk now builds clean.
GCC 14 promotes incompatible-pointer-type from warning to hard error. Three real type mismatches surfaced across nft_bwctl.c, gargoyle_header_footer.c, and qosmon.c.
kernel 6.12 gates ip6_tables.ko behind the hidden select-only IP6_NF_IPTABLES_LEGACY symbol. CONFIG_IP6_NF_IPTABLES=m alone (all that kmod-nf-ipt6 sets) no longer builds it, so kmod-nf-ipt6 fails to package -- on every target, as the mediatek build just demonstrated. The IPv4 twin only works by accident: kmod-ipt-core's CONFIG_IP_NF_FILTER=m selects the IPv4 legacy symbol, and that package is in Gargoyle's set; no IPv6 equivalent is. Move the fix from target/linux/x86/config-6.12 to target/linux/generic/config-6.12 so every target gets it, and answer the open question left in the B2 notes about why IPv4 resolved =m.
…ps table nftables 1.1.6 (the version this OpenWrt base ships) resolves statement ops through a central switch in stmt_ops()/__stmt_ops_by_type() and BUG()s on any type missing from it, instead of reading the ops pointer stored in the statement as older versions did. Gargoyle's integration fragments define bandwidth/timerange/webmon/weburl statement ops but never added cases to that switch, so any ruleset containing one of these statements -- which is every Gargoyle default firewall; a stock config carries ~80 bandwidth/timerange statements -- made 'nft list ruleset' abort: BUG: Unknown statement type 10 Assertion failed: 0 (src/statement.c: stmt_ops: 1366) Rules still loaded fine (fw4 input goes through the parser, not this path); only listing/inspection crashed. Add one case per module to the switch via new meta insertions anchored after the STMT_REJECT case. Verified live: rebuilt libnftables side-loaded onto a vnet VM lists the full ruleset cleanly, exit 0.
nft_bandwidth declared 17 netlink attributes (NFTA_BANDWIDTH_MAX), one over the 16-attribute limit (NFT_EXPR_MAXATTR) that kernel 6.12 added to nft_register_expr(): WARN_ON_ONCE(type->maxattr > NFT_EXPR_MAXATTR). That check does not exist on kernel 6.6, which is why this only shows up on the 25.12 kernel bump. Confirmed by diffing net/netfilter/ nf_tables_api.c between the v6.6 and v6.12 kernel tags. The registration failure alone would just mean the module fails to load, but init() calls nf_register_sockopt() *before* attempting nft_register_expr(), and never rolled that back on failure. When a module's init() returns nonzero the kernel does not call its exit/ fini function and unloads the module's code -- leaving the kernel's global sockopt table (BANDWIDTH_SET=2048, BANDWIDTH_GET=2049) pointing at freed memory. Any later setsockopt/getsockopt on those commands (the exact interface Gargoyle's userspace bandwidth/quota tooling uses) jumps into that freed memory, and the resulting corruption lands wherever it lands -- in testing, consistently on ext4 metadata, producing "doubly allocated" / "deleted inode referenced" errors and an unbootable image. Root-caused and confirmed via QEMU monitor screendumps, module-by-module isolation, and a live serial-console insmod reproduction that surfaced the WARN_ON_ONCE with a full stack trace. Two changes: - init() now calls nf_unregister_sockopt() if nft_register_expr() (or the earlier id_map allocation) fails, before returning the error. This alone prevents the corruption regardless of attribute count, turning any future registration failure into a clean load failure instead of a dangling kernel function pointer. - Removed NFTA_BANDWIDTH_MINUTESWEST, bringing the attribute count to exactly 16. It was declared in the kernel-side parse policy but never actually read by init() or written by dump() -- dead on the kernel side. It did have real plumbing in the userspace libnftnl wire-format code (get/set/build/parse), which is now cleaned up to match; nothing in Gargoyle's own rule-generation scripts ever populated it. Kept the two enums (kernel header and the userspace wire-format copy in libnftnl/include_linux_netfilter_bandwidth.h) numerically synchronized, since a mismatch there would desync the netlink wire protocol between kernel and userspace. Verified: with only nft_bandwidth enabled, the vnet-wifi x86 image now boots clean on kernel 6.12.94 -- lsmod shows nft_bandwidth loaded and registered under nf_tables, no WARNING, no ext4 errors, apk writes succeed post-boot. Isolated confirmation that nft_webmon and nft_weburl were never affected by this bug (module-by-module boot testing, both clean independently).
Every AP left at its out-of-the-box default (country never explicitly configured) silently never reaches a real operating channel under 25.12 -- confirmed live: iwinfo shows Channel: 0/unknown, iw dev prints no channel/ssid line at all, and no client can ever scan or associate, even though hostapd's own process is running and the interface exists. Root cause, traced end to end: '00' is cfg80211's own generic/"world safe mode" regulatory-domain placeholder (confirmed via `iw reg get`: "country 00: DFS-UNSET"), not a real ISO country code -- but wireless.wifi-device.json's schema aliases UCI's 'country' field straight onto hostapd config's 'country_code' unconditionally (default: country_code), and separately defaults 'ieee80211d' (the 802.11d Country IE toggle) to true regardless of whether a real country is configured, even though the schema's own description says ieee80211d "Requires country". hostapd itself has been tightened (also part of this bump) to hard-reject country_code=00 combined with ieee80211d=1 as invalid -- confirmed directly: running the exact generated config standalone gets "Invalid country_code '00' / Cannot enable IEEE 802.11d without setting the country_code" and refuses to start. netifd's newer global multi-BSS hostapd daemon doesn't propagate that failure as a hard error though -- it silently leaves the BSS half-configured (interface/SSID/encryption present, channel never set), which is why every symptom looked like "the AP sort of exists but never really works" rather than an obvious startup crash. This is not hwsim/vnet-specific: Gargoyle's own wireless UI (basic.js) never sets a country code, and UCI's own default leaves it at '00' on first boot, so any real router where the admin enables WiFi without separately configuring an advanced country setting would hit this identically. Fixed in wifi-scripts' own hostapd.uc: device_country_code() already had an early-return guard for "no country_code set", gated only on existence -- extended it to also treat the '00' placeholder as "unset", matching the schema's own documented intent. Verified via a real end-to-end test: after the fix, a freshly-enabled AP with country left at '00' reaches a genuine operating channel (iwinfo: Channel: 6, Tx-Power: 20 dBm) and a real client completes full WPA2 association (wpa_supplicant: CTRL-EVENT-CONNECTED).
…25.12
The rewritten ucode iwinfo CLI broke two things check_sta()/
get_scan_results() depended on:
- iwinfo <iface> scan fails outright ("Netlink error while awaiting
scan results: No event received"), even on a real, already-up
interface. Separately, a disabled=1 wifi-iface now produces zero
kernel interface at all under this netifd (unlike 24.10), so there's
nothing to scan against in the idle case either way, and a live STA
interface is already owned by netifd's global wpa_supplicant, which
refuses a second externally-triggered scan on the same vif.
get_scan_results() now scans through a short-lived, daemon-independent
interface created directly on the phy with plain `iw`, parsing `iw
scan`'s block-structured text output instead of iwinfo's.
- iwinfo <iface> info keeps reporting the last-associated ESSID after a
real disconnect, confirmed live against `iw link` and `wpa_cli status`
(both correctly show the link is gone) while iwinfo stayed wrong for
150+ seconds. check_sta()'s old "unknown" substring check never
caught this, since the degraded fields it inspected print "0", not the
literal word "unknown". check_sta() now derives connected state and
signal quality from `iw dev <iface> link` directly.
Verified live end to end: real association, real failover after
killing the active AP, and real blacklisting on repeated auth failure
all now complete within their expected budgets (vnet phase 19, 5/5).
This was referenced Jul 9, 2026
Closed
added 2 commits
July 10, 2026 21:27
The comment in 031 claimed hostapd "now" hard-rejects country_code=00 combined with ieee80211d=1. Both halves were wrong, as flagged in review: hostapd has rejected any country_code with characters outside A-Z at config-parse time since 2.10 (2022) -- see the Feb 2022 "Invalid country_code '00'" hostap list threads -- and that rejection is unconditional. The "Cannot enable IEEE 802.11d without setting the country_code" error observed in testing is a follow-on (the rejected line leaves the country empty while ieee80211d=1 is still present), not the trigger. What actually changed in 25.12 is the generation side: a radio left at its out-of-the-box default now ends up with country '00' in UCI, and the ucode wifi-scripts schema (wireless.wifi-device.json) aliases 'country' straight onto 'country_code', handing hostapd a config it has always refused. The old shell path had the same -n guard but never saw a '00' in UCI, which is why 24.10 never hit this. Comment-only change; the code hunk is identical. Re-verified the patch still applies cleanly against pristine hostapd.uc (reverse/forward round-trip).
Reconciles Michael's V2 netfilter patches (derived against a pre-25.12 tree) with this branch, which had independently landed about half of them (statement-ops registration in 0bbaf23; the sockopt cleanup and .owner in 327a8eb). Three parts: 1. Switch the kernel-6.12 nft_bandwidth registration fix from attribute-removal to a maxattr bump, partially reverting 327a8eb. That commit dropped NFTA_BANDWIDTH_MINUTESWEST to get the attribute count under kernel 6.12's new WARN_ON_ONCE(type->maxattr > NFT_EXPR_MAXATTR) [16] in nft_register_expr(). Michael's approach keeps the attribute (restored here across the kernel header, both libnftnl wire-format enums, and the userspace get/set/build/parse plumbing) and instead raises NFT_EXPR_MAXATTR to 17. NFT_EXPR_MAXATTR is a kernel-internal sizing constant (bounds a fixed-size on-stack netlink attribute array), not uAPI, so the bump carries no wire-format risk. The mechanism is general: a module ships an optional "maxattr" file naming the ceiling it needs, and integrate_netfilter_modules.sh patches nf_tables.h to at least that value (nf_tables.h is added to the generated-patch file walk so the bump actually lands in 650-custom_netfilter_match_modules.patch). 327a8eb's sockopt-cleanup-on-failed-init, which prevents the dangling-sockopt rootfs corruption regardless of attribute count, is kept -- both approaches want it. 2. Build-warning cleanups for the newer toolchain: libxt_bandwidth.c drops its local ipany typedef for the header's own union xt_bandwidth_ipany and casts %lld printf args to (long long); libxt_webmon.c gains unistd.h; the iptables weburl regexp.c renames its END opcode macro to P_END (collision under newer kernel headers) and regexp.h declares my_strcspn; xt_webmon.c, xt_weburl.c and the three nft_* modules gain forward declarations for their non-static functions. nft_webmon's init() now removes its /proc entries if nft_register_expr() fails, mirroring the bandwidth sockopt cleanup: on a nonzero init() return the kernel unloads the module without calling fini(), and the stale proc file ops would point into freed memory. 3. Rename the nftables modules' bundled dependency dirs to nft_<name>_deps (bandwidth/webmon/weburl) so they can't collide with their iptables counterparts' identically-named dirs, updating the module includes to match. Verified: full x86.vnet-wifi firmware build from this tree, then the complete vnet simulator suite -- all three sites boot clean on kernel 6.12 with nft_bandwidth registered (lsmod-visible, no WARN_ON, no ext4 corruption -- the exact failure mode 327a8eb diagnosed), and the bandwidth/quota, webmon and weburl paths exercised by the suite pass. NFTA_BANDWIDTH_MAX lands at exactly 17 (= the PAD index = the declared .maxattr), matching the shipped maxattr ceiling.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upgrades the OpenWrt base from 24.10 to 25.12 (v25.12.5, kernel 6.12.94). Supersedes PR #41, which was reverted (see below) — this is a curated reland of the same underlying work, scoped to the bump itself.
What changed since #41
PR #41 mixed the bump with an unrelated in-progress feature (gpkg apk-backend work) and some debugging-journey commits that shouldn't have been in reviewed history, and it merged before all four primary targets were verified — mediatek/ath79/ipq40xx all failed to build on it. This PR is the same bump content, scoped down to just the bump, with every fix backed by a real, provable root cause, and all four primary targets build clean before this is proposed for merge.
The unrelated work from #41 will land as separate, independently reviewable PRs: the gpkg apk-backend integration, a netfilter warning-only cleanup, a defensive NULL-guard fix, and a build-script error-reporting improvement.
Base bump and patch re-derivation
Pin to OpenWrt 25.12 (v25.12.5); re-derive patches 004/027/101 and the mediatek uboot serial-rx-buffer patch against the new tree; drop patches 023/024 (absorbed upstream); force USE_APK=n in profile diffconfigs (gpkg remains the package manager); re-derive the x86 diffconfigs.
GCC 14 / new-toolchain build fixes
Fixes for implicit-function-declaration, incompatible-pointer-type, macro collisions, CMake 4's stricter
cmake_minimum_requiredenforcement, and cross-compile probe failures across libbbtargz, libnftbwctl, zip, samba36, gargoyle/qos-gargoyle, mbedtls-clu, https-dns-proxy, and libffi.Runtime bugs exposed by the new kernel/userspace (found via the vnet simulator)
nft_register_expr().init()didn't roll back its earliernf_register_sockopt()on that failure, leaving the kernel sockopt table pointing at unloaded module code — any later sockopt call (Gargoyle's own bandwidth tooling) jumped into freed memory, manifesting as unbootable ext4 corruption. Fixed by unregistering the sockopt on failure and dropping the unusedNFTA_BANDWIDTH_MINUTESWESTattribute.nft list rulesetaborted on every box. nftables 1.1.6 resolves statement ops through a central switch thatBUG()s on unknown types, replacing the old ops-pointer mechanism. The bandwidth/timerange/webmon/weburl statement integrations now register their cases. Rule loading was unaffected; listing crashed once any bandwidth statement existed — which is every stock config.Verification
All four primary targets:
FULL_BUILD=truefrom-scratch, zero errors, images produced.nft list rulesetverified exit-0 with live bandwidth statements rendering correctly.kmod-nf-ipt6packaged on both.Remaining targets (bcm27xx, bcm47xx, ipq806x, mvebu, ramips, rockchip) were not touched in this bump and keep their existing 24.10-generation full configs, per the existing project convention of only converting a target once a buildroot exists to verify against.