*_pie_verify_template() rejected a template that lacked the SIP, DIP,
SMAC or DMAC field a rule needs, but silently accepted one missing the
L4 source/destination port or inner-VLAN fields. When such a template
was picked the corresponding match was simply dropped: a
"flower ip_proto udp dst_port 5353" offload installed against an L2-only
template matched every UDP frame instead of just mDNS.
The same gap exists identically in all four PIE-based SoCs (rtl838x,
rtl839x, rtl930x, rtl931x): each verify_template() stops at the SMAC/DMAC
check and never looks at the L4 port or VLAN fields.
Reject a template that does not carry the port/VLAN field the rule masks,
so the block search falls through to one that does.
The failure was observed on an RTL9302C (Zyxel XGS1210-12, rtl930x): a
dst_port 5353 drop rule also counted UDP sent to other ports. rtl838x/
839x/931x share the same verify_template() structure and template
layout, so the fix is applied there too, though only rtl930x hardware
was available to reproduce and verify it.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The FLOW_ACTION_TRAP handler filled in fwd_data and fwd_act but left
fwd_sel clear, so the PIE never actually selected the forwarding action
and trapped packets were not redirected to the CPU port.
Set fwd_sel like the other forwarding actions do.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The EtherType value in struct pie_rule is a u16, but its mask field was
only u8, so it cannot express a full 16-bit match. Widen the mask to
match the value it applies to.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtl839x_pie_rule_add(), rtl930x_pie_rule_add() and rtl931x_pie_rule_add()
split the PIE blocks into an ingress and an egress half and only scan the
half matching the rule's phase, but the "nothing found" check still
compared against the full block count. For a rule that exhausted its half
the loop then fell through with a stale block/index instead of returning
-EOPNOTSUPP.
Compare against max_block so an exhausted phase range fails cleanly.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
On RTL930x two packet counters share a single LOG table entry, so the
counter ID is halved when addressing the table. rtl930x_packet_cntr_clear()
zeroed one of the two registers and then wrote the whole entry back
without first reading its current contents, wiping the adjacent counter
with whatever stale data happened to be in the table register cache.
Read the entry before modifying one half so the adjacent counter is kept
intact.
Assisted-by: Claude Code (Anthropic Claude Sonnet 5)
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25024
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtldsa_93xx_lag_set_group2ports() gets an already locked table handle
from priv->r->lag_table() and releases it only on the success path, so
both error returns leave the mutex held for good.
The lock covers a whole table access register rather than one of its
tables, so the damage is wider than LAG: on RTL930x that register also
carries VLAN, the ingress ACL, spanning tree state, the packet counters
and port isolation, and every later access to any of them blocks. On
RTL931x the LAG table shares its register with port isolation.
Only the -ENOSPC path can be reached today, when a bond has more than
eight member ports; nothing bounds the member count before it.
Callers cannot reach the -EOPNOTSUPP path because
rtldsa_port_lag_join() already rejects any hash type other than
NETDEV_LAG_HASH_L2 and L23 in rtldsa_83xx_lag_can_offload(), and the
remaining callers pass a NULL info, but the missing release is a trap
for whoever changes that guard.
Not reproduced on hardware: the board here has eight ports, one too few
to trigger the reachable path, and no RTL931x is available.
Compile-tested on realtek/rtl930x and realtek/rtl838x.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25036
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Uboot-Envtools is installed by default on the mpc85xx target.
Add the proper configuration for the Sophos RED 15w, so the fw_*env
commands will actually work.
Fix alphabetic sorting in the case statement while we're at it.
Signed-off-by: Shine- GH <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/24939
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Remove userspace handling for the wifi MAC as nvmem is available to
handle this.
Add label-mac-device support for similar reasons. The ethaddr MAC shows
up on the label on the device.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24699
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
rtpcs_931x_sds_link_sts_get() is marked __always_unused and has no
callers. The active PCS paths now contain the status handling they
require, so remove the dormant SDK-derived diagnostic helper.
Link: https://github.com/openwrt/openwrt/pull/24986
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
pcs_get_state always read the MAC-side link/speed mirror registers,
regardless of SerDes mode. For Clause 37 modes, that mirror can go stale:
a speed renegotiated purely at the SGMII/PCS level is visible in the SerDes
LPA register immediately, but the MAC-side mirror only refreshes when the
MAC force-enable selector is pulsed.
Read the SerDes Clause 22/37 BMSR and LPA registers directly for SGMII,
1000BASE-X and 2500BASE-X, and decode them with the standard phylink helper.
Read BMSR twice because its link status is latched low. Keep all other
SerDes modes on the existing MAC-side mirror path.
When SGMII operates without in-band negotiation, preserve the speed,
duplex and pause settings supplied by phylink; the PCS decoder only updates
link state in that mode.
This fixes PCS state reporting for the SGMII speed-change bug reported on
RTL930x SFP ports. Refreshing the MAC datapath with a force-enable pulse will
be handled separately later.
Link: https://github.com/openwrt/openwrt/issues/23055
Link: https://github.com/openwrt/openwrt/pull/24986
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Both RTL93xx variants use the same link status bit for 10GR links.
Rename the RTL931x helper to rtl93xx so it can be shared by both
variants.
The link status is latched low, so discard the first read and return
the current state from the second. Use the helper in the RTL930x
state-machine initialization instead of open-coding the two reads.
Link: https://github.com/openwrt/openwrt/pull/24986
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace the separate RTL83xx and RTL93xx phylink capability callbacks
with a common implementation.
Add mac_capabilities to the SoC configuration and use it to advertise
the supported link speeds and corresponding SerDes interface modes.
RTL838x and RTL839x support speeds up to 1 Gbps, while RTL930x and
RTL931x additionally support 2.5, 5 and 10 Gbps.
Continue to advertise PHY_INTERFACE_MODE_INTERNAL for all ports.
Do not advertise PHY_INTERFACE_MODE_GMII, as the RTL83xx and RTL93xx
SoCs do not provide a GMII interface between their MACs and PHYs.
When PCS instances are described for a port, copy the supported SerDes
interface modes to pcs_interfaces and register the callback used to
resolve the available PCS instances.
This removes duplicated capability definitions, prevents phylink from
selecting an unsupported GMII interface and provides the basis for
taking the port-specific MAC-to-SerDes mapping into account.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/24992
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Provide two hooks in struct mii_bus
- notify_phy_attach(): called in phy_attach_direct() after PHY
hardware has been initialized and just before PHY is resumed.
- notify_phy_detach(): called in phy_detach() right after PHY
has been suspended.
Link: https://github.com/openwrt/openwrt/pull/25009
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
All mt7622 devices using the RTL8367S switch have been migrated to
the generic rtl8365mb DSA driver. Remove the now-unused RTL8367S_GSW
driver and disable swconfig in the mt7622 kernel config, since no
device in this target needs it anymore.
The driver and its Kconfig symbol are shared across the mediatek
target, so this also drops the tree-wide files/drivers/net/phy/rtk/
sources and the now-dead "# CONFIG_RTL8367S_GSW is not set" line
from the filogic, mt7623 and mt7629 kernel configs.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Migrate Buffalo WSR-2533DHP2, ELECOM WRC-2533GENT and TOTOLINK A8000RU
from swconfig to DSA. These devices use an external Realtek RTL8367S
switch handled by the rtl8365mb DSA driver.
Per-device changes:
- Drop the proprietary mediatek,rtk-gsw node
- Add realtek,rtl8365mb DSA switch with ports lan1-lan4, wan and CPU
- Move CPU port to gmac0 at 2500base-x (HSGMII)
- Remove gmac1 (was 5u@eth1 in swconfig; DSA uses single CPU port)
- Drop unused rgmii_via_gmac2 pin group
- Replace swconfig with kmod-dsa-rtl8365mb
- Bump DEVICE_COMPAT_VERSION (config migration not possible)
- Remove swconfig board setup from 02_network
- Disable CONFIG_RTL8367S_GSW in mt7622 kernel config
CPU link / bandwidth notes:
- Buffalo WSR-2533DHP2 and TOTOLINK A8000RU: already used 2500base-x
on gmac0 before this change; aggregate bandwidth stays the same.
- ELECOM WRC-2533GENT: gmac0 moves from SGMII (1G) to 2500base-x
(HSGMII). The swconfig setup previously used two 1G CPU links
(gmac0 + gmac1) for 2 Gbps aggregate; DSA collapses this to a
single 2.5 Gbps link.
MAC address assignment notes:
- Buffalo WSR-2533DHP2: WAN uses base MAC + 1, gmac0/LAN uses base MAC
(previously the WAN MAC existed on the implicit eth1/gmac1 interface)
- ELECOM WRC-2533GENT: WAN inherits CPU MAC via DSA conduit
(original gmac1 had no nvmem-cells assignment)
- TOTOLINK A8000RU: WAN reuses macaddr_factory_24 (previously gmac1)
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24861
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
rtl839x_packet_cntr_clear() has the same defect as the rtl838x variant:
it zeroes one register of a shared two-register LOG table entry and
writes the entry back without reading it first, so the counter sharing
that entry is overwritten with stale register-cache data.
Read the entry before modifying one half, mirroring the same fix already
applied to rtl930x_packet_cntr_clear().
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25005
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
rtl838x_packet_cntr_clear() zeroes one of the two registers that make up
a LOG table entry and then writes the whole entry back without reading it
first, wiping the adjacent counter with whatever stale data is in the
table register cache. Two 32-bit packet counters share one entry, so the
counter next to the one being cleared is lost.
Read the entry before modifying one half, mirroring the same fix already
applied to rtl930x_packet_cntr_clear().
Signed-off-by: Mark Abe <github@mab.wien>
Link: https://github.com/openwrt/openwrt/pull/25005
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
In order for the firmware package to depend on the corresponding kmod it
needs to be built within the same builtbot phase for the dependency to
land in the package metadata. Select 'nonshared' to force the firmware to
also get built as part of phase1.
Fixes: 1446eff887 ("mediatek: filogic: bpi-r4-pro-8x: add aeonsemi phy to bpi-r4-pro-8x")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The shell mac80211.sh ran both of these with >/dev/null 2>&1:
iw phy "$phy" set antenna $txantenna $rxantenna >/dev/null 2>&1
iw phy "$phy" set distance "$distance" >/dev/null 2>&1
The ucode rewrite dropped the redirect, so on any driver without
->set_coverage_class every wifi up now logs
netifd: radio0 (3302): command failed: Not supported (-95)
with no indication of which command failed. Neither return value is
checked, so the message is pure noise -- but it reads like wifi up
failed, and on ath12k/IPQ5332 it cost real debugging time before the
line was traced back to iw.c:616 rather than to the driver.
Restore the redirect. distance defaults to 0 and antenna to 0xffffffff,
so both calls run on every setup for every radio.
Signed-off-by: Hideo Sumi <hideo.sumi@mugops.com>
Device dts filenames use the lowercase device name across the tree;
the SmartRG boards were the only ones that spell the SDG model
prefix in uppercase. Rename the files and adjust the DEVICE_DTS
values and includes. No functional changes.
Signed-off-by: Chad Monroe <chad@monroe.io>
Link: https://github.com/openwrt/openwrt/pull/24679
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Common specifications:
* MediaTek MT7987A (4x Cortex-A53)
* 4 GiB eMMC
* 1 GiB DDR4 RAM
* 1x 2500M/1000M/100M/10M WAN port (MaxLinear MXL86211C PHY)
* 2x 2500M/1000M/100M/10M LAN ports (MaxLinear MXL86211C PHY,
MT7987 built-in 2.5G PHY)
* 3x LED (green/amber/white) for each Ethernet port
* 2 buttons (Reset, Mesh/WPS)
* uC-controlled RGB LED via I2C
* USB 2.0 type A port
* 3.3V-level 115200 baud UART console
* 12V 3A DC barrel jack power input
SDG-8712: MT7992 dual-band 802.11be Wi-Fi (2.4G 4T4R, 5G 4T5R)
SDG-8732: MT7996 tri-band 802.11be Wi-Fi (2.4G 2T2R, 5G 3T3R, 6G 3T3R)
MAC addresses (base MFG_MAC from the mfginfo partition; the nvmem
cell index in the DTS is added to the base):
wan xx:xx:xx:xx:xx:x0 MFG_MAC
lan1 xx:xx:xx:xx:xx:x1 MFG_MAC + 0x1
lan2 xx:xx:xx:xx:xx:x1 MFG_MAC + 0x1
2.4G xx:xx:xx:xx:xx:x4 MFG_MAC + 0x4
5G xx:xx:xx:xx:xx:xa MFG_MAC + 0xa
6G xx:xx:xx:xx:xx:x6 MFG_MAC + 0x6 (SDG-8732 only)
Both models are also available in versions including 1x FXS POTS
interface for analog phones. Those interfaces are not supported by
OpenWrt.
Installation:
1. Prepare a TFTP server at 192.168.1.10 and serve the OpenWrt
initramfs image, renamed to "openwrt.<engnum>" for the model
being installed:
openwrt.440: SDG-8712
openwrt.442: SDG-8732
2. Connect to LAN2.
3. Connect to the UART port.
4. Power on the device and type "st" to enter the U-Boot command
line. The window to do that might be very short (below 1s), so
type it as soon as the "U-Boot ..." string appears.
5. Run "setenv boot_mode openwrt; saveenv" to boot from OpenWrt
partition by default.
6. Run "bootmenu" and select option 6 (TFTP openwrt image and
boot); "run boot5" is a shortcut for the same. This downloads
openwrt.<engnum> from the TFTP server and boots it.
7. After OpenWrt finishes booting, download the OpenWrt sysupgrade
image and write it to eMMC using "sysupgrade".
8. After sysupgrade finishes writing, the device reboots into
OpenWrt. When the front LED is solid white the device is ready
for configuration.
Signed-off-by: Chad Monroe <chad@monroe.io>
Link: https://github.com/openwrt/openwrt/pull/24679
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Both families limit the frame length of the whole switch in a single
register instead of one per port, so the operation programs it from the
largest MTU of any user port rather than from the port it is handed.
Lowering one port therefore lowers the limit only once no other port
asks for more. RTL838x mirrors that register in a second one and the
vendor SDK writes both, in dal_maple_switch_maxPktLenLinkSpeed_set(),
so this does the same.
These are the first users of the switch-wide path the infrastructure
came with. With their entries in place an MTU can be set on any port of
any of the four families, and the maxima are the ones the ethernet
driver already uses: 10000 on RTL838x, which is what its datasheet gives
and what its rmon range counts, and 12288 on RTL839x.
Nothing programmed these registers until now, so a port keeps whatever
value it comes up with, and a switch that today forwards frames larger
than its ports announce stops doing so once they are programmed at the
default MTU. Asking for them by configuring the MTU works from here on.
Not tested on hardware: no RTL838x or RTL839x here.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/24400
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
RTL931x holds the same per port maximum L2 frame length register as
RTL930x, with the same field layout: two 14 bit lengths, the high speed
one in [13:0] and the 10/100M one in [27:14], and the tag inclusion bit
in [28]. Only the placement differs. RTL930x keeps it inside the 64 byte
per port MAC block, while RTL931x has a compact array of its own at
0x5554, so the family needs nothing beyond the callback and its largest
frame.
The GPL SDK register list gives that address and covers ports 0 to 55
with it, leaving out the CPU port, 56. The stride follows from the array
spanning the 224 bytes up to the next register, MAC_DBG_SEL_CTRL at
0x5634: 56 words of four bytes.
The CPU port needs no row anyway, as the ethernet driver programs both
of its directions from MAC_L2_CPU_MAX_LEN_CTRL, unlike RTL930x whose
equivalent register holds one direction and leaves the other in the row
of the array. The shared operation returns before the write for the CPU
port, so 0x5634 is never addressed.
Nothing programmed those registers until now, so a port keeps whatever
value it comes up with while its netdev announces an MTU of 1500.
Not tested on hardware: no RTL931x here.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/24400
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Fill in the config entries for RTL930x: the callback returning the
register that holds the MAC maximum accepted L2 frame length of a port,
one per user port at 0x326C + (port << 6) from the reverse engineered
maps at svanheule.net, and the largest frame the family switches, from
which the advertised maximum MTU is derived. The programmed limit is the
MTU plus Ethernet header, two stacked VLAN tags (802.1ad QinQ) and FCS.
RTL838x, RTL839x and RTL931x carry no entries yet, so they keep refusing
MTU changes and advertising the ether_setup() default.
This changes what a user port accepts. Nothing programmed these
registers until now, as the ethernet driver only writes the CPU port row
of the same register, so a port kept whatever value it came up with
while its netdev announced an MTU of 1500.
Measured on an RTL9303, frames probed from a host with ping -M do and
the ports configured through UCI alone. On main a port announces a
maximum MTU of 1500 and takes frames up to 1530 bytes, which is the CPU
port limit the ethernet driver derives from the conduit MTU, 1504 plus
the overhead, rather than anything the port enforces; asking for an MTU
of 9000 leaves every port at 1500 and the boundary at 1530. With this
commit the port announces 12258 and the boundary follows the MTU: 1526
bytes by default, 9026 with the ports at 9000, and 1526 again once the
MTU is removed from the configuration.
Probing the same boundary through VLAN devices, with the ports at 9000,
gives 9030 bytes carrying one 802.1q tag and 9026 carrying a 802.1ad tag
with a 802.1q one inside. So the eight bytes the limit sets aside for
stacked tags are what the QinQ case takes, and a single tagged frame has
four of them to spare.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/24400
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Add the port_change_mtu and port_max_mtu operations, wire them into both
the RTL83xx and RTL93xx dsa_switch_ops, and put in place what the per
family support needs: the encoding of the MAC maximum length fields, the
config entries naming the register a family limits its frames with, and
the largest frame it switches.
Nothing is enabled here. No config carries a largest frame yet, so
port_max_mtu keeps returning the ether_setup() default the user
netdevices already advertised, and port_change_mtu keeps returning the
-EOPNOTSUPP the DSA core returns on its own while the operation is
absent. The families are turned on one at a time in the commits that
follow, each filling in nothing but its own config entries.
The CPU port is skipped in the shared operation rather than in a family
callback, though the reason differs. On RTL930x its row of that register
is the one the ethernet driver programs from the conduit MTU, and the
two values would not agree: the DSA core raises the conduit MTU by the
tagger overhead but hands this operation the plain largest user MTU, and
it does so afterwards, so the write here would land last and shorten the
limit by exactly that overhead. On the other three families the CPU port
has no row of its own. Skipping it in one place covers both cases.
Families whose limit is one register for the whole switch are served by
the same operation, programming it from the largest MTU of any user
port; the first users of that path are in the last commit of the series.
The DSA core takes a different route once the operations exist: instead
of bailing out early it sets the conduit MTU and rolls it back, so the
conduit change_mtu operation runs twice per user port at probe, and
twice more on any MTU request this commit then refuses. It is only
called at all because the ethernet driver has one, and at probe it
touches no hardware, as the conduit is still down at that point and the
operation returns before programming anything.
Not tested on hardware in this shape. What was tested on an RTL9303 is
what it reduces to while no config carries a largest frame, the two
operations as bare stubs returning those same two values: the advertised
maximum, the errors an MTU change returns, the conduit at 1504, the boot
log and ordinary traffic were all indistinguishable from the tree
without it.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/24400
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Every link of an AP MLD can hold an entry for a station while only the
association link says where it is listening. Taking the first link that
has an entry sent the frame out on a link the station is not on, so a
BTM Request addressed to a station on the 5 GHz link went out on 2.4 GHz
and the station never saw it.
Prefer the link whose entry names it as the association link, and keep
any other entry only as a fallback for a station no link claims.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
hostapd_bss_transition_request() left mbo_reason, cell_pref and
reassoc_delay uninitialised and assigned them only when the caller named
them, while hostapd_bss_tr_send() built the MBO attributes from all
three unconditionally.
A caller that names none of them, which is every caller that only wants
a plain BTM Request, therefore had whatever the stack held validated and
then written into the frame. Where the leftovers failed validation the
request was refused with an invalid argument and no BTM Request frame
was transmitted at all; where they passed, the frame carried a random
transition reason and cellular preference. Which of the two happened
varied between calls, so client steering failed intermittently with no
diagnostic.
Initialise the three, and build the attributes only when the caller
asked for MBO. Name the cellular preference constants while touching
the validation.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
A station associates over one link of an AP MLD and its sta_info lives
on that link's BSS. A ubus method resolves its hostapd_data from the
object it arrived on, and only the BSS that registered the shared
interface name owns an object, so a method addressed to a station on any
other link looked it up on the wrong BSS.
bss_transition_request returned NOT_FOUND for those stations, so no BTM
Request frame was ever transmitted: hostapd's bss_transition_request_tx
counter stayed put across a whole run of client steering mandates.
del_client likewise failed to deauthenticate them, which left
association control unable to block a client of an AP MLD.
Walk the affiliated links, as hostapd_get_sta_ies_sta() already does for
the association frames, and act on the BSS that holds the station.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The BSSes of an AP MLD share one interface name, so only the first BSS
registers hostapd.<iface> and holds the subscribers. ubus_add_object()
fails for every other link and its return value is discarded, leaving
those links with an object that never has a subscriber.
hostapd_ubus_notify_obj() already resolves this, but only the generic
hostapd_ubus_notify() used it. Every other emitter still tested and
notified hapd->ubus.obj directly, so an event raised on a link other
than the first was dropped without a trace.
sta-authorized is the one that hurts: a station that associates over any
link but the first is never announced. umap-rrmd builds its station
table from that notification, so it never learns the station, and client
steering fails with "rrmd accepted 0 of 1 mandate STAs" for every client
of an AP MLD. bss-transition-response, beacon-report and the association
decision in hostapd_ubus_handle_event() are lost the same way.
Route them all through hostapd_ubus_notify_obj(). A BSS that is not an
MLD link, or one whose own object has subscribers, is unaffected.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The commit adding support for the Zyxel XMG1915-10E didn't carry a
dedicated memory node in the DTS. The device has actually 256MiB, but
because this node is missing from the DTS, it falls back to the
128MiB-sized memory node in rtl930x.dtsi.
The commits refactoring support for XMG1915-10E and adding support for
XMG1915-10EP didn't fix that either. Thus, add the needed memory node to
unlock the full memory.
Fixes: 94607d6285 ("realtek: add support for Zyxel XMG1915-10E")
Fixes: bdddc753c5 ("realtek: add support for Zyxel XMG1915-10EP")
Link: https://github.com/openwrt/openwrt/pull/24984
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
With below patch merged upstream, the qca8k driver can use the external
MDIO bus instead of its internal one. This fixes the issue of the LED
names when an external MDIO bus is used.
LED names were prefixed with "(efault)" because the driver was hardcoded
to use the internal MDIO bus when naming the LEDs as the internal bus
was NULL. This forced the LEDs to be populated under the internal bus.
In addition, the internal MDIO will likely be removed from the driver in
the future.
So let's move the PHYs from the internal MDIO bus to the external bus,
the one from the SoC, in line with all other boards, and rename the LED
names.
link: https://github.com/torvalds/linux/commit/0b7b378ce6cafbb948786cb6f17f406d94016c8c.patch
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24927
Signed-off-by: Robert Marko <robimarko@gmail.com>
Fix the image size limit for TP-Link TL-ST1008F to 29696k. The firmware
partition has a size of 0x1d00000, thus the previous limit is wrong. It
was just copied without proper checking from another device.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The firmware partition and IMAGE_SIZE were inherited from
rtl9303_tplink_tl-st1008f-v2.dts and describe a 32 MiB SPI-NOR. This
board has a 16 MiB chip, so the kernel truncates the partition on every
boot:
[ 0.679519] 6 fixed-partitions partitions found on MTD device spi0.0
[ 0.687292] Creating 6 MTD partitions on "spi0.0":
[ 0.740421] mtd: partition "firmware" extends beyond the end of device "spi0.0" -- size truncated to 0xd00000
The chip identifies itself as a Winbond W25Q128 (128 Mbit / 16 MiB):
# cd /sys/bus/spi/devices/spi0.0/spi-nor
# cat jedec_id manufacturer partname
ef4018
winbond
w25q128
and the resulting partitions end exactly at the top of a 16 MiB chip:
dev: size erasesize name
mtd0: 000e0000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "u-boot-env2"
mtd3: 00100000 00010000 "jffs2-cfg"
mtd4: 00100000 00010000 "jffs2-log"
mtd5: 00d00000 00010000 "firmware"
The vendor firmware uses the same layout and also ends at 0x1000000, so
16 MiB is what the product ships with rather than a smaller variant.
Correct both values to describe the hardware. The result matches the
other RTL9303 boards that use this Realtek reference layout on 16 MiB
flash, notably the Vimin VM-S100-0800MS and the Sirivision SR-ST3408F,
which both use <0x300000 0xd00000> and IMAGE_SIZE := 13312k.
No released image has ever exceeded the truncated size (the current
snapshot sysupgrade image is 5.6 MiB) and mtdsplit already derives
rootfs_data from the truncated partition, so existing installations are
unaffected and no compat version bump is needed. The bug is latent:
check-size currently accepts images up to 29696k, more than twice what
the flash can hold.
Fixes: fbbc36c136 ("realtek: add support for NicGiga S100-0800S-M")
Signed-off-by: Greg Patrick <gregspatrick@hotmail.com>
Link: https://github.com/openwrt/openwrt/pull/24982
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Refresh patches to fix CI builds. The refresh was missed with the former
change adding an additional backport patch.
Refreshed with 'make target/linux/refresh V=99'.
Fixes: 5322f1d79b ("generic: 6.18: mxl862xx enable assisted learning on CPU port")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The GPIO direction was configured via the gpiod flags passed to
devm_fwnode_gpiod_get_index(), i.e. at request time. Restore the prior
behavior of requesting the GPIO as-is (GPIOD_ASIS) and setting the
direction afterwards with gpiod_direction_output_raw() /
gpiod_direction_input().
Note this deliberately does not restore the old skip-and-continue error
handling: before 0ca7895 a failing request or direction setup was skipped
with continue, leaving that GPIO unexported while the rest of the board
still came up. Direction setup failures now abort the probe, consistent
with the request failure handling introduced by 0ca7895. gpiod flags are
also not used for the direction since legacy gpio_request_one() applied
the initial output value raw (ignoring active-low), which
gpiod_direction_output_raw() matches.
Fixes: 0ca7895173 ("kernel: use fwnode for GPIO export driver")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24832
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The GS1920-24 v1 is the non-PoE, fanless sibling of the already
supported GS1920-24HP v1 (ZyNOS firmware code AAOB vs. AAOC) and
shares its board layout and flash map.
Hardware:
* SoC: Realtek RTL8392M
* Flash: 16 MiB SPI NOR (Macronix MX25L12835F)
* RAM: 128 MiB DDR3
* Ethernet: 24x 10/100/1000BASE-T (3x RTL8218B),
4x combo RJ45/SFP (RTL8214FC)
* Hardware monitor: Analog Devices ADT7463C
* LEDs: PWR, SYS, ALM, LOCATOR, per-port link/activity
* Buttons: 1x reset (front)
* UART: RS-232 level (not TTL) on header J2, DCE pinout
(Tx pin 2, Rx pin 3, GND pin 5), 9600 8N1
* Power: 100-240 V AC, 50/60 Hz, 25.9 W max
* No PoE, no fan
MAC address:
* Ethernet: factory MAC from the bootbase partition at offset 0x1fff8
through the factory_macaddr nvmem cell
* ethernet0 is the label MAC device; 02_network uses this address for
the LAN/bridge without assigning individual per-port MAC addresses
The hardware monitor at I2C address 0x2e was identified on hardware
as an ADT7463C from company ID 0x41 and VERSTEP 0x6a. The GS1920-24HP
v1 uses an ADT7468, while the v2 uses an lm85-family hardware monitor
at the same address.
All GS1920-24 variants use hardware monitors supported by
kmod-hwmon-lm85. The shared GS1920 device recipe therefore supplies
that package, while the GS1920-24HP-specific recipe additionally
supplies the PSE driver.
Installation:
1. Connect to the console. Optionally switch BootBase to
115200 baud with ATBA5 (and reconnect at that rate).
2. Load an initramfs image into RAM: ATUP80100000, send the
image via XMODEM, then ATGO80100000.
3. Copy loader.bin and the sysupgrade image to /tmp on the
running initramfs system.
4. Flash both:
mtd write /tmp/loader.bin loader
mtd write /tmp/*-squashfs-sysupgrade.bin firmware
5. Reboot.
The SFP side of the combo ports is untested (no modules available);
the copper side of all 28 ports works.
Tested on hardware: Flash installation and runtime operation verified.
Signed-off-by: David Evans <git@d4vid.uk>
Link: https://github.com/openwrt/openwrt/pull/24962
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Split the GS1920-24 device tree description into common hardware,
RTL8392 v1-specific hardware and GS1920-24HP-specific PoE parts.
Move the PSE controller node and per-PHY pses references from the
GS1920-24HP common dtsi into an HP-specific overlay, leaving a PoE-free
rtl839x_zyxel_gs1920-24-common.dtsi. This allows the non-PoE
GS1920-24 v1 to share the common hardware without inheriting dangling
PSE references, which would otherwise defer PHY probing.
Keep the shared i2c4 bus in the common dtsi because it also carries the
board hardware monitor; only the PSE controller is HP-specific.
The GS1920-24 v1 and GS1920-24HP v1 also share RTL8392-specific board
details, including memory size, console settings, flash layout and
combo-port configuration. Factor these into a separate
rtl8392_zyxel_gs1920-24-v1-common.dtsi.
Likewise split the image recipe into GS1920 family-common and
GS1920-24HP-specific parts. Keep kmod-hwmon-lm85 in the common recipe
and leave the PSE driver HP-specific.
No functional change is intended for the existing GS1920-24HP
devices. The generated GS1920-24HP v1 and v2 DTBs are byte-identical
before and after this commit.
Signed-off-by: David Evans <git@d4vid.uk>
Link: https://github.com/openwrt/openwrt/pull/24962
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The MxL862xx driver enables FDB isolation but does not enable assisted
learning on the CPU port. Consequently, MAC addresses learned through a
physical switch port are not updated in hardware when the corresponding
station moves to a foreign bridge port, such as a Wi-Fi interface.
The stale hardware FDB entry continues directing return traffic toward
the original physical port. Traffic entering that same port is then
filtered instead of being forwarded to the CPU and software bridge. This
causes downstream unicast traffic, including DHCP OFFER and ACK packets,
to disappear after a client roams to a local wireless interface. The
client eventually considers the connection unusable and disconnects.
Enable assisted CPU-port learning so DSA installs foreign bridge FDB
entries on the CPU port. This keeps the hardware FDB synchronized with
the software bridge and allows return traffic to reach locally attached
Wi-Fi clients after roaming.
Tested on a BPI R4 PRO with a MxL862xx switch and a BE14000 WiFi interface.
- Without patch, wired uplink on lan6 port (mxl path)
Wifi clients connect but roam away not getting DHCP offers
- Without patch, wired uplink on wan port (no mxl path)
Wifi clients connect and roam successfully
- With this patch, uplink on lan6 (mxl path)
Wifi clients connect and roam successfully
Fixes: 340bdf984613 ("net: dsa: mxl862xx: implement bridge offloading")
Signed-off-by: Edoardo Pinci <epinci@outlook.com>
Link: https://patch.msgid.link/DU0P251MB069949C6DEB4D1D51F31FE87C4A02@DU0P251MB0699.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add the two external Aeonsemi AS21xxx PHYs used by the LAN and WAN
10GBASE-T ports of the BPI-R4 Pro 8x. Configure their firmware, reset
timing and LEDs, and connect them to the MxL switch and GMAC1.
Replace the fixed SFP GPIO hog configuration with LAN and WAN overlays
selecting either the copper PHY or the corresponding SFP cage. Build all
four overlays, include them in the device image and select the SFP
overlays by default through U-Boot `bootconf_extra`.
Make the AS21xxx firmware package pull in the PHY driver on Linux 6.18,
instead of making the driver depend on the firmware. Update existing
Airoha device package lists accordingly so they continue to install both
components through the firmware package.
Breaking change for users using the router with SFP hogs from PR #21083.
After flashing the new image, configure `bootconf_extra` to select
between SFP or PHY overlays:
fw_setenv bootconf_extra \
mt7988a-bananapi-bpi-r4-pro-8x-lan-phy#mt7988a-bananapi-bpi-r4-pro-8x-wan-phy
If bootconf_extra had additional overlays (CN13 or CN14) keep them appended
Signed-off-by: Pietro Ameruoso <p.ameruoso@live.it>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Add several fixes for reliable operation of Aeonsemi AS21xxx PHYs.
Discard stale Clause 45 responses, refresh invalid cached PHY IDs during
driver matching, and recover shifted IDs reconstructed from adjacent PMA/PMD
and PCS responses. Configure AS2101x DPC rate adaptation at the correct
stage, use the firmware arbitration state for link detection, and expose
the supported multi-gigabit BASE-T modes.
Recover an unresponsive firmware IPC interface after warm reboot by
resetting the PHY, reloading its firmware, and synchronizing IPC again.
Also provide a default link and activity LED configuration for all supported
variants and report the link partner's 2.5G, 5G, and 10G capabilities
correctly through ethtool.
Signed-off-by: Pietro Ameruoso <p.ameruoso@live.it>
Move the existing AS21xxx patch series from the Airoha target to the
generic 6.18 patch set so it is available to all targets.
Promoting the PHY detach patch to the generic patch set changes the patch
application order. Refresh the affected generic, Layerscape, and ramips
patches without functional changes.
Signed-off-by: Pietro Ameruoso <p.ameruoso@live.it>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Mark Abe
Shiji Yang
Gennaro Cimmino
Shine- GH
Rosen Penev
Jonas Jelonek
Jan Hoffmann
Rustam Adilov
Markus Stockhausen
Mieczyslaw Nalewaj
Daniel Golle
Hideo Sumi
Tianling Shen
Chad Monroe
Felix Fietkau
Andrea Pesaresi
George Moussalem
Greg Patrick
David Evans
Edoardo Pinci
Frank Wunderlich
Pietro Ameruoso