BUILD_CFG_DISTCLEANtrueBUILD_CFG_DIFFCONFIGtrueBUILD_CFG_TARGET_DEVWR8750N/WR9500N/WG600HP (AR9344)ユーザーmusashino205が実行tofumusashino205502938f67a519de64dcec10759b2b7203aca086f97a938f67a519de64dcec10759b2b7203aca086f97arefs/remotes/origin/main938f67a519de64dcec10759b2b7203aca086f97a938f67a519de64dcec10759b2b7203aca086f97arefs/remotes/origin/main938f67a519de64dcec10759b2b7203aca086f97a938f67a519de64dcec10759b2b7203aca086f97arefs/remotes/origin/mainhttps://github.com/openwrt/openwrthttps://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/lastFailedBuild/artifacthttps://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/changeshttps://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/lastFailedBuild/https://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/lastFailedBuild/testReportfalsediffconfig: true, device: WR8750N/WR9500N/WG600HP (AR9344)#50262381655647OpenWrt (master) for NEC Aterm (NetBSD based) #502502falsefalse50267FAILURE1790936945341https://taiha.net/jenkins/view/all/job/OpenWrt-master-NEC-BSD-Aterm/502/home-slave02_taihasv- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.cfa38466dc8f93996262550f28d2ea642220205ca1790832511000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: rtl930x: build the whole IPv6 network mask
otto_l3_930x_net6_mask() writes the leading all-ones bytes and the
partial byte after them, and leaves the rest of the address alone. Both
callers hand it an uninitialised struct, so the partial byte is OR-ed
into whatever the stack held there and every byte past it keeps that,
and the route is programmed with a mask nobody chose. At a prefix length
of 128 the partial byte is s6_addr[16], one past the end of the address.
Neither can happen today, because no IPv6 route reaches a writer and the
function has never run. Fix it before one does.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25507
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:28:31 +0200fa38466dc8f93996262550f28d2ea642220205carealtek: l3: rtl930x: build the whole IPv6 network maskedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c1f802c9c75f5da9b2f8dbf5151c02cf5d34f04ef1790832511000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: rtl930x: complete the IPv6 route lookup key
The CAM search key of otto_l3_930x_route_lookup_hw() is built from two
fields, and the IPv6 side gets both wrong. The entry type belongs in
bits 20:19 of L3_HW_LU_KEY_CTRL, which is where the clear mask points,
but the value is written unshifted: the search would run as IPv4 and a
stray bit would land in the VID field below. The destination is written
as the top word of the address four times over, so three quarters of an
IPv6 address never reach the key.
The field position is the one the GPL SDK gives for ENTRY_TYPE, and the
SDK masks the destination with its prefix before writing the key, which
is what ipv6_addr_prefix() does here. A route with an IPv4 destination
is unaffected: its entry type is zero, so the unshifted write was a
no-op, and its branch is untouched.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25507
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:28:31 +02001f802c9c75f5da9b2f8dbf5151c02cf5d34f04efrealtek: l3: rtl930x: complete the IPv6 route lookup keyedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.cace2caa02c9d1d669111ce5cfb1e3e50e91914ff1790832511000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: count prefix route rows per address family
The hardware answers a prefix lookup with the lowest matching row and
the lookup carries the entry type, so each address family wants its own
run of rows, sorted by prefix length: that is how the vendor SDK lays
the table out, IPv4 from the bottom and IPv6 from the top
(dal_longan_l3.c), and how IPv6 prefix routes are to be placed here.
The row bookkeeping cannot express that yet. It counts every placed
prefix route and renumbers every one at or below an insertion point,
without looking at the family, so inserting into one run would shift
rows belonging to the other and leave the list naming rows that no
longer hold those routes.
Nothing changes while every route that gets a row is IPv4 unicast, which
is what the next hop update writes into every route it programs.
Assisted-by: Claude:claude-opus-5
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25507
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:28:31 +0200ace2caa02c9d1d669111ce5cfb1e3e50e91914ffrealtek: l3: count prefix route rows per address familyedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c655b49fda24cee98a6fafc9443eebc42362676bb1790832511000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: key routes on a 16-byte gateway address
Routes are grouped by the gateway they use, so that resolving one
neighbour reprograms every route behind it. The key is four bytes wide,
which is the whole of an IPv4 gateway and a quarter of any other kind,
and the field is read nowhere else: it never reaches a register, and
what the hardware is given is the next hop MAC the resolution produced.
Widen it to a full address and store an IPv4 gateway v4-mapped. Within
one family the mapping is injective, so two IPv4 gateways share a key
exactly when they shared one before, including the connected routes that
arrive with no gateway at all and go on sharing a single one; mapping
instead of zero-extending is also what keeps that shared key distinct
from the all-zero address a gateway of another family can carry.
What a wider key cannot do is say which family a gateway belongs to. An
IPv4 gateway written v4-mapped is a valid IPv6 gateway, and the kernel
accepts one on an IPv6 route, so a single key can name two neighbours
that are looked up in different tables and answer with different
addresses. The routes behind a key are therefore reprogrammed, and a
delete matched, only for the family the event came from.
The allocators and the next hop update take the gateway by address
rather than by value, so the compiler refuses a bare address of the
wrong width where one enters them. The raw lookup in the delete path
takes a void pointer and gets no such help; it is fed the same mapped
address its route was keyed on. The one message of the next hop update
that names a gateway to the user reads the IPv4 address back out of the
mapped one, so it prints what it printed before.
Assisted-by: Claude:claude-opus-5
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25507
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:28:31 +0200655b49fda24cee98a6fafc9443eebc42362676bbrealtek: l3: key routes on a 16-byte gateway addressedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.h
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c651cde72f10875d16ece30a5704156948880467f1790832511000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: keep the address family a route was added with
Programming a route once its gateway resolves stamps the entry type of
an IPv4 unicast route over whatever the route was added as, and builds
the destination match of the PIE rule from the IPv4 destination and a
mask made by shifting a word by 32 minus the prefix length.
The type the add handler set is the one the writers have to see, and a
prefix length that is not an IPv4 one has no such mask. Keep the first
and build the second only for the family it belongs to. The rule fields
are read only where the L3 tables do not carry the destination, and
there every route is IPv4 unicast, which is also why dropping the stamp
changes nothing today.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25507
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:28:31 +0200651cde72f10875d16ece30a5704156948880467frealtek: l3: keep the address family a route was added withedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c174b87e3e84e338da9ffafca29ea9dde40c6f3a91790832511000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: tell two gateways of one address apart
The routes waiting on a gateway are keyed on the gateway address alone,
so the neighbour that answers writes its MAC into every route that names
that address, whichever link the route leaves by. The neighbour table is
keyed on the device as well as the address, for the reason that one
address on two links is two neighbours.
Keep the device a route reaches its gateway on, and let a neighbour
update touch only the routes that were resolved on it. The device is
kept as an index and not a pointer: the work item runs long after the
event and holds no reference to anything.
A route whose gateway answers on the route's own nexthop device is
unaffected, which is every route whose gateway is reachable the way the
kernel was told it is. What changes is the route whose neighbour answers
somewhere else: it took the MAC of whichever neighbour of that address
answered last, and now it waits for the one on its own device, which is
the neighbour the kernel forwards through. IPv4 gets there through a
link-scope route for the gateway on a second device, through a second
routing table, or through RTNH_F_ONLINK out of a device the gateway is
not on - fib_check_nh_v4_gw() resolves the gateway with the nexthop
device and table of the route being added, so each of those validates.
Which switches run this at all: the RTL839x, whose L3 setup is not
behind the RTL930x offload symbol, and an RTL930x built with that
symbol, which none of the six subtarget configs sets. The RTL838x and
RTL931x have no setup, so their notifiers return on the missing one.
Assisted-by: Claude:claude-opus-5
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25507
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:28:31 +0200174b87e3e84e338da9ffafca29ea9dde40c6f3a9realtek: l3: tell two gateways of one address apartedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.h
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/mirror.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.htarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/dsa.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl838x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl839x.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/Makefiletarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/mirror.ctarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.c82961d51cb1e1cbf64da727d8f9fb82324a4ef261790833244000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: move port mirroring into dedicated files
Port mirroring is spread across dsa.c and the four chip-specific files.
Consolidate it in mirror.c to continue organizing the driver by function.
Move the DSA mirror callbacks and chip-specific configuration helpers into
mirror.c. Add mirror.h for their declarations and rtldsa_mirror_config,
and include mirror.o in the driver build.
Keep the existing operation tables, per-switch state and locking.
No functional changes intended.
Assisted-by: ChatGPT (OpenAI GPT-6 Astra)
Link: https://github.com/openwrt/openwrt/pull/25512
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:40:44 +020082961d51cb1e1cbf64da727d8f9fb82324a4ef26realtek: dsa: move port mirroring into dedicated filesedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl838x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl-otto.hedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl839x.caddtarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/mirror.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/Makefileedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl931x.cedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/dsa.caddtarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/mirror.h
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.cc1b3943aa367e839030bf1185b44548e6a9f3e741790833244000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: dsa: remove commented-out rtl930x_l3_intf_add
Remove the unused and incomplete rtl930x_l3_intf_add implementation.
The function is entirely commented out and has no active callers.
Active egress interface allocation is handled by otto_l3_alloc_egress_intf
in l3.c, although it does not implement the old dynamic MTU allocation.
No functional changes.
Assisted-by: ChatGPT (OpenAI GPT-6 Astra)
Link: https://github.com/openwrt/openwrt/pull/25512
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 07:40:44 +0200c1b3943aa367e839030bf1185b44548e6a9f3e74realtek: dsa: remove commented-out rtl930x_l3_intf_addedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/rtl930x.c
- target/linux/generic/hack-6.12/970-mux-expose-core-config.patchtarget/linux/generic/hack-6.18/970-mux-expose-core-config.patch31ef8052449426249b8ea364444df9adab80bfef1790855866000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comgeneric: make multiplexer core config visible
All of the mux kmods depend on CONFIG_MULTIPLEXER being set, however its
currently tristate but with no user visible name so its not selectable by
passing it .config.
It can only be selected by other symbols, so when you select for example
GPIO mux kmod in reality nothing is built unless your target already
selects CONFIG_MULTIPLEXER by accident or ALL_KMODS is used.
So, as a workaround since it still works fine as tristate, simply add a
patch that makes it visible and thus user selectable.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
2026-10-01 13:57:46 +020031ef8052449426249b8ea364444df9adab80bfefgeneric: make multiplexer core config visibleaddtarget/linux/generic/hack-6.12/970-mux-expose-core-config.patchaddtarget/linux/generic/hack-6.18/970-mux-expose-core-config.patch
- target/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl838x_eth.cdb61fd4444566302151248926018d1e3fc55521c1790876616000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: eth: check TX descriptor availability before padding skb
rteth_start_xmit() pads the skb before checking whether the TX
descriptor is still owned by hardware. If it returns NETDEV_TX_BUSY,
the networking stack retries transmission with the modified skb.
This can add FCS space repeatedly or prevent detection of a padded
DSA trailer on subsequent attempts.
Move DSA port detection and padding after the descriptor ownership
check so that the skb remains unchanged when returning NETDEV_TX_BUSY.
Assisted-by: ChatGPT (OpenAI GPT-6.1 Sol)
Link: https://github.com/openwrt/openwrt/pull/25519
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 19:43:36 +0200db61fd4444566302151248926018d1e3fc55521crealtek: eth: check TX descriptor availability before padding skbedittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl838x_eth.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.ce59089db5fc9e576d772c61f18610eaeaa331de31790876997000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: skip IPv4 routes without a nexthop device
A blackhole, unreachable or prohibit route has no device behind its
nexthop: fib_create_info() refuses one for these types and skips the
nexthop check that would find one, so fib_nh_dev stays NULL.
otto_l3_fib_add_v4() hands that device to is_vlan_dev() before any
test, and otto_l3_fib_check_v4(), which the delete path runs as well,
does the same in its variable initialisers. On an RTL9303 with the L3
offload built in, "ip route add blackhole 10.99.8.0/24" oopses in the
rtl83xx work queue and panics the box:
CPU 0 Unable to handle kernel paging request at virtual address
00000000, epc == 8070fe3c, ra == 80710594
Workqueue: rtl83xx otto_l3_fib_event_work_do
epc : 8070fe3c otto_l3_fib_add_v4+0x1c0/0x794
Kernel panic - not syncing: Fatal exception
The faulting load is the priv_flags word is_vlan_dev() tests. Such
routes are common on a router, for address space it announces but does
not use.
Handle them where a route through a nexthop object is already handled,
for the same reasons: there is nothing to offload, and the route can
still replace one that was, so the entry for its destination is taken
out, and a host route is trapped where the host table can hold it. The
delete path takes the same exit.
Tested on an RTL9303 (Hasivo S1100W-8XGT-SE) with the L3 offload built
in. Without this change the command above panics the box; with it, a
blackhole /24 stays in the kernel with no entry in hardware, an
offloaded /24 replaced by a blackhole loses its entry and gets it back
when replaced through the gateway again, a blackhole /32 gets a trap
entry in the host table, unreachable and prohibit routes go in as
well, and every delete leaves no entry and no oops. RTL839x, which runs
this code in a stock build, was not tested.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25513
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 19:49:57 +0200e59089db5fc9e576d772c61f18610eaeaa331de3realtek: l3: skip IPv4 routes without a nexthop deviceedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- tools/firmware-utils/Makefile3746b9b3075209db66bee0800ebbacad7e6ef7b51790879381000https://taiha.net/jenkins/user/mailmailmail@aparcar.orgtools: firmware-utils: update to Git HEAD (2026-09-30)
fac587ee67d5 mkzynfw: add board profiles for Zyxel XGS2220 series
a0177f9b3bba mkzynfw: align RTL_OTTO_BOARD definitions
ceaf0f9c1e22 mksenaofw: warn instead of erroring on plain type-0 images
71f8d9a9a22a asusuimage: fix fs_offset extraction in show_info
9cf0f6e00e39 zyimage: make output byte order explicit
a1d9589f1ea1 dlink-sge-image: initialize the signature length
Link: https://github.com/openwrt/openwrt/pull/25517
Signed-off-by: Paul Spooren <mail@aparcar.org>
2026-10-01 20:29:41 +02003746b9b3075209db66bee0800ebbacad7e6ef7b5tools: firmware-utils: update to Git HEAD (2026-09-30)edittools/firmware-utils/Makefile
- package/network/config/wifi-scripts/files-ucode/usr/share/ucode/wifi/ap.uc4fed8d3c79830a04038f362a47eec3b58beea7a61790879658000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comwifi-scripts: enforce WPA3 for all encryption types on 6 GHz
The existing 6 GHz auth_type override only covers mixed modes
(psk-sae, eap-eap2), upgrading them to their WPA3 equivalents.
However, if a user configures pure WPA2 (psk or eap) on a 6 GHz
radio, the configuration falls through unchanged and hostapd rejects
it with a confusing error about invalid AKM suite.
Extend the override to also cover pure WPA2 modes:
- psk / psk-sae -> sae
- eap / eap-eap2 -> eap2
This matches the existing silent-upgrade pattern and ensures the
radio comes up regardless of which legacy encryption the user
selected.
Signed-off-by: Michael Pfeifroth <micpf@westermo.com>
Link: https://github.com/openwrt/openwrt/pull/23914
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-10-01 20:34:18 +02004fed8d3c79830a04038f362a47eec3b58beea7a6wifi-scripts: enforce WPA3 for all encryption types on 6 GHzeditpackage/network/config/wifi-scripts/files-ucode/usr/share/ucode/wifi/ap.uc
- package/network/services/hostapd/src/src/ap/ucode.c909be7c9fae643ec5c24f81e2041db468eb52c191790886595000https://taiha.net/jenkins/user/nbdnbdnbd@nbd.namehostapd: build the DPP frame link choice without IEEE 802.11be
hostapd_dpp_freq_bss() reads hapd->conf->mld_ap, which exists only
with CONFIG_IEEE80211BE, so ucode.c did not build without it. Without
it there is no AP MLD, and the BSS the caller reached answers.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-10-01 22:29:55 +0200909be7c9fae643ec5c24f81e2041db468eb52c19hostapd: build the DPP frame link choice without IEEE 802.11beeditpackage/network/services/hostapd/src/src/ap/ucode.c
- package/network/services/ustp/files/ustpd.init4850397f5e40d4316d34364fb5b99c4e54d23ec51790886595000https://taiha.net/jenkins/user/nbdnbdnbd@nbd.nameustp: let ustpd write core dumps
Helps with debugging
Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-10-01 22:29:55 +02004850397f5e40d4316d34364fb5b99c4e54d23ec5ustp: let ustpd write core dumpseditpackage/network/services/ustp/files/ustpd.init
- package/network/services/hostapd/src/src/ap/ubus.cc909828ca3f084c0670888ef1119d7857ec3dfaf1790886595000https://taiha.net/jenkins/user/nbdnbdnbd@nbd.namehostapd: ubus: count a reference only for a BSS object that was added
hostapd_ubus_add_bss() counted a reference to the ubus context whether
ubus_add_object() succeeded or not, and hostapd_ubus_free_bss() drops
one only for an object with an id. Every BSS whose object could not be
added, such as each further link of an AP MLD, which all ask for the
same name, kept the context referenced after it was freed. Count the
reference only where the object was added.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-10-01 22:29:55 +0200c909828ca3f084c0670888ef1119d7857ec3dfafhostapd: ubus: count a reference only for a BSS object that was addededitpackage/network/services/hostapd/src/src/ap/ubus.c
- package/base-files/files/lib/upgrade/nand.sh3f26ab3d4d973fdbd3a1593a68e8186f5cc58dbd1790886595000https://taiha.net/jenkins/user/nbdnbdnbd@nbd.namebase-files: keep kernel and rootfs UBI volume IDs with provisioning
Since sysupgrade creates the provisioning volume by default, it takes the
lowest free volume ID before the kernel and rootfs volumes are created.
This shifts their IDs by one, so devices that hardcode the rootfs volume
in root= (e.g. root=/dev/ubiblock0_1) no longer boot after a sysupgrade.
Create the provisioning volume with the last volume ID instead.
A provisioning volume that already exists at a low ID is kept and has to
be removed by hand.
Fixes: 725a1dc534a1 ("base-files: create the provisioning partition on sysupgrade by default")
Fixes: https://github.com/openwrt/openwrt/issues/25501
Signed-off-by: Johan Alvarado <contact@c127.dev>
2026-10-01 22:29:55 +02003f26ab3d4d973fdbd3a1593a68e8186f5cc58dbdbase-files: keep kernel and rootfs UBI volume IDs with provisioningeditpackage/base-files/files/lib/upgrade/nand.sh
- target/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl838x_eth.ceb04f721f5d32595760a66f4830c53af111e180b1790919477000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: eth: fix RTL931x L2 MAC register
The RTL931x L2 MAC register points to the wrong offset.
Fix it.
Fixes: fb6e2568d ("realtek: eth: refactor rteth_set_mac_hw()")
Assisted-by: ChatGPT (OpenAI GPT-6.1 Sol)
Link: https://github.com/openwrt/openwrt/pull/25523
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-02 07:37:57 +0200eb04f721f5d32595760a66f4830c53af111e180brealtek: eth: fix RTL931x L2 MAC registeredittarget/linux/realtek/files-6.18/drivers/net/ethernet/realtek/rtl838x_eth.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c9b4be03f54c466420d3c375a9f87100a676005a21790919544000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: move the per-route next hop work into a helper
otto_l3_nexthop_update() programs every route behind a gateway in one
loop body that has grown to a hundred lines. Move that body into
otto_l3_route_update_hw(), which writes one route to the hardware, and
leave the update to find the routes and call it.
The body moves as it was. A route it gives up on now returns instead of
continuing the loop, and the gateway it prints is the route's own, which
the loop has just compared equal to the one it was given. No functional
change.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25524
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-02 07:39:04 +02009b4be03f54c466420d3c375a9f87100a676005a2realtek: l3: move the per-route next hop work into a helperedittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- target/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c721ab83af6fd77c0f14685a4312a56fd0c18c3ae1790919545000https://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausen@gmx.derealtek: l3: trap routes whose gateway lost its neighbour
The neighbour notifier drops every update that is not NUD_VALID, so once
the kernel has given up on a gateway - its entry failed to resolve, or
was deleted - the routes behind it keep forwarding in hardware to the
address it last answered from. The sender is never told the gateway is
gone, and the kernel never sees the traffic that would let it notice.
Queue those updates as well, and turn every route the hardware holds
for that gateway into TRAP2CPU, with the TTL bits clear like a route
trapped for want of a port. The CPU then resolves the gateway again, and
the update that brings a valid neighbour programs the route as before,
or it reports the gateway unreachable. A route never written stays as
it is. mlxsw does the same: it stops offloading a next hop whose
neighbour is not valid, and a route left without one traps.
An entry taken out of the table - flushed with its device, or collected
while stale - is marked dead and can keep a NUD_VALID state, so a dead
neighbour counts as not valid too, as it does for mlxsw. The state, the
dead flag and the address are read under the neighbour's lock. On a
table large enough for the periodic collection to run (gc_thresh1, 128
entries by default), the entry of a gateway that only the hardware
sends to goes idle and is collected after gc_stale_time; its routes then
pass through the CPU until the next packet resolves it again.
The RTL839x routes through PIE rules and keeps them as they are, as it
does for a next hop without a port. Its notifier now queues the invalid
updates too, which find nothing to write.
Tested on an RTL9303 with a /24 and a /32 through one gateway that stops
answering ARP until the switch's kernel marks it FAILED. Without this
change both rows stay at forward and the gateway still receives every
echo request; with it both rows trap, none reaches the gateway, and the
sender gets Destination Host Unreachable. Once the gateway answers
again, or after an ip neigh del and the traffic that follows, both rows
are back at forward. With the collection thresholds lowered until the
gateway's stale entry is collected, both rows stayed at forward before
the dead flag was tested and trap with it, back at forward with the
next traffic; a down and up of the gateway's interface, which flushes
its neighbours under the table lock, runs clean. The RTL839x was not
tested.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25524
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-02 07:39:05 +0200721ab83af6fd77c0f14685a4312a56fd0c18c3aerealtek: l3: trap routes whose gateway lost its neighbouredittarget/linux/realtek/files-6.18/drivers/net/dsa/rtl83xx/l3.c
- target/linux/kirkwood/image/Makefile7ca89e074d70bd13091a58a04408c1f7e52b81f41790927533000https://taiha.net/jenkins/user/mailmailmail@aparcar.orgkirkwood: store the Ctera firmware members as root
The sysupgrade image of the Ctera C200 V1 differs between builds in the
user and group names of the tar members:
--rw-r--r-- 0 buildbot (1000) buildbot (1000) 175 ... header
+-rw-r--r-- 0 rebuilder (1000) rebuilder (1000) 175 ... header
ctera-firmware sets the mtime of the members, but not their owner, so
the name of the build user ends up in the image. mvebu fixed the same
recipe in commit 0d42a1258f ("mvebu: improve reproducibility of ctera
firmware"); store the members as root here too.
Link: https://github.com/openwrt/openwrt/pull/25525
Signed-off-by: Paul Spooren <mail@aparcar.org>
2026-10-02 09:52:13 +02007ca89e074d70bd13091a58a04408c1f7e52b81f4kirkwood: store the Ctera firmware members as rootedittarget/linux/kirkwood/image/Makefile
- package/firmware/ipq-wifi/Makefilec2eb687d76a04bd66e45fdb2e47998f8f0f565b01790929174000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comipq-wifi: update to Git HEAD (2026-10-01)
73091ab6bf52 ci: safely handle changed BDF lists
133ced5d9165 ci: pin BDF workflow dependencies
f4123f64c204 ci: cancel superseded BDF workflow runs
5a222aea811f ci: comment BDF details on pull requests
e7026095be09 ci: parse IPQ9574 BDF files
033d9392777e ci: initialize BDF artifact path at runtime
0fd886523d7c ci: parse ipq9574 BDF as ath11k
dc51f4c40621 ci: skip BDF comments without an artifact
b8e840138fa9 ci: resolve PRs from workflow-run metadata
9a202b023de2 qcn9274: add TP-Link Archer BE800 BDF
dd938a6a367f kiwi: update BDF to v5
6a0f508b9ce3 add TP-Link RE700X board files
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-10-02 10:19:34 +0200c2eb687d76a04bd66e45fdb2e47998f8f0f565b0ipq-wifi: update to Git HEAD (2026-10-01)editpackage/firmware/ipq-wifi/Makefile
- target/linux/generic/backport-6.18/441-v7.4-spi-spi-qpic-snand-publish-the-ECC-context-to-snandc.patche7eaa9851ff15f7a582132de2f9d05e283fe382f1790932170000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comgeneric: backport spi-qpic-snand stale ECC pointer fix
qcom_spi_ecc_init_ctx_pipelined() installs the ooblayout but never
publishes the ECC context it allocates, and the cleanup path frees that
context without clearing snandc->qspi->ecc. The ooblayout callbacks then
run against a stale pointer.
On IPQ5018 the qcom,smem-part parser makes the first spi-nand probe
defer, so the retry computes the OOB layout from the freed context and
spinand_init() aborts with -512. About half of the boots on a Mercusys
MR80X ended in "Waiting for root device /dev/ubiblock0_1".
Accepted upstream for v7.4 as f94c9b68bb5f, tagged for stable.
Signed-off-by: Johan Alvarado <contact@c127.dev>
Link: https://github.com/openwrt/openwrt/pull/24919
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-10-02 11:09:30 +0200e7eaa9851ff15f7a582132de2f9d05e283fe382fgeneric: backport spi-qpic-snand stale ECC pointer fixaddtarget/linux/generic/backport-6.18/441-v7.4-spi-spi-qpic-snand-publish-the-ECC-context-to-snandc.patch
- scripts/mercusys-fwup.pyb5a84a3323584b47f4dd7a7ebf1bae73630a3af01790932170000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comscripts: add Mercusys fwup image generator
Mercusys devices whose stock web UI expects an fwup container reject the
tplink-image-2022 container: the loader picks its verification algorithm
from the fw-type string at offset 0x14, which that container does not
write.
Build the container the loader accepts, with the fw-type string, the
support list and the MD5 placeholder digest in place.
This is a separate script rather than a flag on tplink-mkimage-2022.py
because only the first 0x14 bytes match, the BE length and the salted MD5
over file[4:]. That script writes 0xff filler up to 0x1014, a table there
(>2I rootfs_size/num_items, then >I32s2I entries), data at a fixed 0x1814
base, the rootfs first and a packed >4B1I2I soft version. The fwup
container has no table: 0x2c records of name[32] + >III base, next_off,
size, each followed by its own data and chained through next_off until 0,
the rootfs appended after the last record, and the soft version as ASCII
soft_ver: in an ordinary record.
Signed-off-by: Johan Alvarado <contact@c127.dev>
Link: https://github.com/openwrt/openwrt/pull/24919
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-10-02 11:09:30 +0200b5a84a3323584b47f4dd7a7ebf1bae73630a3af0scripts: add Mercusys fwup image generatoraddscripts/mercusys-fwup.py
- target/linux/qualcommax/ipq50xx/base-files/etc/hotplug.d/firmware/11-ath11k-caldatatarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/02_networktarget/linux/qualcommax/ipq50xx/base-files/lib/upgrade/platform.shtarget/linux/qualcommax/ipq50xx/base-files/lib/preinit/09_mount_tp_datatarget/linux/qualcommax/dts/ipq5018-mr80x-v2.dtstarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/01_ledstarget/linux/qualcommax/image/ipq50xx.mkpackage/boot/uboot-tools/uboot-envtools/files/qualcommax_ipq50xx938f67a519de64dcec10759b2b7203aca086f97a1790932170000https://taiha.net/jenkins/user/robimarkorobimarkorobimarko@gmail.comqualcommax: add support for Mercusys MR80X v2
Hardware:
SoC: Qualcomm IPQ5018 (2x Cortex-A53)
RAM: 256 MiB DDR3
Flash: 128 MiB SPI-NAND (ESMT)
Switch: Realtek RTL8367S, 4x GbE (3x LAN + 1x WAN), SGMII CPU port
WiFi: IPQ5018 2.4 GHz, QCN6122 5 GHz, both 802.11ax
LEDs: system (green/amber), WAN, LAN1-3
Button: reset
UART: 115200 8N1, 3.3V, on-board header
Wi-Fi is left disabled: 256 MiB is too few for ath11k, same as on the
ELECOM WRC-X3000GS2.
Notes:
- The label reads "Ver 2.20", but the vendor firmware only ever calls the
board V2: the GPL tree is GPL_MR80Xv2, PRODUCT_NAME is MR80Xv2, the
running system reports "MR80X V2" and the fwup support list carries
product_ver 2.0.0. The trailing digits are a production sub-revision,
so the port is named v2.
- MAC1 runs sgmii through the UNIPHY PCS to RTL8367S port 6. The link is
wired for HSGMII and 2500base-x does come up, but only when gmac1 and
the CPU port carry the same phy-mode: the UNIPHY PCS belongs to the
conduit (pcs-handle = <&uniphy0> in ipq5018-ess.dtsi), so setting the
CPU port alone leaves the switch running HSGMII into a SerDes still
clocked for SGMII.
With both ends at 2500base-x the trunk still dies on some boots: over
12 reboots, 2 came up with the CPU port passing no traffic at all -
eth0 transmitting while s00_p06_ifInOctets stayed at 0, no FCS errors,
the link reporting 2.5 Gbps. That matches the bring-up ordering race
described in openwrt/openwrt#25153, where the switch end of the trunk
is configured before the IPQ5018 UNIPHY resets and recalibrates its
PLL. sgmii has not reproduced it, so the port ships at sgmii until
that fix lands.
- MAC addresses come from default-mac in the vendor tp_data UBI volume,
6 raw bytes at offset 0, mounted read-only during preinit:
label default-mac
LAN default-mac
WAN default-mac + 1
2.4 GHz default-mac - 1
5 GHz default-mac - 2
- Sysupgrade A/B ping-pongs rootfs/rootfs_1 via tp_boot_idx, switched
only after the new slot is fully written. primaryboot stays 0, the
stock loader and the button recovery rely on it.
- factory.bin is wrapped in the Mercusys fwup container the stock web UI
accepts (scripts/mercusys-fwup.py). The generic tplink-image-2022
container is rejected: the loader picks its verification algorithm from
the fw-type string, which that container does not write.
- The board needs the backported spi-qpic-snand ECC context fix,
otherwise about half of the boots end in "Waiting for root device
/dev/ubiblock0_1".
Installation:
In the stock web UI go to Advanced -> System -> Firmware Update ->
Local Update, browse for
openwrt-qualcommax-ipq50xx-mercusys_mr80x-v2-squashfs-factory.bin
and press UPDATE.
Tested on stock firmware MR80X(EU)_V2.20_1.1.7 Build 20250415
(Multi-language).
The U-Boot web recovery does not accept this image: it verifies an
RSA1024 signature and has no keyless path. Use the stock web UI.
Signed-off-by: Johan Alvarado <contact@c127.dev>
Link: https://github.com/openwrt/openwrt/pull/24919
Signed-off-by: Robert Marko <robimarko@gmail.com>
2026-10-02 11:09:30 +0200938f67a519de64dcec10759b2b7203aca086f97aqualcommax: add support for Mercusys MR80X v2edittarget/linux/qualcommax/image/ipq50xx.mkeditpackage/boot/uboot-tools/uboot-envtools/files/qualcommax_ipq50xxedittarget/linux/qualcommax/ipq50xx/base-files/etc/hotplug.d/firmware/11-ath11k-caldataedittarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/02_networkedittarget/linux/qualcommax/ipq50xx/base-files/etc/board.d/01_ledsaddtarget/linux/qualcommax/dts/ipq5018-mr80x-v2.dtsedittarget/linux/qualcommax/ipq50xx/base-files/lib/preinit/09_mount_tp_dataedittarget/linux/qualcommax/ipq50xx/base-files/lib/upgrade/platform.sh
githttps://taiha.net/jenkins/user/robimarkorobimarkorobimarkohttps://taiha.net/jenkins/user/markus.stockhausenmarkus.stockhausenmarkus.stockhausenhttps://taiha.net/jenkins/user/danieldanieldanielhttps://taiha.net/jenkins/user/mailmailmailhttps://taiha.net/jenkins/user/haukehaukehaukehttps://taiha.net/jenkins/user/jonasjonasjonashttps://taiha.net/jenkins/user/ansuelsmthansuelsmthansuelsmthhttps://taiha.net/jenkins/user/nbdnbdnbdhttps://taiha.net/jenkins/user/lynxislynxislynxis