Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

wifi: 40 MHz HE/VHT htmodes unusable — validator only accepts HE40±/VHT40±, which OpenWrt 24.10 ignores (silent 20 MHz)

Open Beginner friendly
  • Is something wrong?
#344 0 comments 0 reactions 1 assignee View on GitHub

@rslater-cs is already working on this.

Since Oct 21, 2026.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
lua, shell
Domain
networking, testing

Research direction

Start by reading the htmode allow-lists in src/services/hal/types/capability_args.lua and src/services/hal/drivers/radio.lua, then compare them with the mac80211.sh matching behavior described in the issue. Locate the existing validator tests and add coverage for HE40 and VHT40, plus the chosen handling of signed 40 MHz variants. The change is done when validation accepts OpenWrt-compatible values, handles or clearly rejects HE40±/VHT40±, and the relevant tests pass.

Written by the indexing model from the issue text.

Description

bug

Summary

The radio htmode allow-list accepts HE40+, HE40-, VHT40+, VHT40- and rejects HE40/VHT40. OpenWrt 24.10's mac80211.sh understands HE40/VHT40 (and HT40+/HT40-/HT40), not HE40±/VHT40±. As a result:

  • htmode = HE40 is rejected (radio_args_invalid), and the radio keeps its previous settings.
  • htmode = HE40+ passes validation and is written to uci, but hostapd brings the radio up at 20 MHz, with no error anywhere.

So no HE/VHT radio can run at 40 MHz, and validation gives false confidence.

Where

  • src/services/hal/types/capability_args.lua:527 (RADIO_VALID_HTMODES) and the RadioHtmode alias at :545.
  • src/services/hal/drivers/radio.lua:16 (VALID_HTMODES).

Evidence

bigbox-v1-cm-2, devicecode-lua v0.11.3, OpenWrt 24.10.7. Radio1 (5 GHz) on channel 100, 2026-10-20:

  • htmode = HE40: logread shows LOG wifi warn radio_args_invalid err=htmode must be one of: HE20, HE40+, HE40-, HE80, HE160, HT20, HT40+, HT40-, VHT20, VHT40+, VHT40-, VHT80, VHT160 method=set_channels. uci is unchanged.
  • htmode = HE40+:
    • uci show wireless.radio1 has htmode='HE40+';
    • /var/run/hostapd-phy1.conf has he_oper_chwidth=0 and no 40 MHz ht_capab;
    • hostapd logs DFS-CAC-START freq=5500 chan=100 sec_chan=0, width=0;
    • iw dev reports width: 20 MHz.
  • On the box, /lib/netifd/wireless/mac80211.sh matches htmode with case patterns such as HT40*|VHT40|VHT80|VHT160|HE40|HE80|HE160|EHT40|EHT80|EHT160 (around lines 169, 246 and 749). HE40+ doesn't match any of them.
  • HE80 works (verified).
  • VHT40± is inferred from the same script, not tested on hardware.

Impact

40 MHz operation isn't available for HE/VHT configs, and the fallback to 20 MHz is silent. That matters wherever 80 MHz is too wide, e.g. dense sites or DFS channels.

Suggested fix

  • Accept HE40 and VHT40: OpenWrt chooses the secondary channel itself.
  • Either map HE40±/VHT40± to those values, or reject them with a clear error.
  • Keep HT40±.
  • Add validator tests.

Found while setting up the grand-pipeline Wi-Fi client test (jangala-dev/grand-pipeline#18).

Dominant language
Lua
Stars
1
Forks
0
Avg merge
5d 15h
Merged PRs (30d)
3

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from jangala-dev/devicecode-lua

All issues in jangala-dev/devicecode-lua

Similar issues

More Lua issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.