When a gateway's neighbour goes away, the routes through it are turned
into traps. A route whose address had no entry in the host table
returned before recording that, so it still said forward, and a main
/32 that later got the entry back when a local address went was
programmed to forward through the neighbour that had gone.
Record the trap before looking for the entry. Only RTL930x has a host
table.
Not reproduced on hardware: it needs a host route that found no free
entry in the host table.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25619
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
While an address is the switch's, its host entry is the local route's
and a main /32 for the address keeps out of it. When the kernel
replaces the local route by another for the same address, as when an
address held on two devices is removed from the first, the driver tears
the old route down, which hands the entry back to the main /32, and
then writes the new local trap over it. In between, the hardware can
forward packets for the switch's own address through the main /32's
gateway.
A route torn down to be replaced no longer hands the entry back; the
route replacing it takes it over. The entry is still invalidated in
between, so for that moment a covering prefix answers. Only RTL930x has
a host table.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
through a bench-only line logged whenever a main /32 gets its entry
back: with an address on two switch interfaces and a main /32 for it
via another host, removing the address from the first interface logs
that write without this change and none with it. Removing it from the
second logs it on both, and the main /32 forwards 5 of 5 echoes again.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25619
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Use the new ucidef_set_led_brightness function for the ST LED1202 status
LEDs now that it supports configurable brightness. Blue is enabled at
brightness 51 with red and green off, matching the OEM default colour
scheme and intensity.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23457
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add ucidef_set_led_brightness() to set up a static LED with an optional
brightness level, complementing ucidef_set_led_default() for hardware
that supports per-channel current or PWM control.
The function writes a "brightness" type to board.json alongside the
default on/off state. config_generate picks this up and writes the
brightness option to the UCI LED config, where the led init script
already knows to apply it.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23457
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Allwinner H5 uses the H3 R-PIO controller in addition to its
H5-specific main PIO controller. Moving the pinctrl configuration to
the subtargets left PINCTRL_SUN8I_H3_R disabled for cortexa53.
On the NanoPi NEO 2, usb0-vbus depends on the R-PIO PL2 GPIO. Without
the driver, the regulator and USB PHY remain deferred, preventing the
USB host controllers from probing. No USB device nodes are created
and lsusb reports "unable to initialize libusb: -99".
Enable PINCTRL_SUN8I_H3_R in the cortexa53 configuration to restore
the R-PIO driver required by H5 boards.
Fixes: 920fa6f061 ("sunxi: enable pinctrl driver in subtarget")
Signed-off-by: Joseph Chen <phenomenon0102@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25588
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Since the MAC lookup started returning -EPROBE_DEFER, a probe that
defers while its nvmem provider (e.g. a mac-base cell in the CFE
partition) isn't ready yet leaves the power domain devices attached
by genpd_dev_pm_attach_by_id() behind. The next probe then fails to
re-create them:
sysfs: cannot create duplicate filename '/devices/genpd:0:1000d800.ethernet'
bcm6368-enetsw 1000d800.ethernet: error getting pm 0
bcm6368-enetsw 1000d800.ethernet: probe with driver bcm6368-enetsw failed with error -22
leaving the board without ethernet and the DSA switch deferred forever.
Look up the MAC first, before anything that isn't device-managed has
been set up, so a deferred probe can simply be retried.
Seen on a BCM6328 (BeWAN A2100N) with kernel 6.18.
Fixes: ed545519ee ("bmips: enet: handle EPROBE_DEFER for the MAC address")
Signed-off-by: Max Plekh <mplekh@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25454
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A rule given an explicit dscp selector keeps it in the family's own
part of the rule, with a flag that tells dscp 0 from no selector at
all. fib4_rule_default() and fib6_rule_default() only test the dscp
value, so "dscp 0 lookup main" passed for an unrestricted main rule:
packets with any other dscp go on to the next rules in the kernel, and
the hardware forwarded them by main all the same.
Only the family's own callbacks see that part of the rule, and its fill
callback reports an explicit selector as FRA_DSCP. Run it into a
scratch buffer and count a local or main rule with FRA_DSCP, or one
that cannot be read out, as restricted.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled:
a prefix routed in main via a host on another VLAN, blackholed in
table 100, with "dscp 0 lookup main" ahead of a rule sending the
sender's subnet to table 100. Echoes with dscp 8: without this change
the row keeps forwarding and all 5 reach the host, with it the row
traps and none do, for IPv4 and IPv6. With it, echoes with dscp 0 still
reach the host, routed by the kernel through main.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25618
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Probe holds the FIB replay work disabled until the FIB notifier is in
place, and queueing a disabled work does nothing. The notifiers are
live before that, so one that could not allocate in the window asked
for a replay that never came, and what its lost event would have
changed could stay wrong in hardware.
Note the request in the control structure before queueing the work,
and have probe queue the work once it has enabled it if a request was
noted. The two barriers pair, so at least one side sees the other: the
notifier finds the work enabled, or probe finds the request. The work
clears the note when it starts. Where the work is never enabled, a
family that routes through PIE rules, the note is set and never read,
as the queueing does nothing there today.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
through a bench-only commit that asks for a replay right after the
netevent notifier is registered, as a notifier does when its allocation
fails: without this change no replay follows, with it the FIB is
replayed once probe has enabled the work, and a route added afterwards
is offloaded and forwards 5 of 5 echoes as before.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25617
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The switch looks a destination up in rows built from the local and main
tables, while the kernel consults the policy rules first. A rule ahead
of main can send a packet to another table, and a main rule restricted
to some packets, or no main rule at all, sends the others elsewhere;
the hardware forwarded them by main all the same. Rule events of both
families went to fib4_rule_default(), which only logged "FIB4 default
rule failed".
On every rule event, look at that family's rules. The local rule, an
unrestricted main rule and rules at a later priority leave the offload
as it is: such a rule only sees what main has no route for, and no row
forwards that either. Any other rule before main or at main's
priority, or a missing or restricted main rule, turns the family's
forwarding rows into traps, and they go back to forwarding through
their gateways once the rules allow it again. A rule that only matches
iif lo never sees a forwarded packet and does not count.
fib4_rule_default() and fib6_rule_default() tell a default rule; they
leave ip_proto and the fwmark mask out, so a rule with either does not
pass for main here. A main rule restricted to dscp 0 still does: the
kernel keeps that in a structure the driver cannot see.
The rows are rewritten where they are; a main /32 kept out of a local
address's host entry stays out of it. This changes the L3 table path
only. A family that routes through PIE rules keeps its rules and the
error it logged, now for IPv4 rules only.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled:
a prefix routed in main via a host behind another port, blackholed in
table 100, pinged from a third subnet. With a rule sending that subnet
to table 100 ahead of main, the hardware without this change still
forwards all 5 echoes to the host; with it the rows trap and none
arrive, for IPv4 and IPv6 independently. A main rule restricted to
another source subnet gives the same 5 against 0. Rules at a later
priority than main, iif lo rules and the default rules keep the rows
forwarding, and rows that trapped come back once the rules do.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25612
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Both notifiers allocate their work with GFP_ATOMIC and return
NOTIFY_BAD when that fails. The kernel takes that as a veto only for a
route or a rule being added; a route delete or a neighbour update goes
ahead regardless, and the hardware keeps forwarding by what the lost
event would have changed.
On such a failure, queue a work item kept in the driver's control
structure, which needs no allocation. It unregisters the FIB notifier,
takes out every route the driver programmed and registers it again, so
the kernel replays the FIB as it does at probe. The stale entry still
forwards until that flush, which waits for the work already queued;
from there until the replay is done, the catch-all rows trap what the
routes no longer cover. A replay can fail too, short of memory the
same way or on a route the notifier refuses that came in while it was
away: it is flushed and tried again after a delay that doubles up to
64 seconds. An add the kernel refused schedules a replay as well, which
finds nothing to correct.
The work is enabled once probe has registered the notifier, and only
where the L3 tables provide the catch-all rows; a family that routes
through PIE rules keeps the old behaviour. Remove disables it before
unregistering the notifiers.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
through bench-only debugfs counters that make the next allocations of
either notifier fail. A route deleted while its event is lost: without
this change its row keeps forwarding and 5 of 5 echoes still reach the
old gateway; with it the replay takes the row out and none do. A
permanent neighbour moved to another host while its event is lost:
without this change all 5 echoes still go to the old host, with it to
the new one. With the replay's first allocation failing as well, the
replay fails once and the retry converges the same way. An add whose
event is lost is refused either way. The untouched IPv4 and IPv6 routes
forward in hardware after every replay.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25603
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
A router advertisement adds its routes with RTF_ADDRCONF: on-link
prefixes, which have no gateway and are left out already, the default
route, also left out, and with CONFIG_IPV6_ROUTE_INFO the Route
Information routes. Such routes never become multipath siblings
(rt6_qualify_for_ecmp()), so the routes several routers advertise for
one prefix sit side by side and the kernel picks among them at lookup
time (rt6_select()). The driver only hears of the route at the head of
the list, and when a router changes its preference the route is
updated in place, with no event.
Leave RTF_ADDRCONF routes to the kernel. OpenWrt builds the kernel
without CONFIG_IPV6_ROUTE_INFO, so none of the routes its router
advertisements add is handled differently.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled.
No router advertisement can create such a route with OpenWrt's kernel,
so a bench-only tool added one through the legacy SIOCADDRT ioctl,
which keeps RTF_ADDRCONF in the flags. On main it is programmed to
forward and marked offloaded; with this change it gets the trap row a
route left to the kernel gets, is not marked offloaded, and the echoes
sent into it still all reach its gateway. A twin route to another
prefix without the flag is offloaded on both.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25602
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The host table holds one entry per IPv4 address, found by the address
alone. A /32 in main for an address of the switch shared that entry
with the local route: whichever wrote last owned it, a neighbour update
of the main route turned the local trap into forwarding, and deleting
the main route took the entry from the local one. The kernel looks the
local table up first, so the address is the switch's for as long as it
holds it.
While a local route holds an address, a host route from main for it
leaves the entry alone - on add, neighbour update, trap and delete -
and keeps its state in memory. When the local route goes, the main
route writes its entry back as it last stood.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
main against main with this and the previous commit. A /32 route
through a gateway in hardware, then the same address added to the
switch, and 5 echoes to it:
- after a neighbour update of the gateway, main turned the address's
entry into forwarding and sent all 5 to the gateway, unanswered;
now the switch answers all 5.
- with a /24 through the gateway covering it and the /32 route
deleted, main took the address's entry away and the /24 forwarded
all 5; now the switch answers all 5.
- with a /24 through another gateway covering it and the address
deleted, main took the /32 route's entry with it and the /24 sent
all 5 to that other gateway; now the /32 route forwards all 5 to
its own.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25598
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The kernel looks the local table up before main, so an address of the
switch is delivered to it even when main holds a route of the same
length to that address. The hardware answers with the first prefix row
that matches, and a route is placed after every row of its length or
longer: whichever of the two came first won, and a /128 route in main
added before the address forwarded the address's traffic away.
Place a local table entry after the longer rows only, ahead of main's
of the same length. Main's row stays, and answers again once the
address is gone.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
main against main with this and the next commit, which only touches
the IPv4 host table. fd00:9f::1/128 through a gateway in hardware,
then fd00:9f::1/64 added to the switch, and 5 echoes to the address:
main left the route's row ahead of the address's and forwarded all 5
to the gateway, unanswered; now the switch answers all 5. With the
address gone again, the route forwards all 5 to its gateway on both.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25598
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
tls_mbedtls_set_ciphers() contains logic intended to handle cipher name
mapping cases where the Mbed TLS name carries a trailing "-SHA256" that
the OpenSSL name omits, e.g. the OpenSSL name
"ECDHE-RSA-CHACHA20-POLY1305" corresponds to the Mbed TLS name
"TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256". The os_memcmp()
expression for this suffix check was missing a "== 0", i.e. the logic
was inverted.
This means intended cases like "ECDHE-ECDSA-CHACHA20-POLY1305" were
incorrectly rejected (an unmatched name makes tls_mbedtls_set_ciphers()
fail), while accepting bogus mappings like "ECDHE-RSA-AES256-GCM" ->
"ECDHE-RSA-AES256-GCM-SHA384" or "ECDHE-ECDSA-AES" ->
"ECDHE-ECDSA-AES256-CCM". (Fortunately no valid OpenSSL suite names were
accepted with a bogus mapping.)
Signed-off-by: Karsten Sperling <ksperling@apple.com>
Link: https://github.com/openwrt/openwrt/pull/25552
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
tls_mbedtls_match_dn_field() populates one struct mlistoid per component
of the check_cert_subject string, but never initializes the prefix flag,
which is only assigned when the value ends in '*'. Whether a component
without a wildcard was matched as a prefix therefore depended on
leftover stack contents, e.g. check_cert_subject="O=w1.f" could be
accepted for an Organization of "w1.fi".
Found by ap_wpa2_eap_ttls_pap_check_cert_subject_neg, which happens to
check "C=FI1*" immediately before "O=w1.f".
Signed-off-by: Karsten Sperling <ksperling@apple.com>
Link: https://github.com/openwrt/openwrt/pull/25552
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
OpenWrt sources diag.sh at the preinit_main hook stage (02_default_set_state),
resolving LED aliases from the device tree so that set_state() can blink the
boot LED through the preinit and preinit_regular phases before init takes
over. For that to work the LED driver must be present before the preinit
scripts run.
Without the boot flag, AutoProbe only places the module in etc/modules.d,
which is loaded by /etc/init.d/boot once preinit has finished. By that
point the entire preinit LED window has passed and the boot indication on
any ST LED1202-backed LED is silently skipped.
Set the boot flag so the module is also linked into etc/modules-boot.d,
which procd loads before running the preinit scripts. The previous commits
bring the driver to a state where loading it at early boot is appropriate.
Assisted-by: LLM
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23456
Signed-off-by: Robert Marko <robimarko@gmail.com>
Register the three status LEDs of the ST LED1202 controller in the board
default configuration so they are exposed to userspace via UCI and LuCI,
allowing users to customise LED behaviour without manual sysfs interaction.
Blue is enabled by default; red and green are off.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23456
Signed-off-by: Robert Marko <robimarko@gmail.com>
The NXP PCA9633 LED controller was defined in the shared ipq8174-mx4x00.dtsi,
but the MX4200v2 uses a different controller — the ST LED1202 (I2C address
0x58) — instead of the PCA9633 (0x62) used by MX4200v1, MX4300, and HomeWRK.
Move the LED controller node out of the shared DTSI into each device's own
DTS file.
Fix kmod-leds-pca963x being pulled in for all linksys_mx devices by assigning
LED driver packages explicitly per device: kmod-leds-pca963x for MX4200v1,
MX4300, MX5300, and MX8500; kmod-leds-st1202 for MX4200v2.
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23456
Signed-off-by: Robert Marko <robimarko@gmail.com>
ead-client trusts several length and index fields taken straight from
the network when handling server responses, before authentication has
completed. Since the client sends its requests as UDP broadcasts and
never validates the origin of the replies, any host on the same L2
segment can spoof the whole handshake and hit these paths.
handle_prime() copies sb->len bytes into saltbuf[MAXSALTLEN] (32 bytes)
without checking the length, and passes sb->prime to t_getpreparam()
without a range check. Both come from the wire, so a salt length up to
255 overflows saltbuf and a prime index up to 255 reads (and writes)
out of bounds in the precompiled parameter table. This is
GHSA-mq4v-mf82-24rr.
handle_b() computes the copy length as msg->len - sizeof(number) and
memcpy()s it into bbuf[MAXPARAMLEN] with no bounds check. msg->len is
attacker controlled and only capped by the 1500 byte receive buffer, so
up to 1479 bytes land in the 256 byte bbuf. A msg->len of 0 makes the
signed length -1, which memcpy() treats as SIZE_MAX. This is
GHSA-8f8g-5c8x-8mhh.
handle_pong() writes the NUL terminator at pong->name[len] using an
unchecked length, allowing a one byte write past msgbuf, and the receive
loop's length check could wrap for a large msg->len.
Bound every length against its destination buffer and range check the
prime index, mirroring the checks already present on the daemon side in
ead.c (handle_send_a(), commit 63c0767f3d). ead-client is not
installed into images by the ead package, only the daemon is, so this
only affects administrators who build and run the client by hand.
Link: https://github.com/openwrt/openwrt/security/advisories/GHSA-mq4v-mf82-24rr
Link: https://github.com/openwrt/openwrt/security/advisories/GHSA-8f8g-5c8x-8mhh
Fixes: 2d86ea2a1d ("add the 'ead' package (emergency access daemon), which can provide remote access to your device, even if the ip and firewall settings are broken")
Assisted-by: Claude:claude-opus-4-8
Link: https://github.com/openwrt/openwrt/pull/25492
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Build/elx-header and Build/znet-header convert a hex string into \xHH
escape sequences using `fold -s2`. This relies on the obsolete -WIDTH
option syntax of GNU fold, which parses "-s2" as "-s -2". uutils
coreutils does not support this syntax and fails with:
error: unexpected argument '-2' found
tip: to pass '-2' as a value, use '-- -2'
Since fold writes nothing to stdout in this case, the command
substitution expands to an empty string. The following
`dd bs=N count=1 conv=sync` then writes zero bytes, because conv=sync
only pads partial input blocks and never pads empty input. The header
field is dropped entirely, and all subsequent fields move to lower
offsets.
The build still succeeds, because the failure happens inside the
subshell which is then handed to echo.
The malformed images are only rejected when a device tries to
boot them.
For example, on the Zyxel WSM20, the missing payload size field in the
znet-header moves the 0x12345678 magic and the payload to unexpected
offsets. The bootloader then rejects the image, even though sysupgrade
accepted it.
This affects all builds on Ubuntu 25.10 and later, because these
releases use uutils coreutils by default.
Replace `fold -s2` with `fold -w2`, which is the documented way to set
the line width and produces identical output with GNU fold.
Affected devices:
- Build/znet-header is used in all images of the Zyxel WSM20 and the
ELECOM WRC-X1800GS
- Build/elx-header is used in the factory images of the ELECOM
WAB-I1750-PS, WAB-S1167-PS, WAB-S600-PS, WRC-2533GHBK-I and
WRC-2533GHBK2-T, the I-O DATA WN-AC1167GR, WN-AC733GR3 and WNPR2600G,
the Edimax RA21S and RG21S, and the D-Link DAP-X1860 A1
Signed-off-by: Grische <github@grische.xyz>
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/25410
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A source-specific route matches only the packets from its source, and
the hardware matches on the destination alone, so the driver traps the
destination of every such route. All of them shared one trap row with
one member count, which each add overwrote: deleting one of two
source-specific routes to a prefix took the row from the other, and an
add of the route without a source to that prefix replaced the trap
with a forwarding row, which then sent the traffic of every source to
its gateway. A source-specific route added over a forwarding row took
that row out, and deleting it again left the destination without one.
Keep the members of each source apart on the trap row, next to those of
the route without a source, and take the row out only when none is
left. The route without a source joins the trap while source-specific
routes remain, and keeps it after they are gone until its next event,
as a multipath route keeps its trap after a member leaves. The error
that stood in for this goes.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
main against main with this change. fd00:9e::/32 through one gateway
in hardware, a /48 inside it, and 5 echoes into the /48 from a host in
the source of the first route below, which the CPU routes back to it:
- two source-specific routes, then one deleted: main took the row away
and all 5 echoes reached the /32's gateway; now the row stays and
none do.
- a route without a source through the /32's gateway, added after a
source-specific one: main forwarded all 5 to that gateway whatever
their source; now the row stays a trap and none go there. Deleting
that route left no row on main; the trap stays now.
- a source-specific route added and deleted over a forwarding route
without a source: main left no row and all 5 reached the /32's
gateway; now a trap stays and none do.
A default route with a source gets no row on either.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25583
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
TP-Link EX220 v1 as distributed by the Russian ISP MTS, labelled
"EX220(RU)MTS) Ver:1.30". It carries the same model name as the already
supported tplink,ex220-v1, but it is a different board: 128 MB of
parallel NAND managed by NMBM instead of 16 MB of SPI-NOR, and an entirely
different flash layout. The bootloader tells the two apart - on this
revision U-Boot prints "NAND: 128 MiB" followed by "NMBM has been
successfully attached".
Hardware specification:
- SoC: MediaTek MT7621AT (MIPS 1004Kc, ver 1 eco 3)
- RAM: 128 MB DDR3 (chip hidden under the shielding can)
- Flash: 128 MB parallel NAND, ESMT F59L1G81MB, NMBM managed
(the driver identifies the chip as "ESMT PSU1GA30DT")
- WiFi: MediaTek MT7915E, DBDC, 2x2 2.4 GHz + 2x2 5 GHz (AX1800)
- Ethernet: MediaTek MT7530, 5x 10/100/1000 Mbps (4x LAN + 1x WAN)
- LEDs: 7x GPIO - power, LAN, WAN green, WAN amber, WLAN 2.4 GHz,
WLAN 5 GHz, WPS
- Buttons: 2x tactile - reset, WPS
- UART: 4 unpopulated through holes on the solder side of the board,
beside the silver factory sticker, with no silkscreen designator.
Counting from the hole furthest from the ethernet ports: pin 1 TX,
pin 2 RX, pin 3 GND, pin 4 unused - leave it unconnected.
115200 8N1, 3.3 V.
- Power: 12 VDC, 1 A
MAC addresses:
LAN f0:a7:31:xx:xx:xx misc_ro @ 0x5c50bc, matches the label
WAN f0:a7:31:xx:xx:xx same as LAN
2.4G label MAC + 2
5G label MAC + 3
The radio calibration lives in the misc_ro partition, which holds a
JFFS2 filesystem with five files named after their original flash
offsets. The largest one carries the MT7915 EEPROM at offset 0x90000,
so 11-mt76-caldata mounts the partition read-only and copies it out.
Reading it needs CONFIG_JFFS2_ZLIB - the vendor compressed those nodes
with zlib, which OpenWrt does not build in by default.
It is worth the kernel option. With the factory calibration the client
reports -44 dBm at half a metre and negotiates HE-MCS 11; with the
generic default EEPROM the very same link reports -82 dBm and settles
at HE-MCS 3, and a local transfer peaks at 541 instead of 692 Mbit/s.
The vendor bootloader loads a FIT image from the fixed address
0xd00000 and does not evaluate partition names, so the vendor firmware
slot is split into a raw kernel partition and a UBI partition holding
rootfs and rootfs_data.
Flash instructions:
The vendor web interface offers no way in, so the first installation is
done over the serial console.
1. Open the case and attach a 3.3 V USB-to-serial adapter to the 4-pin
header described above.
2. Power the board up and interrupt the bootloader by pressing any key
when it prints "Hit any key to stop autoboot".
3. Load the initramfs image into RAM over YMODEM:
loady 0x84000000
Send openwrt-ramips-mt7621-tplink_ex220-v1-nand-initramfs-kernel.bin
using the YMODEM transfer of your terminal program - this takes
about 11 minutes at 115200 baud - and boot it:
bootm 0x84000000
Do not raise the bootloader console speed to shorten the transfer:
with the console set to 921600 baud the kernel hangs while taking
the UART over from the bootloader, leaving nothing after the 16550A
line, and the watchdog resets the board.
4. The running system serves 192.168.1.1/24 on the LAN ports. Transfer
openwrt-ramips-mt7621-tplink_ex220-v1-nand-squashfs-sysupgrade.bin
to /tmp and install it:
sysupgrade -n /tmp/openwrt-*-ex220-v1-nand-squashfs-sysupgrade.bin
The board reboots into OpenWrt on its own; later updates use
sysupgrade as usual.
Reverting to stock:
The second firmware slot ships empty, so there is nothing to fall back
to - take a backup while the initramfs image of step 3 is running, ie
before step 4:
cat /dev/mtd4 /dev/mtd5 > /tmp/stock.bin
and copy it off the device. To restore it, boot the initramfs image
again and write it back:
dd if=stock.bin bs=1M count=4 | mtd write - kernel
dd if=stock.bin bs=1M skip=4 | mtd write - ubi
Signed-off-by: Denis Faizullin <triplexit.help@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24831
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport 12 upstream fixes for the ST LED1202 driver to backport-6.12:
894-01 leds: st1202: Check for error code from devm_mutex_init() call
894-02 leds: st1202: Refactor st1202_led_set() to use !! operator for
boolean conversion
894-03 leds: leds-st1202: Initialize hardware before DT node child
operations
894-04 leds: leds-st1202: Spacing and proofreading editing
894-05 leds: st1202: Stop pattern sequence before reprogramming
894-06 leds: st1202: Validate pattern input before stopping the
sequence
894-07 leds: st1202: Fix pattern duration prescaler and
pattern_clear skip marker
894-08 leds: st1202: Set all pattern PWM slots to full after
clearing pattern
894-09 leds: st1202: Fix spurious pattern sequence start in setup
894-10 leds: st1202: Fix brightness having no effect while pattern
mode is active
894-11 leds: st1202: Disable channel when brightness is set to zero
894-12 leds: st1202: Validate LED reg property against channel count
894-01 through 894-04 landed in v6.15; 894-05 through 894-12 were
merged for v7.3 and are now also in stable 6.18.52 and 6.18.53, so
none of these are needed for backport-6.18.
Assisted-by: LLM
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/23455
Signed-off-by: Robert Marko <robimarko@gmail.com>
PCRE2 supports JIT on RISC-V and LoongArch64, but PCRE2_JIT_ENABLED
cannot be selected for them. Allow it and enable it by default, as on
aarch64.
libpcre2-8.so grows by 61 KiB on riscv64 and 54 KiB on loongarch64,
compressed with xz.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/25582
Signed-off-by: Robert Marko <robimarko@gmail.com>
RISC-V is becoming more popular, and it's beneficial to have OpenSSL
optimized for speed on riscv64 architectures by default. And many
algorithms in OpenSSL currently lack assembly optimizations for riscv64,
so optimizing for speed for riscv64 will bring significant performance
improvements for C implementations. For example, the performance of
ChaCha20 improves dramatically with this change, from 63603.67k to
129428.12k on Bananapi BPI-RV2 with rva22u64 profile.
All existing boards that use riscv64 that support boot from SDCard or at
least 128M NAND flash, so the slight increase in binary size is
acceptable. And I have tested this change to build with even rva22u64
profile, the libssl.so.3 only increases from 972K to 1.1M, which is
acceptable for most use cases.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Link: https://github.com/openwrt/openwrt/pull/21070
Signed-off-by: Robert Marko <robimarko@gmail.com>
An IPv4 route through a switch port got its entry only when its gateway
resolved, and a route with no gateway - a connected prefix - never got
one. Until then, or for good, a shorter prefix in hardware forwarded
its destinations through another gateway: a /24 under an offloaded /16
whose gateway is slow to answer or gone, or a host of a connected /24
under it that has not been resolved yet.
Give these routes their entry when they are added, trapping to the
CPU, which resolves the gateway or the host. otto_l3_route_update_hw()
turns a gateway's entry into a forwarding one once it answers, at the
row the route already holds. IPv6 routes do the same since they were
offloaded.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
against the tree without this change, with the same /16 and echoes as
the previous commit:
- a /24 and a /32 through a gateway that never answers, and a
connected /24 with no host on it: before, no entry, and all 5
echoes reach the /16's gateway; now a trap entry, and none do.
- a /24 and a /32 through a gateway that answers still end up
forwarding, and all 5 echoes reach that gateway; a blackhole /24
replaced by such a route leaves one forwarding row.
No entry is left after the deletes.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25572
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
A route the driver leaves out is the CPU's to forward, but a shorter
prefix in hardware still matches its destinations and forwards them
through its own gateway. IPv6 routes left out get a row that traps;
IPv4 ones got one only at /32, and only when they had no device, so a
blackhole, unreachable or prohibit /24 under an offloaded /16, or a
/24 through a device outside the switch, went the /16's way. So did
an address of the box on such a device - a loopback or a WAN address
under an offloaded prefix.
Give every IPv4 route left out an entry that traps: a /32 in the host
table as before, anything shorter a row of its own, the default route
none since the catch-all row already traps what nothing else matches.
The entry is keyed on no gateway, so the delete handler takes it out
by destination before it looks for the route's gateway.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
against the tree without this change. 10.99.0.0/16 through a gateway
on a switch port, in hardware, and 5 echoes from a host on another
VLAN into each route below:
- a blackhole /24, a prohibit /24 and a /24 through a bridge without
ports: before, no entry, and all 5 echoes reach the /16's gateway;
now a trap row, and none do.
- a /32 address of the switch on that bridge: before, all 5 reach the
/16's gateway and none is answered; now the switch answers all 5.
No entry is left after the deletes. A build without the delete
handler's part leaves the trap row of the /24 through the bridge
behind once its route is gone.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25572
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
register_fib_notifier() replays the FIB to the notifier before it starts
delivering events, and checks that nothing changed while it did. When
something did, it unregisters the notifier, calls the callback it was
given and dumps again, up to five times. The driver passed no callback,
so a route the first dump queued and the FIB lost before the next one
stayed programmed for good: its delete went to no one.
Pass a callback that takes out every route the driver programmed,
after the work the dump queued has run. The catch-all rows stay: no
table owns them.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
through a bench-only debugfs file that unregisters the notifier, takes
out the driver's routes and registers it again, as probe does, with
and without this callback. 20000 routes in table 100 make the dump
long; 40 /24s in main are deleted and added back while it runs, and
deleted at the end. Eight runs each, every one taking 2 to 5 dumps:
- without the callback, 7 of 8 runs leave 13 to 40 of those /24s in
hardware, though the kernel has none;
- with it, none is left in any run.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25571
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The notifier records how many members an IPv6 route has when the event
fires, because the work that handles the event runs later. The check
that refuses multipath routes still read the route's own sibling count
at that later point. A member appended and deleted before its append
was handled has had that count cleared by then, so the append
programmed it as a single route through its own gateway, replacing the
row of the route it had joined, and the delete took that row away. The
route left behind had no row, and a shorter prefix in hardware
forwarded its traffic to another gateway.
Decide on the recorded count, on add and delete alike. The route left
behind keeps a trap row until its next event, as it already does when
the member leaves after its append was handled.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
main against main with this change. fd00:9d::/32 through one gateway
and fd00:9d:N::/48 through another, both in hardware; then a single
ip -batch adds 40 filler routes, appends a second member to the /48
through the /32's gateway and deletes it again. The fillers keep the
work queue busy, so the append is handled after the delete: a marker
written to the kernel log right after the batch precedes the driver's
check of the append in 5 of 5 runs on both images.
- main: the /48 is left without a row, and all 5 echoes sent into it
reach the /32's gateway, in every run.
- this change: the /48 keeps a trap row, and the 5 echoes reach its
own gateway through the CPU, in every run.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25564
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
A route can carry a lightweight tunnel - seg6 encapsulation, an MPLS
label push - that the kernel applies to every packet it forwards. The
FIB notifier never looked at it, so such a route through a gateway on
a switch port was offloaded like any other, and the hardware forwarded
its traffic to the gateway bare. OpenWrt enables seg6 lightweight
tunnels by default on every target without small_flash, realtek
included.
Leave these routes out, on both families. An IPv6 one gets a trap row,
as the other IPv6 routes the driver leaves out do. An IPv4 one takes
the path of the routes without a device or through a nexthop object:
a /32 is trapped in the host table and a shorter prefix gets no row,
so an offloaded shorter prefix covering it would still forward its
traffic. The delete handler takes the same path, so a trapped /32 does
not outlive its route.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
main against main with this change. Three routes with seg6
encapsulation through a gateway on a switch port - 10.99.80.0/24,
10.99.81.7/32 and fd00:9a::/48 - each took 5 echoes from another VLAN.
- main: each gets a forwarding row, and the gateway receives all 5
echoes bare, none encapsulated.
- this change: no row for the /24, a trap row for the /32 and the
/48, and the gateway receives none bare and all 5 inside an IPv6
segment routing header. No row is left after the deletes.
A build without the delete half leaves the trapped /32 in the host
table once its route is gone. An IPv4 and an IPv6 prefix without a
tunnel, through the same gateway, forward in hardware on both images,
5 of 5.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25560
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
RTL9607C has 3 SerDes starting at 0xbb040030. Serdes 0 is for PON transceiver
and Serdes 1/2 are HSGMII. The pages are laid out in a similar structure as
RTL838x with SDS, SDS_EXT, FIB, FIB_EXT but not in the same order as the rest
of the switch SoCs: WSDS_DIG is 1st, then goes WDIG, ANA_MISC, ANA_COM, ANA_SPD
ANA_1P25, ANA_GPON, ANA_EPON, and then ordinary SDS, SDS_EXT, FIB and FIB_EXT.
The serdes 1/2 however only have WSDS_DIG, SDS, SDS_EXT, FIB and FIB_EXT pages.
RTL9607C has a WSDS_DIG page which seems a bit different from WDIG so add it to
rtsds_page_name struct.
There is however another page WSDS_ANA that comes before WSDS_DIG at 0xbb040000
but it is ignored because it doesn't align nicely, is empty with full of DMY
bit fields and is unused by SDK anyway.
Signed-off-by: Rustam Adilov <adilov@tutamail.com>
Link: https://github.com/openwrt/openwrt/pull/25463
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Is a security patch release. The most severe CVE fixed
in this release is High.
This release incorporates the following bug fixes and mitigations:
* Fixed DTLS retransmissions of handshake messages from a stale buffer offset.
([CVE-2026-84782])
* Fixed excessive memory allocation in relative CRLDP processing.
([CVE-2026-35189])
* Fixed QUIC unvalidated amplification credit may be over-accounted.
([CVE-2026-35191])
* Fixed potential CPU DoS via O(n^2) fragment reassembly in QUIC.
([CVE-2026-42772])
* Fixed a timing side-channel in scalar multiplication for mon-NIST EC curves.
([CVE-2026-54872])
* Fixed QUIC `STREAM` fragment metadata DoS.
([CVE-2026-54873])
* Fixed non-constant-time SM2 scalar multiplication on ARM64 and RISC-V.
([CVE-2026-54875])
* Fixed out-of-bounds access after `SSL_set_SSL_CTX()` during a handshake.
([CVE-2026-72897])
* Fixed QUIC connection-level flow control was not enforced for streams.
([CVE-2026-75804])
* Fixed a NULL pointer dereference in CMP client revocation response handling.
([CVE-2026-75805])
* Fixed an unauthenticated and undersized DTLS 1.2 AEAD record causing DoS.
([CVE-2026-75806])
* Fixed a timing side-channel in SM2 signature generation.
([CVE-2026-77696])
* Fixed an unbounded `RETIRE_CONNECTION_ID` backlog in QUIC stack
implementation.
([CVE-2026-84784])
* Fixed a bug where `EVP_DecryptFinal()` incorrectly reported a stale success
on AES-SIV authentication failure.
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25557
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
UBIFS root file systems differ between builds, e.g. the one of the
Microchip SAMA7G5-EK: the superblock gets a random UUID, the inodes get
the ctime of the build host, which can't be reset with touch, and the
entries of each directory are added in readdir() order, which depends on
the host file system and decides inode numbers and layout.
Add a patch that, when SOURCE_DATE_EPOCH is set, uses a time-based
(version 1) UUID with that time and clamps all inode times to it. The
node ID of the UUID is taken from the new --uuid-node option, which the
image build sets from IMG_PART_DISKGUID, itself derived from
SOURCE_DATE_EPOCH and the kernel vermagic.
Directory entries are added sorted by name. Two trees with the same
contents but different ctimes and readdir() order now give identical
images; without SOURCE_DATE_EPOCH the UUID stays random.
Link: https://github.com/openwrt/openwrt/pull/25430
Signed-off-by: Paul Spooren <mail@aparcar.org>
Git commit changes:
389b9b7 wireless-regdb: update regulatory database based on preceding changes
8f1e802 wireless-regdb: allow 320MHz channel width for Hong Kong (HK)
74cb99f wireless-regdb: Update 2.4 and 5 GHz rules for South Africa (ZA)
2482838 wireless-regdb: Remove DFS flag from 60 GHz band for Togo (TG)
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/25008
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Deleting the route the kernel selected for an IPv4 prefix does not
always notify a delete. When another route for the same prefix and
table remains, fib_notify_alias_delete() sends a replace carrying that
successor instead. otto_l3_fib_add_v4() looked up the switch port of
the new route before taking out the programmed one, so a successor
through a device outside the switch - a WireGuard tunnel, say -
returned -ENODEV and left the old row forwarding to a gateway the
kernel no longer uses. The delete of the successor finds no row of
its own, so the stale one outlives both routes.
Take the programmed route out before anything can turn the new one
down, as the IPv6 path already does. The successor still gets no row,
so a shorter prefix in hardware would forward its traffic, as it does
today for any IPv4 route through a device outside the switch.
Tested on a Hasivo S1100W-8XGT-SE (RTL9303) with L3 offload enabled,
main against main with this change. 10.99.70.0/24 via a host behind a
switch port, metric 10, then the same prefix via a bridge without
ports, metric 20, then the metric 10 route deleted. On both images the
kernel keeps the bridge route and the driver logs "lower interface
wanx not found".
- main: the row stays forwarding, 5 of 5 echoes sent to the prefix
reach the old gateway, and the row outlives both routes.
- this change: no row, 0 of 5 echoes reach the old gateway.
With the successor behind a switch port instead, both images end with
one forwarding row and its gateway receives 5 of 5 echoes.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25559
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The boot partition of the DNS-313 factory image differs between builds:
-Linux rev 1.0 ext2 filesystem data, UUID=9f7d7721-0bf7-4483-bd56-b539d195f181
+Linux rev 1.0 ext2 filesystem data, UUID=d3ca4870-378b-48dd-9b05-760812dfeb81
-drwxr-xr-x ... 2026-09-23 07:37:23.000000 ./.boot/
+drwxr-xr-x ... 2026-09-23 09:38:09.000000 ./.boot/
genext2fs copies the mtimes of the staged files from the host and adds
them in readdir() order, which also decides their inode numbers and
blocks. It leaves the UUID empty, so e2fsck fills in a random one, and
e2fsck stamps the last check with the current time.
Pass genext2fs a name sorted tarball with mtimes clamped to
SOURCE_DATE_EPOCH and group/other write bits cleared, derive the UUID
from IMG_PART_DISKGUID and run e2fsck with E2FSCK_TIME set to
SOURCE_DATE_EPOCH.
Link: https://github.com/openwrt/openwrt/pull/25358
Signed-off-by: Paul Spooren <mail@aparcar.org>
TP-Link RE700X is a dual-band Wi-Fi 6 (AX3000) range extender based on
Qualcomm IPQ5018 (2.4 GHz) with a QCN6122 (5 GHz) companion radio.
Specifications:
- SoC: Qualcomm IPQ5018 (dual-core ARM Cortex-A53)
- RAM: 256 MiB
- Flash: 128 MiB SPI-NAND (ESMT F50D1G41LB)
- Wi-Fi: IPQ5018 2.4 GHz + QCN6122 5 GHz, both 802.11ax
- Ethernet: 1x Gigabit - IPQ5018 MAC1 (DWMAC) via SGMII/uniphy0 to a
Realtek RTL8211F (MDIO1 addr 6). The SoC internal GE PHY (MAC0/gmac0)
is not wired to any external port and stays disabled.
- LEDs: 5, Buttons: reset + WPS
- Power: 100-240 V AC, 50/60 Hz, 0.4 A (internal PSU, wall-plug)
- UART: 3.3 V serial console, 115200 8N1; on-board 4-pad header,
pinout from top: TX, RX, GND, VCC
MAC addresses (factory_data UBI volume, file default-mac, mounted
read-only in preinit like on the EAP650):
- LAN (label MAC): default-mac
- 2.4 GHz: default-mac + 1
- 5 GHz: default-mac + 2
Calibration data is extracted from the 0:art partition (IPQ5018 at
0x1000, QCN6122 at 0x26800).
Installation:
- From OpenWrt (or after a RAM-boot of the initramfs via U-Boot/TFTP):
sysupgrade.
- From the stock firmware: openwrt-...-squashfs-factory-webflash.bin via
the TP-Link web UI (System -> Firmware Upgrade).
scripts/tplink-re700x-factory.py wraps the rootfs UBI into the stock
"nvrammanager" upload container (the same "tplink2022"/safeloader
family as scripts/tplink-mkimage-2022.py); the stock flasher writes it
into the inactive dual-boot slot. This path has not been tested end to
end (no unit on stock firmware was left), so keep UART at hand for a
first install.
The stock U-Boot passes a slot-correct ubi.mtd= (rootfs / rootfs_1 per the
dual-boot index) but with an unmountable root=mtd:ubi_rootfs. The DTS /chosen
inherits ubi.mtd= and appends root=/dev/ubiblock0_1, so OpenWrt boots from
whichever slot the flasher wrote. Like on the EAP650, sysupgrade installs
into the inactive slot and then points tp_boot_idx at it, keeping the
running slot as a fallback; the U-Boot environment is on 0:appsblenv.
The QCN6122/IPQ5018 board-2.bin (BDF) data is supplied via
ipq-wifi-tplink_re700x (openwrt/firmware_qca-wireless).
Wi-Fi is disabled in the DTS for now: with the default ath11k DP ring
sizes both radios exhaust the 256 MiB of RAM. It will be enabled in a
follow-up together with the ath11k patch that selects smaller rings on
low-memory boards, once that has been accepted upstream.
Signed-off-by: Eduard Hart <eduard.hart@etik.com>
Link: https://github.com/openwrt/openwrt/pull/23982
Signed-off-by: Robert Marko <robimarko@gmail.com>
Move register definitions and constants to the functional source files
and headers that use them. Keep private definitions in their translation
units and shared definitions in the corresponding headers.
Remove unused defines, preserve associated comments and collapse
consecutive blank lines. Adjust includes and move rtldsa_flood_type to
l2.h to avoid circular header dependencies.
Macro values and runtime behavior remain unchanged.
Assisted-by: ChatGPT (OpenAI GPT-6.1 Sol)
Link: https://github.com/openwrt/openwrt/pull/25550
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The switch has a single routing table. The driver tells its routes apart
by the kernel table they came from, but writes every one of them to that
single table, where it matches whatever packet the hardware routes. A
route that only a policy rule selects - one per uplink, the way
multi-WAN setups do it - is then applied to all traffic, and two routes
to one prefix from two tables become two rows for the same destination,
either of which can answer.
Take FIB events from the main and local tables only, for both address
families, and warn about a route from any other: it stays in software.
The local table carries the switch's own addresses, which the driver
traps. A route from another table is set aside before anything else
looks at it, so an IPv4 route there with an IPv6 gateway is no longer
refused.
This is a change for IPv4 as well, which has had the same exposure: a
route in another table was offloaded until now. The RTL839x, whose L3
code runs in a stock build, is affected the same way and 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/25313
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The drop a missed route lookup ends in does not care which family asked,
and neither does the router MAC that feeds it: an IPv4 destination with
no row of its own is dropped in silicon exactly as an IPv6 one was. An
IPv4 connected route reaches the handler, is given a route object and
has the kernel told it is offloaded, and never has a row written for it,
so every host on-link behind this switch is one of those destinations.
Give that family the same last row, from the same helper. It differs
only in which end of the table the block grows from, which the placement
already knows.
This sits here rather than on its own because the row it needs is a row
the table can hold: before the entries were ordered by prefix length a
prefix route lived at the row its id happened to be, and a catch-all
would have had to pin one. The ordering arrived with the IPv6 work, and
with it this became a second call to a function that was already there.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25313
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The router MAC this driver installs matches on any port and any VLAN, so
from the first offloaded route every IP frame addressed to the switch is
pulled into the route lookup. A destination the driver did not program
misses that lookup, and a miss is a drop: not a trap, not a punt to the
CPU, a drop in silicon before anything upstream can see the packet.
A route with no gateway to resolve is never offloaded, so every on-link
prefix is such a destination. Measured on an RTL9303 with two bridge
VLANs, one port each, an address of the switch on both, routing on and
the firewall stopped:
from VLAN 10 to the switch, same VLAN 20/20
from VLAN 10 to the switch, in VLAN 20 20/20
from VLAN 10 to a host on-link in VLAN 20 0/20
The middle line is the control: crossing VLANs works, and it works
because that destination has a row. The third has none, and the drop
counter follows the packets: against an idle span of the same length
that read four, the twenty-packet arm read twenty-four
IPUC_ROUTING_LOOKUP_MISS, while a deliberate VLAN violation over the
same two ports raises VLAN_IGR_FILTER and leaves that counter at zero.
The arms are IPv4 because the miss does not depend on the family: the
router MAC is matched before the lookup and the lookup is what fails.
So the offload makes the switch worse at forwarding than it is with the
offload off, which is a regression and not a missing feature.
The miss itself cannot be steered. The Realtek GPL SDK carries a lookup
miss action in the multicast route controls and in neither of the
unicast ones - rtk_longan_regField_list.c gives L3_IPMC_ROUTE_CTRL and
L3_IP6MC_ROUTE_CTRL a LU_MIS_ACT field and gives the two unicast
registers none. What a unicast row can carry is an action of its own,
and trapping is one of them.
Write that row. One entry, prefix length zero, the trap action and no
next hop, at the end of the block: the rows are ordered longest prefix
first and the hardware answers with the lowest matching row, so every
destination that has a row of its own is answered by it and only what
nothing matches arrives here. What arrives is handed to the CPU, which
is where it would have gone with the offload off.
It costs one of the 127 entries the table holds for IPv6 and it costs
that traffic the hardware path, which it never had. The row is written
where the tables are set up, before the notifiers are registered, so
there is no window in which the tables are live and a destination is
dropped for want of a route that has not arrived yet.
Only a switch whose L3 tables carry the destination writes it, which is
an RTL930x built with the offload symbol, and no subtarget config sets
that. The RTL839x reaches none of this.
This commit writes the IPv6 row only, so the IPv4 arms above are still
answered the same way at this point in the series: the row that answers
them is in the commit after this one.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25313
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The destination column is 24 characters wide, which fits an IPv4 address
and its prefix length with room to spare and an IPv6 one only when it
compresses well. The link-local rows this driver writes take up to 29
characters, an address with nothing to compress takes 43, and the column
they run into is the action, so the two print as one word.
Widen the column, and give the buffer the width the kernel uses for an
address it prints: %pI6c writes a dotted quad for the v4-mapped and
ISATAP forms, which reach 44 characters, and 48 held those but not the
prefix length after them.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25313
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Gennaro Cimmino
Manuel Fombuena
Joseph Chen
Tianling Shen
Max Plekh
Karsten Sperling
Hauke Mehrtens
Grische
John Audia
Shiji Yang
Denis Faizullin
Julius Bairaktaris
Ivan Pavlov
Yangyu Chen
Rustam Adilov
Paul Spooren
Eduard Hart
Markus Stockhausen