Til Kaiser [Sun, 1 Feb 2026 15:42:46 +0000 (16:42 +0100)]
ipq40xx: refresh IPQ4019 switch patch for v6.18
Linux 6.18 adjusts the DSA/phylink integration and removes a couple of
interfaces used by the out-of-tree IPQ4019 built-in switch support.
Update the qca8k-ipq4019 patch to match the new APIs:
- move phylink callbacks to phylink_mac_ops and switch to phylink_config
[1], [2]
- adapt pcs_get_state() to the new signature [3]
- drop get_mac_eee() from dsa_switch_ops [4]
- switch platform_driver from .remove_new to .remove [5]
Til Kaiser [Fri, 27 Feb 2026 19:46:15 +0000 (20:46 +0100)]
kernel/ipq40xx: restore files for v6.12
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
A script was ran that checks the label-mac-device node to see if it has
nvmem definitions as label-mac-device requires nvmem.
This is mostly a change to make the script happy. No indended functional
difference.
Add a change to qca9533_yuncore_cpe830.dts adding an nvmem definition to
wmac. Seems to have been some kind of oversight where it's specified in
nvmem but not used. label-mac-device needs an NVMEM definition.
On 25.12.0 the device has not enough free blocks to initialize overlay.
Move the device to tiny target and consume backup with storage
partitions, which were previously unused. This operation will reclaim
~800 KiB of flash memory. OEM used storage partition for configuration,
while backup was used to store copy of U-Boot environment and copy of
calibration data.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Partially revert 5e3a602def72. Unfortunately the ethaddr value in U-Boot
environment is enclosed in double quotes which makes it longer than
ETH_ALEN, thus nvmem returns EINVAL. Switch back to handling the MAC
addresses in user space.
Fixes: 5e3a602def72 ("ath79: sitecom,wlrx100: use nvmem") Reviewed-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Rosen Penev [Sat, 2 May 2026 21:41:43 +0000 (14:41 -0700)]
ath79: use led-sources for WMAC
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
Rosen Penev [Sun, 3 May 2026 21:14:32 +0000 (14:14 -0700)]
ath79: fap-221-b: revert led-sources change
Normally WMAC handles 2.4ghz on ath79 devices. Some older units though
handle 5ghz on WMAC and 2.4ghz on pcie. This can be seen by the
frequemcy limits placed on each interface.
Rosen Penev [Sat, 24 May 2025 23:02:54 +0000 (16:02 -0700)]
ath79: qca953x: use led-sources for WMAC
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
Rosen Penev [Sun, 25 May 2025 00:40:41 +0000 (17:40 -0700)]
ath79: qca955x: use led-sources for WMAC
The ath9k driver creates an ath9k LED by default. Instead of having a
non functional LED, configure it properly and remove the extra as it's
not needed.
It's also a bit funny matching against phy0 and phy1 when both differ
between ath9k and ath10k.
realtek: mach/prom: add identifiers to soc_info structure
SoC name and system type identifiers are currently separated from
the soc_info structure. This gives no benefit. Relocate that info
into the structure where it belongs.
Jonas Jelonek [Mon, 27 Apr 2026 10:34:27 +0000 (10:34 +0000)]
realtek: pcs: rtl93xx: share IP mode register write
RTL930x and RTL931x program the same physical SerDes IP mode field
(page 0x1f reg 0x09, bits 11:7 hold the 5-bit mode value, bit 6 is
the "force mode" enable), but did so via two unrelated code paths:
RTL930x kept the force bit separate from the value in a __set helper,
while RTL931x had it baked into each switch-case constant.
Add a shared rtpcs_93xx_sds_set_ip_mode() that takes the rtpcs_sds_mode
enum, looks up the 5-bit value from the existing sds_hw_mode_vals
table, and writes value | force-bit in one place.
Convert both variants:
- RTL930x: drop __rtpcs_930x_sds_set_ip_mode and the manual table
lookup; __rtpcs_930x_sds_get_ip_mode is replaced by the shared
rtpcs_93xx_sds_get_ip_mode, which reverse-looks the raw register
value up in sds_hw_mode_vals[] and returns the matching enum
rtpcs_sds_mode (or -ENOENT for an unmapped raw value). The
wrapper that orchestrates power, CMU, state machine and rx-reset
around the mode write is renamed to rtpcs_930x_sds_apply_ip_mode
for clarity.
- RTL931x: drop the per-mode switch and the leftover pr_info debug
print; rename the symerr-clear + MAC-OFF + IP-mode-write wrapper
to rtpcs_931x_sds_apply_ip_mode.
rtpcs_930x_sds_reconfigure_to_pll() now goes through the new shared
get/set helpers: it saves the current IP mode as an enum on entry
and restores it via the enum-taking setter after the PLL reconfigure.
This changes behavior by mapping the raw mode setting through the
hardware mode table, effectively blocking unknown modes which might be
set by bootloader or somewhere else. This is intended and might uncover
unknown behavior instead of hiding it.
As a side-effect, QSGMII is now properly set too for RTL931x. Most code
paths anyway already had support for this mode, but it was missing from
the mode setting.
Christoph Krapp [Mon, 4 May 2026 07:23:13 +0000 (09:23 +0200)]
ath79: add calibration variant for TP-Link EAP225-Wall v2
Now that we have a board file, add calibration variant for TP-Link
EAP225-Wall v2 and add ipq-wifi package for it.
Tested-by: Alexander <52272120+alexxela1337@users.noreply.github.com> Signed-off-by: Christoph Krapp <achterin@gmail.com> Link: https://github.com/openwrt/openwrt/pull/23216 Signed-off-by: Robert Marko <robimarko@gmail.com>
Jonas Jelonek [Thu, 30 Apr 2026 10:55:36 +0000 (10:55 +0000)]
realtek: image: reset COMPILE between devices
Device/zyxel_zynos sets COMPILE := loader-$(1).bin to drive the
standalone rt-loader build, but include/image.mk's Device/Init does
not reset COMPILE between TARGET_DEVICES iterations. When a non-zynos
device follows a zynos device, the stale COMPILE entry survives and
Device/Build/compile registers a second recipe for the previous
device's loader-*.bin target. Make warns about the override and the
second (wrong) recipe wins.
Reset COMPILE in Device/Default so each device starts with a clean
slate.
Jonas Jelonek [Thu, 30 Apr 2026 10:54:33 +0000 (10:54 +0000)]
realtek: image: pin FLASH_ADDR per device
FLASH_ADDR is referenced inside Build/rt-loader-standalone but is not
listed in DEVICE_VARS, so include/image.mk's Device/Export does not
emit a per-target FLASH_ADDR := <value> assignment for the standalone
loader recipe. At recipe expansion time $(FLASH_ADDR) therefore
resolves to whatever value the last device in TARGET_DEVICES set
globally, which is not necessarily the value belonging to the loader
being built.
This currently happens to produce correct binaries only because every
device that sets FLASH_ADDR within a given subtarget shares the same
value, so the leaked global matches by coincidence.
Add FLASH_ADDR to DEVICE_VARS so each loader recipe captures its own
device's address.
Zoltan HERPAI [Tue, 5 May 2026 22:41:54 +0000 (22:41 +0000)]
starfive: 6.18: update LED aliases
Between 6.12 and 6.18, a 'blank' led_status_power has been added into
jh7110-common.dtsi. Update the patches responsible for adding the LED
aliases and add functionality for this LED entry.
The mdio driver has found a simple way to handle phy addresses
for all devices with upstream kernel defaults. Remove all unneeded
hacks from the corresponding patch and reword it.
While we are here increase DSA_MAX_PORTS to 56 to match RTL931x.
- mdio bus 0 serves ports 0..23
- mdio bus 1 serves ports 24..51
This is baked into hardware and cannot be changed during mdio driver
setup with any register write. With the recent changes the driver
handles ports, phys and busses in a more logical way. So a port X
is assigned to a bus Y and a phy Z (on that bus). This gives a
mapping like
- port 16 <=> bus 0, address 16
- port 32 <=> bus 1, address 8
This unique assignment is used in the mdio driver as follows:
- Request to read bus 1, address 8
- Lookup corresponding port = 32
- Read from port 32
Looking at RTL839x it becomes clear that bus/phy => port lookup can
be achieved in multiple different ways. The simple reason is, that
for this device the driver cannot setup the smi topology. It is
baked into the hardware. So adding a "virtual" second bus does not
change the hardware access but allows to keep phy addresses below 32.
Making an example
mdio_bus0 {
PHY_C22(40, 40)
}
resolves to port 40. But the same can be achieved with
mdio_bus1 {
PHY_C22(40, 16)
}
In the first case the kernel sees bus/phy = 0/40 and in the second
case it sees bus/phy = 1/16. Both result in the access to the same
phy device on hardware port 40.
Use this analogy for RTL839x devices to match the real hardware
topology. For this change the existing dts and
- activate mdio bus 1 in rtl839x.dtsi
- rearrange devices with ports 24..51 to make use of bus 1
The lm75 alert polarity active-high patch has been accepted upstream.
Replace the downstream version. Additionally add an upstream bugfix
that was identified during the implementation.
Edward Chow [Mon, 27 Apr 2026 03:13:51 +0000 (11:13 +0800)]
mpc85xx: unify wrapper address of simple image devices
The wrapper address of simple image devices should have been changed
at commit 6a8b831 , but only TL-WDR4900 and BR200-WP are changed at
that time, and now the wrapper address changes are split among patches
for specific devices. More importantly, commit 6a8b831 forgot to
change Enterasys WS-AP3715i, causing
https://github.com/openwrt/openwrt/issues/23112 .
This commit will gather the change of wrapper address of simple image
devices into a dedicated patch file.
Tested: Both WS-AP3715i and TL-WDR4900 v1 boot well.
Fixes: https://github.com/openwrt/openwrt/issues/23112 Signed-off-by: Edward Chow <equu@openmail.cc> Link: https://github.com/openwrt/openwrt/pull/23121 Signed-off-by: Robert Marko <robimarko@gmail.com>
Edward Chow [Wed, 29 Apr 2026 21:52:10 +0000 (05:52 +0800)]
mpc85xx: ws-ap3715i: use libdeflate-gzip for kernel
The simpleImage contains a payload already compressed with lzma-based
xz (by default), so further compressing it with lzma will often make
the result larger. On the contrary, compressing these simpleImages
with gzip can make the result smaller, so replace lzma with
libdeflate-gzip to compress kernel for ws-ap3715i.
Edward Chow [Tue, 28 Apr 2026 03:29:01 +0000 (11:29 +0800)]
mpc85xx: ws-ap3715i: enable access to u-boot env
find_mtd_part() outputs /dev/mtdblockX, to which fw_setenv cannot
write, "/dev/mtd$(find_mtd_index '<vol name>')" could be used instead.
The envsize should also be changed to 0x1000 to make the CRC checksum
valid and the env block recognized by the uboot-envtools, but the
flash sector size remains 0x10000, otherwise the env block will be
readable but not writable.
The "read-only" mark within device tree is also removed.
Add the basic bits to allow 100base-FX SFP mode on the RTL8214FC.
While this looks good fom ethtool perspective, it does not really
change the phy registers to enforce the mode. The SFP is still
driven in 1000base-X.
While it might seem useless at the moment this at least opens
up a new phy control method. This comes handy with one known bug.
In rare cases a SFP that is plugged in during boot does not get
a link. One option to revive the dead port seems to be
root@OpenWrt:~# ethtool -s lan28 speed 100 duplex full autoneg off
rtl83xx-switch 1b000000.switchcore:ethernet-switch lan28: Link is Up - 100Mbps/Full - flow control off
switch: port 28(lan28) entered blocking state
switch: port 28(lan28) entered forwarding state
rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
rtl83xx_fib_event: FIB_RULE ADD/DEL for IPv6 not supported
Maximum devnum in c45 access is only 31. The bits 21-31 of the MMD
register are reserved and cannot be written. Nevertheless add a
proper mask to help AI review bots.
rtmdio_probe_one() should be only called by rtmdio_probe() after it
has validated the dts input. Nevertheless be defensive and add
another consistency check.
Rename the module to describe that it is for the Realtek Otto
switches. Add owner to make clear who takes care. Adapt the
license to match the SPDX header.
realtek: mdio: avoid access to uninitialized variable
The read functions might fail and thus "val" might be uninitialized.
The debug function will output the undefined state. Set the value
to zero to be consistent.
realtek: mdio: add define for RTL839x C22 reads/writes
The RTL839x allows to add an extended page operator during phy
access. This is not needed for the standard linux kernel C22
access. Give the hardcoded 0x1ff value a meaningful define.
Although it is not needed, add the corresponding register define.
This makes clear where the mask belongs to.
realtek: mdio: focus on c22/c45 bits in rtmdio_931x_setup_ctrl()
The rtmdio_931x_setup_ctrl() function currently initializes the c22/c45
and the proprietary format bit of the controller. This works because of
the order these calls are arranged. Narrow down the update to the really
needed bits.
- c22/c45 (bit 1) is updated here
- standard/proprietary (bit 0) is updated in rtmdio_931x_setup_polling()
Adapt the confusing comment "Std. C45, non-standard is 0x3" it basically
explains the other function.
realtek: mdio: refactor RTL930x port ability setup
Provide a separate function to setup the ability (SDS/MDIO) of a RTL930x
port. This simplifies rtmdio_930x_setup_polling(). With this commit the
driver does no longer unconditionally overwrite reserved register bits.
Add a return value for the new function to indicate failure/success. As
of now this will be silently ignored in the caller. A future commit will
take care about that.
realtek: mdio: refactor RTL931x port ability setup
Provide a separate function to setup the ability (SDS/MDIO) of a RTL931x
port. This simplifies rtmdio_931x_setup_polling(). With this commit the
driver does no longer unconditionally overwrite reserved register bits.
Add a return value for the new function to indicate failure/success. As
of now this will be silently ignored in the caller. A future commit will
take care about that.
realtek: mdio: add missing brackets to RTMDIO_PHY_POLL_MMD
With its current usage type RTMDIO_PHY_POLL_MMD() definition is ok.
But for the sake of consistency add brackets around the macro
parameters and use masks to avoid calculation inconsistencies.
The mdio hardware is fully understood. Describe the number of real
busses in the configuration structure and check against this limit
when working on busses.
Try to describe the hardware capabilities with consistent defines
and configuration variables. As raw_page is always num_pages - 1
better use num_pages naming where needed and provide a macro that
converts this naming.
While we are here:
- Sort the configuration variables alphabetically
- Provide num_pages defines per architecture
- adapt RTMDIO_839X_C22_DATA() macro to use the new define
Magnus Kroken [Thu, 23 Apr 2026 18:12:51 +0000 (20:12 +0200)]
mbedtls: backport upstream patches to fix TLS 1.2 client issues
Fix a TLS 1.2 regression that caused clients to reject valid
ServerKeyExchange signatures using RSA-PSS signature algorithms.
The TLS 1.2 regression resulted in errors like:
$ curl https://api.domeneshop.no/v0/
curl: (35) ssl_handshake returned: (-0x6600) SSL - A field in a message was incorrect or inconsistent with other fields
Fixes: https://github.com/openwrt/openwrt/issues/22874 Fixes: https://github.com/openwrt/openwrt/issues/23116 Fixes: f48ef0040b7e ("mbedtls: update to 3.6.6") Signed-off-by: Magnus Kroken <mkroken@gmail.com> Link: https://github.com/openwrt/openwrt/pull/23066 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Felix Fietkau [Mon, 4 May 2026 12:02:41 +0000 (12:02 +0000)]
hostapd: clear start_disabled when adding a BSS to an enabled iface
In AP+STA mode, wifi-scripts emits start_disabled=1 in the per-BSS
section of the generated hostapd config so that hostapd defers
beaconing on every BSS until apsta_state up clears the flag for the
whole iface (uc_hostapd_iface_start clears start_disabled on every BSS
and calls ieee802_11_set_beacon).
When a new BSS is added later via iface.add_bss while the iface is
already in HAPD_IFACE_ENABLED state, the freshly parsed config still
carries start_disabled=1 for that BSS. hostapd_setup_bss is invoked
with start_beacon=true, but hostapd_start_beacon then skips
ieee802_11_set_beacon because conf->start_disabled is set. The kernel
netdev is created without ever starting beacons, the carrier never
comes up, and probe-response transmission attempts fail with
"handle_probe_req: send failed".
Mirror what iface.start does: when the iface is already enabled, the
apsta channel selection has happened, so clear start_disabled for the
incoming BSS before starting it.
Felix Fietkau [Mon, 4 May 2026 07:58:40 +0000 (07:58 +0000)]
hostapd: emit ubus key-mismatch event for SAE confirm failures
Surface SAE confirm mismatches (wrong password) through the same
key-mismatch ubus notification that is already used for PSK failures, so
consumers can react uniformly regardless of the authentication method.
Felix Fietkau [Mon, 4 May 2026 07:49:37 +0000 (07:49 +0000)]
hostapd: avoid spurious interface reload on empty MLD config
mld_set_config() treated any call with empty prev_mld as a fresh
configuration and triggered a full Reload all interfaces, even when the
new config was also empty (the typical path on non-MLD devices).
Reloading every BSS on each netifd reconf disrupted associated stations
including PMF-protected backhaul STAs, which would self-deauth after the
SA Query timeout.
Only treat the call as a new configuration when the new config is
actually non-empty.
Manuel Stocker [Wed, 29 Apr 2026 19:25:21 +0000 (21:25 +0200)]
realtek: support configurable LED interface mode on RTL930x
Add support for changing the LED mode via the device tree.
Currently it always defaults to SERIAL mode. With this change,
one can also use the SINGLE_COLOR_SCAN and BI_COLOR_SCAN modes.
Shiji Yang [Sat, 2 May 2026 06:36:05 +0000 (14:36 +0800)]
toolchain: gcc: drop 110-Fix-MIPS-PR-84790.patch
The issue reported on the patch has been fixed in GCC 13.4.0[1],
14.2.0[2] and 15.1.0[3]. And we have already removed the GCC 14
patch variant in commit a1b9c28edd72 ("toolchain: gcc: drop 110-Fix-MIPS-PR-84790.patch").
1. Boot WRC-X6000GSD in router mode normally
2. Access to the WebUI ("http://192.168.2.1/") on the device
-> その他設定 (Other settings)
-> フォームウェア更新 (Update firmware)
-> ローカルファイル指定 (Specify local file)
3. Select the OpenWrt factory.bin image and click apply ("適用") button
4. Wait ~120 seconds to complete flashing
Switching to the stock firmware:
1. Load the elecom.sh script
. /lib/upgrade/elecom.sh
2. Check the current index of firmware partition
mstc_rw_bootnum
3. Set the bootnum to opposite value between 1 and 2
mstc_rw_bootnum value
example:
- step2 returned "1": mstc_rw_bootnum 2
- step2 returned "2": mstc_rw_bootnum 1
4. Reboot, to stock FW
5. Flash the stock FW to fuly revert back to original.
Notes:
- With the stock firmware, it will flash to another partition and
toggle boot to that partition when any firmware is flashed.
For example when booting on ubi, the new firmware will be flashed
to ubi_2 and the router will boot from ubi_2 afterwards.
The 5th byte of the Persist partition is the boot value (0x01 or 0x02).
- bootmenu_delay=0 is set from factory so uboot menu is hidden by
default.
- The hardware of WRC-X6000GSD is almost identical to WRC-X6000QS, but
WAN (labeled as "INTERNET") port is limited to 1000 Mbps on stock FW.
On OpenWrt FW, 2500 Mbps connection is available on that port.
MAC Addresses:
LAN : 38:97:A4:xx:xx:58 (Factory, 0x2A(hex)/Ubootenv, "ethaddr"(text))
WAN : 38:97:A4:xx:xx:5B (Factory, 0x24(hex))
2.4GHz: 38:97:A4:xx:xx:59 (Factory, 0x4(hex))
5GHz : 38:97:A4:xx:xx:5A (Factory, 0xA(hex)
1. Boot WRC-X6000QS in router mode normally
2. Access to the WebUI ("http://192.168.2.1/") on the device
-> その他設定 (Other settings)
-> フォームウェア更新 (Update firmware)
-> ローカルファイル指定 (Specify local file)
3. Select the OpenWrt factory.bin image and click apply ("適用") button
4. Wait ~120 seconds to complete flashing
Switching to the stock firmware:
1. Load the elecom.sh script
. /lib/upgrade/elecom.sh
2. Check the current index of firmware partition
mstc_rw_bootnum
3. Set the bootnum to opposite value between 1 and 2
mstc_rw_bootnum value
example:
- step2 returned "1": mstc_rw_bootnum 2
- step2 returned "2": mstc_rw_bootnum 1
4. Reboot, to stock FW
5. Flash the stock FW to fuly revert back to original.
Note 1: With the stock firmware, it will flash to another partition and
toggle boot to that partition when any firmware is flashed.
For example when booting on ubi, the new firmware will be flashed
to ubi_2 and the router will boot from ubi_2 afterwards.
The 5th byte of the Persist partition is the boot value (0x01 or 0x02).
During my tests, it never switched to another boot partition if the
firmware failed boot. So if openwrt doesn't boot,
UART might be required to recover.
Note 2: bootmenu_delay=0 is set from factory so uboot menu is hidden.
iw: backport scan print of RSN Element Override IEs
Backport upstream iw commit d90618809e06 ("iw: scan: print RSN
Element Override IEs") as 001-*.patch so `iw scan` decodes the
RSNOE (vendor WFA type 41) and RSNO2E (type 42) elements that
hostapd emits for WPA3 Compatibility / RSN Overriding APs.
Also refresh the hunk offsets in 200-reduce_size.patch.
Two of the IW_FULL guards in 200-reduce_size.patch were inverted
or incomplete:
* the "unknown event" handler unconditionally replaced the
verbose print with the short form, so IW_FULL builds lost
the command name decoding;
* the early return before the vendor IE parser used
#ifdef IW_FULL, which suppressed parsing in the full build
instead of the size-reduced one.
Wrap both with the correct #ifndef IW_FULL / #else so the full
and reduced builds produce the intended output.
wifi-scripts: ucode: default sae_groups to NIST ECP 19/20/21
The WPA3 and Wi-Fi Enhanced Open Deployment Guide v1.1 (Table 4,
"SAE Groups") recommends that WPA3-Personal APs advertise support
for SAE groups 19, 20 and 21:
* group 19 - ECP 256-bit (NIST P-256)
* group 20 - ECP 384-bit (NIST P-384)
* group 21 - ECP 521-bit (NIST P-521)
hostapd's default is group 19 only, which leaves the two larger
ECP groups unavailable even though the peer may prefer them.
Set sae_groups = "19 20 21" as the default for any BSS whose
auth_type is sae or psk-sae (SAE, SAE Transition and SAE
Compatibility modes).
wifi-scripts: ucode: default BIP cipher from wpa_pairwise
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1 (Tables 4, 5, 6) requires the group-management cipher (BIP) to
match the mode and strength of the pairwise cipher: GCM-mode pairwise
ciphers pair with BIP-GMAC integrity, CCM-mode pairwise ciphers with
BIP-CMAC integrity. The ucode pipeline hard-coded group_mgmt_cipher
to AES-128-CMAC (BIP-CMAC-128) regardless of the pairwise cipher,
except for the eap192 special case that already forced BIP-GMAC-256.
An EHT WPA3-Personal BSS therefore emitted wpa_pairwise=GCMP-256
alongside group_mgmt_cipher=AES-128-CMAC -- the integrity cipher two
steps weaker than the data cipher and a spec violation on EHT.
hostapd has a single group_mgmt_cipher knob, so the selected BIP has
to be compatible with every pairwise cipher in wpa_pairwise. Picking
from the first token would mis-select on mixed lists -- e.g.
wpa_pairwise=\"GCMP-256 CCMP\" would yield BIP-GMAC-256, which a
CCMP-only STA cannot negotiate.
Walk the wpa_pairwise tokens and pick the BIP that matches the
weakest cipher present:
Token matching uses fnmatch wildcards against a copy of wpa_pairwise
that is padded with leading and trailing spaces, so each token is
space-bounded regardless of its position in the list.
The RSN override pairwise lists are not consulted: in the only
caller that sets them (WPA3-Personal Compatibility Mode), Tables 6
and 7 require BIP-CMAC-128 across RSNE/RSNOE/RSNO2E even when the
override lists advertise GCMP-256, so wpa_pairwise=CCMP already
yields the correct BIP.
An explicit ieee80211w_mgmt_cipher UCI value still wins over the
derived default.
wifi-scripts: ucode: advertise Transition Disable on WPA3-only BSSes
WPA3 Specification v3.5 §13 defines the Transition Disable element sent
inside message 3 of the 4-way handshake. An AP that is no longer
offering a transition mode for its SSID sets the matching bit so that
compliant STAs permanently stop falling back to WPA-PSK / WPA-EAP /
open for that SSID, hardening against downgrade attacks and against
operator mistakes where a transition-mode BSS is briefly brought up on
an SSID that previously ran WPA3-only.
Expose this as a UCI list 'transition_disable' with three classes of
entries:
* The existing OpenWrt encryption tokens 'sae' (bit 0x01), 'sae-pk'
(0x02), 'wpa3' (0x04) and 'owe' (0x08) OR into the bitmap. SAE-PK
itself is not yet wired through wifi-scripts; the token only lets
an operator who configured SAE-PK out of band also hand the
matching bit to hostapd.
* 'on' derives the bitmap from the AP's auth_type ('sae' -> 0x01,
'eap2'/'eap192' -> 0x04, pure 'owe' -> 0x08) and overrides any
other explicit tokens in the same list. Transition BSSes
(psk-sae, eap-eap2, owe with owe_transition set) produce no
bits even under 'on' because they are by definition still in
transition.
* 'off' unconditionally suppresses the element regardless of any
other entries. Operators who need to revert a WPA3-only SSID back
to a transition mode can set this proactively, giving compliant
STAs time to forget the permanent bit before the mode change.
Leave the list unset by default. Advertising Transition Disable is a
one-way door -- once a compliant STA has seen the permanent bit for an
SSID it will refuse to associate to a transition-mode BSS of the same
name ever again -- so it must be opted in to per SSID, never flipped
on by a firmware bump. This also matches the WPA3 and Wi-Fi Enhanced
Open Deployment and Implementation Guide v1.1 Table 4 requirement that
Transition Disable be MAND disabled by default on APs.
wifi-scripts: ucode: default sae_pwe to H2E-only on 6 GHz
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1 (Tables 7 and 8) mandates "H2E Only" for SAE on 6 GHz, in both
WPA3-Personal Only and WPA3-Personal Compatibility Mode: the 6 GHz
band disallows the legacy Hunting-and-Pecking password element, so
the AP must advertise BSS Membership Selector 123 to force STAs onto
H2E.
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1 §2.4 (Tables 6 and 7) defines WPA3-Personal Compatibility Mode:
the AP advertises a legacy-looking RSNE (WPA-PSK, CCMP-128, PMF
Disabled) while RSN Override Elements layered on top expose SAE and,
on EHT, SAE-EXT-KEY. WPA2-only STAs and STAs that ignore RSN
Overriding associate unchanged; modern STAs pick up the stronger WPA3
AKM via RSNOE or RSNO2E.
Only the pairwise cipher differs between elements: RSNE and RSNOE
advertise CCMP-128, RSNO2E advertises GCMP-256 (EHT only). Group
data (CCMP-128) and group management cipher (BIP-CMAC-128) are the
same in all three per Tables 6/7, so hostapd's BSS-wide group_cipher
and group_mgmt_cipher singletons produce the spec-correct values.
Unlike WPA3-Personal Transition Mode (sae-mixed), which puts PSK and
SAE together in the main RSNE with PMF Capable, Compatibility Mode
keeps the main RSNE strictly WPA2-shaped so clients that choke on a
mixed AKM list or PMF=Capable still see a pure WPA2 BSS. The trade-
off is that clients without RSN Overriding support never pick up SAE.
wifi-scripts: ucode: enable Beacon Protection by default with PMF
The WPA3 and Wi-Fi Enhanced Open Deployment and Implementation Guide
v1.1, Table 4 (Common security configuration) marks Beacon Protection
as MAND for EHT-enabled APs and RECOM otherwise for all WPA3 and
Wi-Fi Enhanced Open modes.
The ucode path blindly passed beacon_prot through from UCI in iface
setup, which ran before encryption and MFP had been configured, and
left hostapd at its insecure default of 0 when the user did not
explicitly opt in.
Default beacon_prot to 1 in iface_mfp after MFP has been confirmed to
be enabled, and emit it there instead of in iface_setup so the option
is only written when PMF support is actually negotiated. Users can
still disable it explicitly via UCI.
WPA3 Specification v3.5 §2.5.4 mandates that an AP's BSS Configuration
enables AKM suite selector 00-0F-AC:24 (SAE-EXT-KEY, SAE with a
group-dependent hash) whenever EHT or MLO is enabled. The WPA3 and
Wi-Fi Enhanced Open Deployment Guide v1.1 also recommends it on
non-EHT APs (Tables 3, 5, 6, 8).
Add a new sae_ext_key UCI option (enabled by default) that advertises
SAE-EXT-KEY, and FT-SAE-EXT-KEY when 802.11r is enabled, alongside
plain SAE/FT-SAE for the sae and psk-sae encryption modes.
projects / thirdparty / openwrt.git / log
