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).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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:
CCMP / TKIP -> AES-128-CMAC (BIP-CMAC-128)
CCMP-256 -> BIP-CMAC-256
GCMP -> BIP-GMAC-128
GCMP-256 -> BIP-GMAC-256
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.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
parse_encryption() stashed a preliminary wpa_pairwise value in a
local wpa3_pairwise variable, cleared it per auth_type, then let a
switch default either copy it back or special-case wpa3-192. The
result was three separate places where wpa_pairwise was clobbered
and behavior that was awkward to trace when the explicit cipher
suffix (encryption[1]) and the auth_type disagreed.
Replace the scaffolding with a single block at the end of
parse_encryption() that only assigns wpa_pairwise via ??= when no
earlier branch (explicit cipher suffix, wpa3-192, or sae-compat)
has already set one:
no WPA -> null
60 GHz (hw_mode=ad) -> GCMP
HE or EHT htmode -> GCMP-256 CCMP
everything else -> CCMP
wpa3-192 now sets wpa_pairwise='GCMP-256' directly in its switch
case, so the final default block can stay short. No functional
change for existing encryption values.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The rsn_override UCI number was scaffolding that let a Transition
Mode BSS (sae-mixed, wpa3-mixed) automatically overlay a WPA3
Compatibility-Mode-like layout: WPA3 AKMs were moved from the main
RSNE into RSNOE/RSNO2E, and with rsn_override=2 the main RSNE even
dropped SAE entirely to placate clients that refuse to associate to
a mixed AKM list.
This layout does not match any mode defined in the WPA3 and Wi-Fi
Enhanced Open Deployment and Implementation Guide v1.1: Transition
Mode (Table 5) advertises the full AKM list in a single RSNE, and
Compatibility Mode (§2.4, Tables 6 and 7) requires a specific
combination of RSNE, RSNOE and RSNO2E contents that the knob cannot
express. In practice it also triggers interop failures: Pixel 10
phones refuse to associate to a Transition-Mode BSS whose SAE-EXT-KEY
AKM has been shoved into RSNO2E by this scaffolding, even though the
same BSS works fine when the full AKM list stays in the main RSNE.
Keep the generated configuration honest by removing the knob; the RSN
override plumbing stays in place for a future caller that sets the
override fields explicitly. SAE-EXT-KEY advertisement will be added
back in a later commit via a dedicated sae_ext_key path that places
the AKM where the Deployment Guide actually requires it.
Drop the rsn_override schema entry and every wifi-scripts path that
read it:
* parse_encryption no longer diverts the WPA3 pairwise cipher
into rsn_override_pairwise.
* wpa_key_mgmt no longer mirrors WPA-EAP into
rsn_override_key_mgmt, moves SAE/SAE-EXT-KEY into the override
for psk-sae, or drops the main RSNE AKM list when
rsn_override > 1.
* generate() no longer back-fills missing rsn_override_* fields
from the main RSNE or duplicates the override element into an
MLO-gated RSNO2E.
The RSN override elements are now emitted only when each of
(rsn_override_key_mgmt, rsn_override_pairwise, rsn_override_mfp) --
and their _2 counterparts -- has been populated explicitly, which
keeps the machinery from firing on transition modes where it was
never spec-compliant.
Fixes: https://github.com/openwrt/openwrt/issues/21486
Fixes: https://github.com/openwrt/openwrt/issues/22200
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
sae_require_mfp and sae_pwe are SAE-specific knobs but iface_auth_type()
set them on every auth type that requires PMF (sae, owe, eap2, eap192,
dpp) and on both PMF-optional transition modes (psk-sae, eap-eap2).
hostapd silently ignores the stray settings on non-SAE BSSes, but they
clutter the generated configuration and make it harder to tell at a
glance which knobs actually apply.
Split the grouping: keep ieee80211w (and rsn_override_mfp for transition
modes) where it was, and move sae_require_mfp / sae_pwe into a separate
check that only fires for the two auth types that actually run SAE (sae
and psk-sae).
No functional change on the air.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23009
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Without this, max_oper_chwidth is set incorrectly,
thus ibss_mesh_select_80_160mhz fails to set the correct channel width
Signed-off-by: Richard Huynh <voxlympha@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22644
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The ucode path generates different erp_domain and fils_cache_id
values than the legacy shell path due to three mismatches:
1. erp_domain md5 input missing trailing newline (echo adds \n)
2. erp_domain output truncated to 4 chars instead of 8 (shell
uses head -c 8)
3. fils_cache_id md5 input missing trailing newline
4. erp_domain missing fallback to mobility_domain
Same bug pattern as mobility_domain fixed in commit b1dc2736db.
Fixes: #21768
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Joshua Klinesmith <joshuaklinesmith@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22677
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Doesn't make sense to have he_twt_required enabled without
he_twt_respodner.
Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22577
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
In hostapd conf this option is set to 1 by default.
Then it's set to 0 if the HE MAC capability bit is not present.
Add an option in wifi-scripts to manually control it.
Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/22577
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The hostapd configuration for SU-BEAMFORMEE was incorrectly using the
beamformer antenna count instead of the beamformee antenna count for the
[BF-ANTENNA-N] capability string.
Fix this by using config.beamformee_antennas instead.
Signed-off-by: Andrew Sim <andrewsimz@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22511
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
After 02e2065203c5e6c95f88e3501644d3e6ad740f89, it can happen that both,
[VHT160-80PLUS80] and [VHT160] are added to the vht_capab option in
an AP's hostapd.conf, which would cause a failure to start the AP.
Fix the logic in order to prevent such misconfiguration.
Fixes: #22481
Signed-off-by: Shine <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/22482
Signed-off-by: Robert Marko <robimarko@gmail.com>
The key variable is not defined in the scope when setting wpa_psk. Use
config.key instead.
This fixes configuration the 64 characters wpa_psk directly.
Reported-by: donjoe in OpenWrt Forum
Link: https://github.com/openwrt/openwrt/pull/22182
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add optional chaining when accessing device config in the wifi-iface
loop to handle cases where a referenced device doesn't exist.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit ebd2fefea5152d032cded1ccc7cf6e731b5bbcc2)
This should not be defaulted to anything in the schema.
What seemed like a minor cleanup actually broke this
as the schema defines a default value already. I did
not notice as I had this explictly set in my config.
Fixes: 70ba7512 ("wifi-scripts: ucode: allow sae_pwe to be modified for AP mode")
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/22043
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Some Android devices have issues with H2E causing downgrades to PSK
when using WPA2/3. With WPA3 it doesn't work reliably whatsoever.
My Samsung A55/6 for example has the following behavior:
daemon.info hostapd: lan5g: STA <redacted> IEEE 802.11: authenticated
daemon.notice hostapd: SAE: <redacted> indicates support for SAE H2E, but did not use it
daemon.info hostapd: lan2g: STA <redacted> IEEE 802.11: authenticated
daemon.info hostapd: lan2g: STA <redacted> IEEE 802.11: associated (aid 1)
daemon.notice hostapd: lan5g: Prune association for <redacted>
daemon.notice hostapd: lan2g: AP-STA-CONNECTED <redacted> auth_alg=open
daemon.info hostapd: lan2g: STA <redacted> RADIUS: starting accounting session 8234C696AAC1AE7D
daemon.info hostapd: lan2g: STA <redacted> WPA: pairwise key handshake completed (RSN)
daemon.notice hostapd: lan2g: EAPOL-4WAY-HS-COMPLETED <redacted>
This is also brought up in the issue: https://github.com/openwrt/openwrt/issues/9963
Ultimately this allows users to have the option to at the very least
disable H2E.
Unrelated: a minor cleanup was done so that ieee80211w uses set_default instead.
There is no functional change on that front.
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/22021
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When config_change is set during an active setup (e.g. by a concurrent
reconf call), wdev_mark_up() attempted to call setup() while still in
"setup" state. Since setup() requires state "up" or "down", it silently
returned, leaving the state as "setup". The subsequent wdev_setup_cb()
then treated this as a setup failure, triggering an unnecessary
teardown+restart cycle.
Fix this by removing the config_change handling from wdev_mark_up() and
moving it to wdev_setup_cb() instead. wdev_mark_up() now always
transitions to "up" state. When wdev_setup_cb() runs afterwards and
finds the device already "up" with config_change set, it initiates a
clean re-setup from the "up" state where setup() can run.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Commit 01a87f4bd0cdbfc84bbc172920e865c1600f7a45 changed the encryption
setting of the default SSID "OpenWrt" from "none" to "open". The correct
setting as per the documentation [1] is "none", though.
While this invalid setting won't cause a wrong hostapd setup, it will
at least cause malfunction in LuCI.
Change the default encryption setting back to "none".
[1] https://openwrt.org/docs/guide-user/network/wifi/basic#encryption_modes
Fixes: 01a87f4bd0cdbfc84bbc172920e865c1600f7a45
Signed-off-by: Shine <4c.fce2@proton.me>
Link: https://github.com/openwrt/openwrt/pull/21925
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When storing device-level data, wdev_set_data() spread the entire wdev
object into handler_data. Since handler_config.data is set from the
previous handler_data[wdev.name] before each setup, this created
exponentially growing nesting with each reload, eventually causing
"nesting too deep" JSON parse errors.
Fix by initializing cur to a simple object containing only the device
name instead of the entire wdev object.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Add support for DPP (Device Provisioning Protocol) as both a primary
encryption type and as an optional addition to existing authentication.
Primary DPP mode (encryption=dpp):
- Sets WPA2 with key_mgmt=DPP
- Requires Management Frame Protection (ieee80211w=2)
- Supports dpp_connector, dpp_csign, dpp_netaccesskey options
Optional DPP mode (dpp=1 boolean on AP):
- Adds DPP to existing key management methods
- Allows AP to accept both DPP and other auth types
- Supports the same connector options
Both ucode and legacy shell implementations are updated for AP and STA
modes.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The ucode wifi-scripts unconditionally set ieee80211w=1 for psk-sae
and eap-eap2 auth types, ignoring any user-configured value. This
caused ieee80211w=2 (MFP required) to be silently downgraded to 1
(MFP optional) when using sae-mixed encryption.
Change the logic to only set the default of 1 when ieee80211w is not
already configured by the user.
Fixes: https://github.com/openwrt/openwrt/issues/21751
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The mobility_domain value generated by ucode differed from the previous
shell script implementation. The legacy shell script used `echo` on the
SSID, which appended a trailing newline.
To maintain roaming compatibility with pre-25.12 releases and OpenWrt
forks in default configuration, update the ucode logic to include this
newline character when generating the default value.
Fixes: #21731
Signed-off-by: Youfu Zhang <zhangyoufu@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21732
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Extract survey fetching into get_survey() and store results in iface.survey,
allowing access to full survey info (not just noise) for later use.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Moved interface discovery and data population into an exported update()
function that can be called on-demand to refresh wireless interface
information. This allows using iwinfo.uc as a library inside daemons.
Signed-off-by: John Crispin <john@phrozen.org>
WiFi 6E (802.11ax) clients cannot discover 6GHz APs operating at
320MHz because the HE Operation element contains uninitialized
center frequency values.
For EHT320 mode, the code sets eht_oper_centr_freq_seg0_idx but not
the corresponding HE values. Later, the HE values are copied from
VHT values, but VHT is not used on 6GHz, leaving he_oper_chwidth
and he_oper_centr_freq_seg0_idx at 0. This causes WiFi 6E clients
to see incorrect channel width information, making the AP invisible
to them during scanning.
Fix this by:
1. Setting he_oper_chwidth to 3 (160MHz) for EHT320 mode
2. Computing he_oper_centr_freq_seg0_idx based on the 160MHz segment
that contains the primary channel
3. Preserving these pre-set values instead of overwriting them with
uninitialized VHT values
WiFi 7 clients continue to see 320MHz operation via the EHT Operation
element, while WiFi 6E clients can now discover and connect at 160MHz.
Signed-off-by: Ryan Chen <rchen14b@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21588
Signed-off-by: Robert Marko <robimarko@gmail.com>
The code to be replaced is a glorious no-op. A default value for
config.radius_das_client does not need to be assigned. This parameter
already has non-empty value: see the enclosing 'if' block.
As a result, the value of config.radius_das_client never gets modified
to contain both dae_client and dae_secret. This breaks hostapd.add_iface()
that expects config.radius_das_client to contain both dae_client and
dae_secret separated by a whitespace.
Fixes: #21519
Signed-off-by: Val Kulkov <val.kulkov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21522
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
It is a BSS-level option and not radio-level. As such,
move it to wifi-iface and ap.uc.
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/21412
Signed-off-by: Robert Marko <robimarko@gmail.com>
They are being default enabled unconditionally when they should
depend on 802.11k. 802.11k should not be enabled by default
either as it can cause issues with certain older drivers and
is useless without a userspace program like usteer or DAWN.
If users want to enable 802.11k they will enable it when they
set such programs up.
Another inconsistency with rnr was dealt with so that it is not
default enabled. This is also not done with old wifi-scripts
and is generally unexpected and surprising behavior.
Moreoever, this introduces an inconsistency between old shell
wifi-scripts and ucode version. Old wifi-scripts does not do this.
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/21425
Signed-off-by: Robert Marko <robimarko@gmail.com>
This helps for setups where the wifi interfaces are added dynamically
via procd data by avoiding automatically bringing up interfaces with
the default config. Internally, they are treated pretty much the same
by netifd.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Mesh mode interface creation fails when the freq parameter is empty or
undefined. Unlike adhoc mode which checks if freq exists before using it,
mesh mode blindly constructs the iw command with freq parameter, resulting
in invalid syntax like:
iw dev mesh0 mesh join ssid freq NOHT
This causes the mesh interface to be created without joining the mesh
network, leaving it in a DOWN state with no channel assigned.
Fix by adding freq validation check similar to adhoc mode.
Tested on two routers in parallel as mesh peers:
- Xiaomi AX3000T (MediaTek MT7981)
- OpenWrt One (MediaTek MT7981)
- OpenWrt 6.6.119, 802.11s mesh on 5GHz (Channel 36, HE80)
Signed-off-by: Valent Turkovic <valent@meshpointone.com>
Link: https://github.com/openwrt/openwrt/pull/21373
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Wifi on the 6GHz band does not support open networks, configure owe by
default. 6GHz wifi also needs a country code, configure a broken country
code '00' by default to hint the user to change it.
Link: https://github.com/openwrt/openwrt/pull/21313
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Without this patch, the
if (!config.wpa)
config.wpa_pairwise = null;
is overwritten immediately.
Signed-off-by: Leon M. Busch-George <leon@georgemail.eu>
Link: https://github.com/openwrt/openwrt/pull/21215
Signed-off-by: Robert Marko <robimarko@gmail.com>
When wdev interfaces and hostapd interfaces are mixed, race conditions
can occur. Sometimes all interfaces are started correctly, sometimes only
the wdev interface and some of the hostapd interfaces, and sometimes only
the wdev interface.
Fix this by creating the wdev interfaces first, before processing
wpa_supplicant or hostapd interfaces.
Link: https://github.com/openwrt/openwrt/pull/21303
Signed-off-by: Nick Hainke <vincent@systemli.org>
The multicast rate (mcast_rate) is defined as a single numeric value,
not an array. The ucode scripts already expect a single number, and
the OpenWrt documentation specifies this option as an integer [0].
Adjust the wireless schema accordingly. This also fixes the wdev.uc
call path for the iw fallback mesh setup.
[0] - https://openwrt.org/docs/guide-user/network/wifi/basic
Link: https://github.com/openwrt/openwrt/pull/21291
Signed-off-by: Nick Hainke <vincent@systemli.org>
The previous wdev.uc invocation failed for mesh interfaces.
Rewrite it as a loop so the mesh interface is created correctly
when no wpa_supplicant mesh support is installed.
Link: https://github.com/openwrt/openwrt/pull/21291
Signed-off-by: Nick Hainke <vincent@systemli.org>
Mesh interfaces may not define an encryption setting. This results in
a ucode runtime error when parse_encryption() is called:
Reference error: left-hand side expression is null
In parse_encryption(), file /usr/share/ucode/wifi/iface.uc, line 20, byte 32:
called from function setup_sta (/usr/share/ucode/wifi/supplicant.uc:59:31)
called from function generate (/usr/share/ucode/wifi/supplicant.uc:243:41)
called from function setup (./mac80211.sh:254:61)
called from anonymous function (./mac80211.sh:342:14)
` config.auth_type = encryption[0] ?? 'none';`
Near here ------------------------^
Link: https://github.com/openwrt/openwrt/pull/21293
Signed-off-by: Nick Hainke <vincent@systemli.org>
Add EHT* check so that the hwmode will display 802.11be capability correctly.
Signed-off-by: Elwin Huang <s09289728096@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21267
Signed-off-by: Nick Hainke <vincent@systemli.org>
This fixes a simple logic error in the macaddr existence check in mac80211.uc.
Signed-off-by: Harin Lee <me@harin.net>
Link: https://github.com/openwrt/openwrt/pull/21277
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes a failed bring up of the radio on bootup
if the model defines a rename of phy in its /etc/board.json.
This specifically impacts Redmi AX6S and any router that does so
in its /etc/board.json. The fix fortunately is simple, just update
phy name in phys after rename.
The entry that specifically causes this issue is the following:
{
<omitted>
"wlan": {
"wl0": {
"path": "platform/18000000.wmac",
"info": {
"antenna_rx": 15,
"antenna_tx": 15,
"bands": {
"2G": {
"ht": true,
"max_width": 40,
"modes": [
"NOHT",
"HT20",
"HT40"
],
"default_channel": 1
}
},
"radios": [
]
}
},
...
}
The issue is that after rename, referenced phy in config is going to be
wl0 but in phys array it is still phy0; and so it fails to find phy
and does not bring up radio.
Fixes: https://github.com/openwrt/openwrt/issues/20250
Fixes: https://github.com/openwrt/openwrt/issues/20339
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/21175
Signed-off-by: Robert Marko <robimarko@gmail.com>
