Is "ucode wifi-scripts" good to use already?

[AcidSlide]

Hi All,

I've been searching for a couple of hours regarding if the "ucode" version for the wifi-scripts is production ready already but can't find anything about it.

I've been using the main/snapshot for all my routers for more a few years now but since 24.10.x is around the corner, I'm thinking of switching to the latest RC. But my question is, should I use the "ucode" or stick with it disabled for now?

Thanks in advance!

[brada4]

24.10 is with shell script. You can go with 24.10-SNAPSHOT to have rolling stable version.

[AcidSlide]

So it's safe to assume that for now, wifi shell scripts is stable compared to wifi ucode?

[brada4]

shell scripts are stable for 10 years or something. ucode is recent rewrite.

[hnyman]

Well, @nbd has now changed the new ucode wifi-scripts to active by default in main/master snapshot builds.

At least for me, the 5 GHz radios are unoperable, both R7800 (without the previously optional "band" option set), and also with MT-6000 (with "band" set"). Apparently some other option (channel fallbacks, WPA3 or 802.11r related?) fails to get interpreted correctly.

Now when the new scripts are enabled by default, bugs will likely surface about config combinations, as all possible configs have surely not been tested by now.

I wrote a bug about my issue.

wifi-scripts (ucode): R7800 fails to initialize radios

[nbd]

Please report any configs that stopped working with the ucode scripts to me. The band/hwmode issue is already fixed.

[hnyman]

Thanks @nbd for quickly fixing both the band/hwmode thing as well as the 802.11r options parsing.

• https://github.com/openwrt/openwrt/commit/ce3ab2646b1e1f14f1d7d4d67698bd7fd85c821f
• https://github.com/openwrt/openwrt/commit/0da0a6c449f965f12a18ca701cefac6b9bf67051

[stangri]

Can you guys catch up the rest of the class on what are you talking about?

Is there an attempt to rewrite the script which translates uci config into hostapd config from shell script to ucode?

[xize]

I might managed to have a config which seem to break:

wireless config

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi'
        option channel '10'
        option band '2g'
        option htmode 'HE20'
        option cell_density '0'
        option txpower '10'
        option country 'NL'
        list hostapd_options 'ssid_protection=1'
        option log_level '3'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'platform/soc/18000000.wifi+1'
        option channel '100'
        option band '5g'
        option htmode 'HE160'
        option cell_density '0'
        option country 'NL'
        option txpower '16'
        list hostapd_options 'ssid_protection=1'
        option log_level '3'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option mode 'ap'
        option ssid 'GL-MT6000-7fa'
        option encryption 'psk2+aes'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option ieee80211w '1'
        option ocv '1'
        option wpa_disable_eapol_key_retries '1'
        option mobility_domain 'F8DD'
        option reassociation_deadline '20000'
        option macaddr 'random'
        option dynamic_vlan '2'
        option wpa_psk_file '/etc/hostapd/ppsk-vlans'
        option skip_inactivity_poll '1'
        option vlan_naming '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option mode 'ap'
        option ssid 'GL-MT6000-7fa-5G'
        option encryption 'psk2+aes'
        option ieee80211r '1'
        option mobility_domain 'F8DC'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option ieee80211w '1'
        option reassociation_deadline '20000'
        option macaddr 'random'
        option ocv '1'
        option wpa_disable_eapol_key_retries '1'
        option skip_inactivity_poll '1'
        option dynamic_vlan '2'
        option vlan_naming '1'
        option wpa_psk_file '/etc/hostapd/ppsk-vlans'

config wifi-vlan
        option iface 'default_radio0'
        option vid '178'
        option name 'aqnet'
        option network 'aqaranet'

config wifi-vlan
        option iface 'default_radio0'
        option vid '179'
        option name 'hwnet'
        option network 'hwnet'

config wifi-vlan
        option iface 'default_radio1'
        option vid '90'
        option name 'aya'
        option network 'ayaneo'

config wifi-vlan
        option vid '52'
        option name 'iot'
        option network 'iot'
        option iface 'default_radio0'

config wifi-vlan
        option vid '62'
        option name 'beta'
        option network 'beta'

config wifi-vlan
        option iface 'default_radio0'
        option vid '133'
        option name 'sma'
        option network 'sma'

config wifi-vlan
        option iface 'default_radio1'
        option vid '50'
        option name 'wlan0'
        option network 'wlan0'

config wifi-vlan
        option iface 'default_radio0'
        option vid '51'
        option name 'wlan1'
        option network 'wlan1'

/etc/hostapd/ppsk-vlans

vlanid=178 00:00:00:00:00:00 pass1
vlanid=179 00:00:00:00:00:00 pass2
vlanid=90 00:00:00:00:00:00 pass3
vlanid=52 00:00:00:00:00:00 pass4
vlanid=62 00:00:00:00:00:00 pass5
vlanid=133 00:00:00:00:00:00 pass6
vlanid=50 00:00:00:00:00:00 pass7
vlanid=51 00:00:00:00:00:00 pass8

And I also use a patch in my build by @Fail-Safe this worked really fine, upon there was a recent change in the OpenWrt tree, (I suspect this ucode change), the issue seem to remain also without patch, when I use:

make package/network/services/hostapd/clean
make package/kernel/mt76/clean
make -r -j8

Router: Flint 2 MT6000

Clients don't want to connect.

edit:

I unchecked the ucode version inside make menuconfig and the issue was gone, so deff the issue is within this change.

[hnyman]

@stangri

Can you guys catch up the rest of the class on what are you talking about?

Source code is your friend with that question...
Blogic and Nbd wrote some months ago revamped scripts for wifi device and interface handling. Netifd, mac80211, uci combination of OpenWrt components touching WiFi. And e.g. the multi-link functionality is only implemented to the new code.

wifi-scripts: add ucode based scripts

commit history: https://github.com/openwrt/openwrt/commits/main/package/network/config/wifi-scripts

The new scripts have been non-default during development until now, but now they are the default. So, corner cases with more exotic options will likely surface in the test usage by larger population.

[Gingernut]

Has anyone had any problem with WDS using these new scripts after the most recent updates yesterday? wpa_supplicant failed to start error on the WDS client.

I’ll post some logs when I get the chance.

Edit: possible fixed in https://github.com/openwrt/openwrt/commit/84ea33609729bf41eb3de8a4cc2a66eb4c0b8f49

[tapper]

“Source code is your friend” That statement is not my friend. Not all people can read Source code. It does not help people understand what’s going on with in the OpenWrt project. infact that is just the thing to put people off coming around the forums!

[tapper]

Hi how will the change to “ucode wifi-scripts” help the OpenWrt project? What’s wrong with the scripts we had? If we don’t know what’s going on how can the people who like to tinker with snapshots do proper testing? How would we know what’s the rite bug to post on the git? It just happens that I have bin playing around with 802.11s and things have not bin going well. This could be the caws of some of my frustration. If I hade a heads up then I mite of bin able to think about things in a different way. All so of dun some proper testing without not knowing the scripts being changed was mooving the goalposts To run proper tests you have to be shure of the parameters you are working with.

Frustratingly the OpenWrt is always like this. It’s one of the things that puts people off.

[slh]

You have to distinguish between the needs of a developer (who's directly interacting with these interfaces in their packages) and those of a user, like yourself.

For a user, this is just a detail behind the curtain - for you, nothing should change, and where it does, it's a bug, like any other (completely independent of old wifi-scripts vs ucode, regressions can/ will happen anytime, not restricted to the new implementation).

@tapper

What’s wrong with the scripts we had?

Isn't 'they don't do MLO' already enough of an answer?
MLO is the major improvement of wifi 7, and it turns a lot of old assumptions on their heads. In order to support MLO, a lot of things need changing, kernel, hostapd, wifi-scripts, netifd, luci, …
Sure, with our 'old' devices (up to wifi 6) none of that is important, as MLO doesn't work there anyways, but there are new toys on the horizon, and those do need it (or OpenWrt would suck on those, compared to the OEM firmware).

MLO5+6 is what gives you 1.5-2.0 GBit/s throughput over the air, not just on paper, in practice . wifi7 (without MLO) does not.

[tapper]

Thanks for the info. Stuff like this is what should be championed to put the good name of OpenWrt out there. It gets people excited about using and being involved with openwrt as a project.

All so it is good for people to know what is going to be in the next builds/release.

Btw I think you are the first person to talk about MLO On here.

For those who don’t know.

Multi-Link Operation (MLO) allows devices to use multiple bands (2.4 GHz, 5 GHz, and/or 6 GHz) simultaneously to avoid network congestion and maintain connectivity.

[Gingernut]

Getting an oops on a mt7622 device that didn’t happen using the old scripts. The radios seem to come up and connect correctly after.

Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.166630] ------------[ cut here ]------------
Fri Sep 26 06:54:49 2025 kern.warn kernel: [   19.171277] WARNING: CPU: 0 PID: 1799 at ieee80211_hw_conf_init+0x78/0x80 [mac80211]
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.179161] Modules linked in: pppoe ppp_async nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7615e(O) mt7615_common(O) mt76_connac_lib(O) mt76(O) mac80211(O) cfg80211(O) ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c compat(O) cls_flower act_vlan fuse sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact cifs oid_registry nls_ucs2_utils cifs_md4 cifs_arc4 asn1_decoder dns_resolver netfs sha512_arm64 seqiv md5 geniv des_generic libdes uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd gpio_button_hotplug(O) usbcore usb_common
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.267373] CPU: 0 UID: 101 PID: 1799 Comm: wpa_supplicant Tainted: G           O       6.12.49 #0
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.276327] Tainted: [O]=OOT_MODULE
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.279807] Hardware name: TOTOLINK A8000RU (DT)
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.284415] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.291370] pc : ieee80211_hw_conf_init+0x78/0x80 [mac80211]
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.297054] lr : ieee80211_hw_conf_init+0x34/0x80 [mac80211]
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.302736] sp : ffffffc081f233f0
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.306042] x29: ffffffc081f233f0 x28: ffffffc081f23dc8 x27: 0000000000000000
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.313175] x26: ffffff8005d39940 x25: 0000000000000001 x24: 0000000000000001
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.320308] x23: ffffff8005d38000 x22: ffffff80038d08c0 x21: 0000000000000000
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.327440] x20: ffffff8005d38950 x19: ffffff80038d08c0 x18: 00000000ffffffff
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.334573] x17: 0000000000000028 x16: 0000000000000000 x15: ffffff801fea9940
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.341706] x14: 0000000000000000 x13: ffffff8000a7d4c0 x12: 0000000000000055
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.348838] x11: 00000000000000c0 x10: ffffff800001e0b8 x9 : 0000000000000000
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.355972] x8 : ffffff800000f8b0 x7 : 0000000000000000 x6 : 0000000000000000
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.363104] x5 : ffffff80016bde00 x4 : 0000000000000000 x3 : ffffff8000a7d400
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.370237] x2 : 0000000000000000 x1 : ffffff8000a7d400 x0 : 00000000ffffffea
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.377370] Call trace:
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.379807]  ieee80211_hw_conf_init+0x78/0x80 [mac80211]
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.385143]  ieee80211_do_open+0x598/0x750 [mac80211]
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.390218]  ieee80211_do_open+0x734/0x750 [mac80211]
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.395292]  __dev_open+0xe8/0x160
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.398693]  __dev_change_flags+0x154/0x1c0
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.402870]  dev_change_flags+0x20/0x64
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.406700]  do_setlink+0x280/0xe10
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.410183]  rtnl_setlink+0xf0/0x188
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.413753]  rtnetlink_rcv_msg+0x25c/0x358
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.417843]  netlink_rcv_skb+0x5c/0x128
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.421674]  rtnetlink_rcv+0x14/0x1c
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.425244]  netlink_unicast+0x22c/0x330
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.429160]  netlink_sendmsg+0x170/0x380
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.433076]  ____sys_sendmsg+0x1d0/0x280
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.436995]  ___sys_sendmsg+0x7c/0xc0
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.440652]  __sys_sendmsg+0x44/0x9c
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.444223]  __arm64_sys_sendmsg+0x20/0x28
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.448315]  invoke_syscall.constprop.0+0x4c/0xd0
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.453015]  do_el0_svc+0x3c/0xd0
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.456324]  el0_svc+0x18/0x60
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.459374]  el0t_64_sync_handler+0x118/0x124
Fri Sep 26 06:54:49 2025 kern.debug kernel: [   19.463725]  el0t_64_sync+0x150/0x154
Fri Sep 26 06:54:49 2025 kern.warn kernel: [   19.467381] ---[ end trace 0000000000000000 ]---

[lleachii]

@Gingernut

on a mt7622 device that didn’t happen using the old scripts.

Care to provide any details needed to assist?

(E.g., make, model, config, version, what old scripts, when did you update, etc.?)

[slh]

A kernel oops is very unlikely to be caused by wifi-scripts, that's more a 'mere kernel bug' (respectively mt76).

[Gingernut]

Yeah, sorry.

The model is Totolink A8000RU.

Almost always using own buiilds based on latest OpenWRT main branch.

The image is the same no kernel oops build, config, etc. Only change made is old wireless scripts for new ucode scripts, and this oops happens.

[platanopi]

Hi,

Is there a way to disable ucode Wi-Fi from the Luci ASU application?

Before ucode:

After ucode:

GL-MT6000 snapshot