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.
Link: https://github.com/openwrt/openwrt/pull/23009
(cherry picked from commit 164428d2d6)
Link: https://github.com/openwrt/openwrt/pull/23011
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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.
Link: https://github.com/openwrt/openwrt/pull/23009
(cherry picked from commit 957b921721)
Link: https://github.com/openwrt/openwrt/pull/23011
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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
(cherry picked from commit 0ca11b32eb)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit 68165c85c8)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit 2db148c062)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit 3b22050040)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit 86b9eec8f0)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit ef393caee2)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit a12cec9ea3)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit 1f86f4e471)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit 588330e92b)
Link: https://github.com/openwrt/openwrt/pull/23011
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
(cherry picked from commit 9aeea77b8d)
Link: https://github.com/openwrt/openwrt/pull/23011
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Hardware:
- SoC: MediaTek MT7628AN
- Flash: 16 MiB SPI NOR
- RAM: 128 MiB DDR2
- WLAN: 2.4 GHz (MT7628AN, 11n), 5 GHz (MediaTek MT7615E, 11ac)
- Ethernet: 1x10/100 Mbps LAN
- Buttons: 1 Reset button
- LEDs: 8x Green
- LTE: internal USB-connected modem Quectel EC200A
- Serial Console: unpopulated header 115200 8n1
MAC addresses:
+---------+-------------------+-----------+
| | MAC | Algorithm |
+---------+-------------------+-----------+
| LAN | 80:af:ca:xx:xx:x0 | label |
| WLAN 2g | 80:af:ca:xx:xx:x0 | label |
| WLAN 5g | 80:af:ca:xx:xx:x2 | +2 |
+---------+-------------------+-----------+
Migration to OpenWrt:
- Download the RSA signed intermediate firmware:
`openwrt-ramips-mt76x8-cudy_lt500-outdoor-v1-squashfs-flash.bin`
- Connect computer to LAN and flash the intermediate firmware via OEM web interface
- OpenWrt is now accessible via 192.168.1.1
Revert back to OEM firmware:
- Press the reset button while powering on the device
- Connect the LAN port to the PC
- Open 192.168.1.1 in a browser and use the wizard to upload and flash OEM firmware image
- When recovery process is done, OEM firmware is accessible via 192.168.10.1 again
Signed-off-by: rodriguezst <git@rodriguezst.es>
Link: https://github.com/openwrt/openwrt/pull/23752
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit b5ea3abd60)
Link: https://github.com/openwrt/openwrt/pull/24213
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
For LEDs that have no network trigger configuration in Device Tree
(no mode or family properties), net_activate() infers the family
from the LED name or function string. If that inference fails,
the trigger previously returned -EINVAL and refused to activate.
This is too strict for manual activation via sysfs (e.g.
echo "network" > /sys/class/leds/<led>/trigger) on LEDs that
were not declared for the network trigger in DT. In that case
the user expects the trigger to load with sensible defaults.
Change the non-DT activation path to fall back to NET_TRIG_WLAN
instead of failing, while keeping the condition visible via pr_warn().
Device Tree paths with dt_mode or dt_family are left unchanged
and continue to fail on invalid parameters
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24235
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
(cherry-picked from f31b65a870)
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This commit migrates the repository validation to a webhook-based bot instead of the GitHub Actions workflow (.github/workflows/formal.yml).
Since the bot handles stable branch labeling automatically (via the "branch_labeling: true" configuration option), the redundant branch check and labeling steps are removed from .github/workflows/labeler.yml.
The following configuration choices are applied in formalities.json:
- check_space_after_assignment: false (Disabled temporarily to catch any issues since it is a newly implemented check)
- check_makefile_indentation: false (Disabled temporarily to catch any issues since it is a new feature)
- check_patch_headers: 'warning' (Changed to warning instead of hard error since many legacy patches lack headers)
- enable_stale_bot: false (Disabled for now)
Other configurations can be adjusted in formalities.json based on the openwrt-bot-worker repository [1].
[1] https://github.com/openwrt/openwrt-bot-worker
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24256
(cherry picked from commit 9146f931b6)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Drop the pull_request_target trigger so the LLM review no longer runs
on opened/reopened PRs. We are limited to 15 Claude routine runs per
day, and the automatic per-PR trigger exhausted that budget on
several days, starving the nightly digest.
The nightly schedule and manual workflow_dispatch triggers remain.
Link: https://github.com/openwrt/openwrt/pull/23474
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 4871040d5d)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Manual workflow_dispatch and push share the same ref on main, so
they previously landed in the same concurrency group
'Build Kernel-refs/heads/main' (and the equivalent for the packages
workflow). With cancel-in-progress: false for non-PR events, only
one run can be pending per group: a newer queued run cancels the
older pending one.
That made the manual trigger unreliable in both directions. A push
landing while a dispatch was queued displaced the dispatch (so the
ccache reseed never ran), and dispatching while a push was queued
displaced the push (so the legitimate per-commit build was lost).
Adding github.event_name to the concurrency group puts pushes,
dispatches, and pull_requests in separate buckets on the same ref,
so they no longer compete with each other.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Link: https://github.com/openwrt/openwrt/pull/23283
(cherry picked from commit 3c7a1418c1)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Allow the Build Kernel and Build all core packages workflows to be
launched manually from the Actions tab. The shared workflow side
detects workflow_dispatch and, for Build Kernel, rebuilds the full
target/subtarget matrix including testing kernel versions, so a
manual run can re-seed the s3 ccache when a queued push run got
displaced from the concurrency queue by the next commit on main.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Link: https://github.com/openwrt/openwrt/pull/23283
(cherry picked from commit d9e6f9dce8)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tightened from real bot reviews:
- Patch regeneration: spell out which make ... refresh command
to recommend for each patch directory class, so the bot stops
suggesting git format-patch for quilt-managed patches.
- Backports / cherry-picks: a backport's diff should match the
upstream commit on main verbatim; flag only deviations and
the missing (cherry picked from commit <sha>) trailer, not
pre-existing style issues.
- New device support: require Hardware specification, Flash
instructions, and MAC address layout sections in the commit
message that introduces a new device. Two reference commits
(986ca4c887, a2dcbd79a4) named so the bot can sample the
expected shape.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23184
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 0bef741188)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Drop-in wrapper that calls the reusable LLM review workflows in
openwrt/actions-shared-workflows. Triggers on pull_request_target
(incl. PRs from forks), a nightly cron (03:00 UTC), and manual
workflow_dispatch with a max_prs input override.
A detect-kernels pre-step builds the extra_repos list at workflow
runtime: it reads target/linux/generic/kernel-* in the base branch
to derive gregkh/linux:v<X.Y.Z> tags for each currently-targeted
kernel, then appends u-boot/u-boot:master. The list updates
automatically when kernel versions are bumped; the routine clones
only the entries actually needed for a given diff.
The bundled .github/llm-review-rules.md teaches the bot two
project-specific deprecations to flag even when other in-tree files
still use the legacy form:
- LED label syntax `label = "<color>:<function>";` -->
`color = <LED_COLOR_ID_*>;` + `function = "<func>";`
- `mediatek,mtd-eeprom` for MAC sourcing -->
`nvmem-cells` + `nvmem-cell-names = "mac-address";`
Repository settings need LLM_ROUTINE_ID_PR / LLM_ROUTINE_TOKEN_PR
and the *_NIGHTLY counterparts populated before the workflow can
fire. See openwrt/actions-shared-workflows/docs/llm-review-setup.md
for the full setup procedure.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/23105
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit af3cbd4013)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Without a prompt the action auto-detected mode: tag instead of agent
when triggered via issue_comment, resulting in no review being posted.
Remove the prompt so the action can correctly use its built-in agent
mode with full PR context.
Fixes: c0e75c9de6 ("github: add Claude code review workflow triggered by /claude comment")
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 62ca0a987f)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The claude-code-action uses mcp__github_ci__get_ci_status and related
tools to check workflow run status as part of the review. Without
actions: read the GitHub API calls for CI status are rejected.
Fixes: c0e75c9de6 ("github: add Claude code review workflow triggered by /claude comment")
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 122b2f2ef5)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
The whitelist was too restrictive, causing permission denials when
Claude tried to use basic tools like Read or Grep to analyse the diff.
Remove it and let the action use its default toolset.
Fixes: c0e75c9de6 ("github: add Claude code review workflow triggered by /claude comment")
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 29e1c7b85a)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Add claude-code-review.yml using anthropics/claude-code-action@v1.
The review runs when a PR comment containing "/claude" is posted,
avoiding unnecessary API usage on every push.
Uses issue_comment trigger restricted to PR comments only. Only
triggers for users with write access (OWNER, MEMBER, COLLABORATOR)
and when the comment body contains "/claude", preventing any runner
from being allocated for unrelated comments. A short domain hint
steers the review toward OpenWrt embedded Linux conventions.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Link: https://github.com/openwrt/openwrt/pull/22556
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit c0e75c9de6)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Run this only when a PR is created, so either author or anyone who can
edit the PR message (all maintainers) can trigger such build.
Instead of maintaining it in the main repository, move it to the
external repository to bloat this repository less with further CI
commits.
Signed-off-by: Paul Spooren <mail@aparcar.org>
(cherry picked from commit 8cff0d8ca0)
Link: https://github.com/openwrt/openwrt/pull/24318
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Hardware specification:
SoC: MediaTek MT7987A
Flash: 8GB eMMC
RAM: 1GB DDR4
Ethernet: 2x 2.5GbE (RTL8221B PHY + Internal PHY)
WiFi: MediaTek MT7992 / 2+3 antenna variant
Interface: M.2 USB for 5G module
LED: Power (hw-controlled), 2.5G WAN (user-definable),
5G Module (hw-controlled), LED-3 (user-definable),
LED-4 (user-definable)
Button: Reset, WPS
Power: USB Type-C PD
Other: PWM Fan control
MAC address assignment is unconventional: the board has no Factory
partition with pre-programmed MACs. Instead, all addresses are
derived from the eMMC CID at runtime:
LAN : macaddr_generate_from_mmc_cid mmcblk0
WAN : LAN + 1 (label_mac)
phy0: LAN + 2
phy1: LAN + 3
This matches the vendor firmware behaviour and ensures stable,
unique addresses across reboots without a dedicated EEPROM region
for MACs.
Flash instructions:
Factory `mmcblk0p2` partition is empty,
stock ImmortalWrt-798x-mt799x-6.6-mtwifi from PadavanOnly firmware
uses `MT7991_MT7976_EEPROM_BE5040_iPAiLNA.bin`.
Flashing this eeprom before flashing OpenWrt will make OpenWrt read eeprom:
```
dd if=/lib/firmware/MT7991_MT7976_EEPROM_BE5040_iPAiLNA.bin of=/dev/mmcblk0p2 bs=1 count=7680
sync
```
But it will have wifi issues for now. It's better to use OpenWrt fallback eeprom for now.
Power off the device.
Press and hold the Reset button.
Power on the device while keeping the Reset button pressed.
Wait for the device to enter U-Boot recovery mode.
Connect to the device via Ethernet (default IP: 192.168.1.1).
Set your PC's IP to 192.168.1.x (e.g., 192.168.1.100).
Open a web browser and navigate to http://192.168.1.1
Upload and flash the OpenWrt firmware
Wait for the flashing process to complete and the device to reboot.
Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21398
(cherry picked from commit 6487cc9a1f)
Link: https://github.com/openwrt/openwrt/pull/24156
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Delete the KERNEL_LOADADDR assignment from the airoha_an7583-evb device definition.
The kernel load address is now centrally managed in image Makefile with, just using default load address:
loadaddr-$(CONFIG_TARGET_airoha_an7583) := 0x80200000
This ensures the load address configuration is maintained in a single location.
Removing the duplicate assignment prevents confusion and potential misconfiguration.
Signed-off-by: YaleiZang <yalei.zang@airoha.com>
Link: https://github.com/openwrt/openwrt/pull/24000
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 10631d244c)
Link: https://github.com/openwrt/openwrt/pull/24153
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Cherry pick the patches recommended in the hostapd security advisory
2026-1:
https://w1.fi/security/2026-1/missing-ml-parsing-validation.txt
Vulnerability
Vulnerabilities in parsing and use of received multi-link (MLO/EHT/IEEE
802.11be/Wi-Fi 7) information has been identified in hostapd and
wpa_supplicant. These issues show up in various cases where frames
including information on affiliated links are parsed and processed in
both AP and STA modes. The issues can result in process termination due
to buffer read overflow checks and memory corruption.
The issues for AP mode (hostapd or wpa_supplicant) can result in
denial-of-service attacks due to process termination and small memory
corruption that could theoretically cause other issues, but it does not
seem likely that those could be exploiting in practice. Affected areas
can be reached by sending invalid Management frames without needing
authentication or user action on the target device.
Link: https://github.com/openwrt/openwrt/pull/24043
(cherry picked from commit 8614a2ba68)
[Removed 004 and 008 which do not apply and fix some others]
Link: https://github.com/openwrt/openwrt/pull/24044
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
RAM: ESMT M15T2G16128A-DEB DDR3 1866 MT/s
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdinfo" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_m3000-v2-yt8821-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_m3000-v2-yt8821-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_m3000-v2-yt8821-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Signed-off-by: Dmitry Mostovoy <stavultras@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23274
(cherry picked from commit 395252be08)
Link: https://github.com/openwrt/openwrt/pull/24018
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
RAM: ESMT M15T2G16128A-DEB DDR3 1866 MT/s
This allows us to use the full size of nand,
which extends ubi size from 64Mb to 122.25Mb.
1. Log in to the device and backup all the partitions,
especially unique "Factory" and "bdinfo" partitions
from System -> Backup / Flash Firmware -> Save mtdblock contents.
2. Install kmod-mtd-rw to unlock mtd partitions for writing
apk update && apk add kmod-mtd-rw && insmod mtd-rw i_want_a_brick=1
3. Write new OpenWrt (U-Boot Layout) "BL2" and "FIP":
mtd -e BL2 write openwrt-mediatek-filogic-cudy_m3000-v1-ubootmod-preloader.bin BL2
mtd -e FIP write openwrt-mediatek-filogic-cudy_m3000-v1-ubootmod-bl31-uboot.fip FIP
4. Set static IP on your PC: "192.168.1.254", gateway "192.168.1.1"
5. Serve openwrt-mediatek-filogic-cudy_m3000-v1-ubootmod-initramfs-recovery.itb
using TFTP server.
6. Connect Router LAN with PC LAN.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt initramfs recovery has booted,
clean "/dev/mtd5" ubi partition to utilize maximum of free space:
ubidetach -p /dev/mtd5; ubiformat /dev/mtd5 -y; ubiattach -p /dev/mtd5
ubimkvol /dev/ubi0 -n 0 -N ubootenv -s 128KiB
ubimkvol /dev/ubi0 -n 1 -N ubootenv2 -s 128KiB
9. Perform sysupgrade.
Signed-off-by: Dmitry Mostovoy <stavultras@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23274
(cherry picked from commit 6a08c65949)
Link: https://github.com/openwrt/openwrt/pull/24018
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Hauke Mehrtens
rodriguezst
Mieczyslaw Nalewaj
Josef Schlehofer
Paul Spooren
Fil Dunsky
YaleiZang
Rosen Penev
Dmitry Mostovoy
Pavlo Samko