MT7925 (103c:8f06) on macOS 26.0 (25A354): Ethernet front end works (en1), no native Wi-Fi UI — is 26.0 supported? #6

Thanks for the report, that's a new board for the list.

1. 26.0 is unsupported on purpose. MtkWlanNative is built against the private IO80211 class layouts of two builds, 26.7.1 (25G241) and 26.7.2 (25G332), and refuses to load on any other, so a wrong layout can't panic the machine. I don't plan to add 25A354: every build needs its own headers and a test boot, and I only have the current ones. Updating to 26.7.2 gets you the Wi-Fi menu. The MtkWlan 0.12.1 you run now stays, and you add MtkWlanNative 0.4.15 and the two boot-args from the README.
2. Nothing to collect on 26.0. If you update, ioreg -r -c MtkWlan -l -w0 | grep -E 'MtkFrontEnd|MtkCountry' after the first boot would show me how the HP card behaves with the native front end.
3. en1 is fine. macOS numbers the ports in the order they attach, and en2 is only what it happens to be on my laptop.

On the tool: scan, join and add need root because they go through the driver's user client. The mkdir failure is a real bug, mtkwifi add assumes /Library/Application Support/legion already exists. I've noted it to fix. For auto-join, tools/mtkwifi/install.sh installs a LaunchDaemon that does what yours does.

One more thing: the ifconfig block in your post shows the card's MAC address and your public IP. You may want to edit those out.

The mtkwifi add bug is fixed in 8a4de8e: the tool now creates /Library/Application Support/legion before its own folder. I tested it against an empty folder tree.

It will be in the next bundle. Until then, either build the tool from main with tools/mtkwifi/build.sh, or run this once and keep your current binary:

sudo mkdir -p "/Library/Application Support/legion"

Thanks for the detailed reply — and for the privacy catch, I have just redacted the MAC address, public IP, gateway and netmask from the report.

On 26.0: understood, keeping MtkWlan 0.12.1 as an Ethernet front end is fine for now. I will update to 26.7.2 at some point, add MtkWlanNative 0.4.15 plus the two boot-args, and report back with:

ioreg -r -c MtkWlan -l -w0 | grep -E 'MtkFrontEnd|MtkCountry'

On en1: thanks for confirming — the port numbering explanation makes sense.

On the tool: good to hear the mkdir bug is fixed in 8a4de8e. I can either build from main with tools/mtkwifi/build.sh or wait for the next bundle; happy to test whichever is more useful to you.

Board details for the list, if you want them:

• Model: HP HyperX OMEN PRO 16
• Board: 103c:8f06
• Wi-Fi subsystem: 103c:8c38, PCI 14c3:7925
• CPU: Ryzen 9 9955HX
• macOS: 26.0 (25A354), OpenCore 1.0.9
• Project: https://github.com/xiaoyizpast/Hackintosh-OMEN-8f06

Once I am on 26.7.2 I will also test scan/join through the native front end and report any differences from the Ethernet front end.

Updated this machine from 26.0 (25A354) to 26.7.2 (25G332) and installed MtkWlanNative 0.4.15 with mtkfe=native mtknativeif=1, as you suggested.

The Wi-Fi pane is now present and the interface joins at boot. Results:

$ system_profiler SPAirPortDataType
  en1:
    Card Type: Third-Party Wireless Card
    Firmware Version: MtkWlanNative 0.4.15
    MAC Address: f6:33:e5:09:b5:95
    Country Code: CN
    Supported PHY Modes: 802.11 a/b/g/n/ac
    Status: Connected

$ ioreg -r -c MtkWlan -l -w0 | grep -E 'MtkFrontEnd|MtkCountry'
    "MtkCountry" = "US, 36 channels (11 at 2.4 GHz), rc 0"
    "MtkFrontEnd" = "ethernet"

Two observations that may be worth a look:

1. MtkFrontEnd still reports ethernet in ioreg, even though CoreWLAN shows the native front end and the Wi-Fi pane works. Possibly the property is only set by the core kext and not updated by the front end.
2. MtkCountry reports US while system_profiler reports CN.

No crashes, panics or firmware timeouts so far; the machine has been up through several reboots with the native front end enabled. Happy to run any additional ioreg/log collection you want.

On the 26.0 side I also archived the menu bar front end we used before upgrading (issue #7) as an optional fallback; no action needed from you.

Thanks, that is a useful report, and it is good to have a second laptop confirmed. I added the OMEN to the card table in the README.

1. MtkFrontEnd = ethernet. Misleading, not wrong. The driver always creates its built-in Ethernet object, and that object publishes MtkFrontEnd whether or not it owns the link. The property to read is MtkFrontEndActive:

ioreg -r -c MtkWlan -l -w0 | grep -E 'MtkFrontEnd(Active|Wanted)|MtkNativeAbiBuild'

On my machine that prints MtkFrontEndActive = native next to the same MtkFrontEnd = ethernet you see. If yours says native too, everything is as it should be. The old property will be renamed in the next driver release so the two stop contradicting each other.

2. US against CN. These are two different things:

• Country Code: CN in System Information is the Country element of your access point. The menu kext reports it when macOS has not given the driver a country.
• MtkCountry is the regulatory domain the radio really uses. It stays US until macOS sends a country code to the driver, and on your machine it has not sent one.

With the US set, 2.4 GHz channels 12 and 13 are not scanned and transmit power follows the US table. On channels 1 to 11 and on 5 GHz you will not notice a difference. If a network of yours sits on 12 or 13 and does not show up, that is the reason, and I would like to hear about it.

3. The bundle. mt7925-wifi-bundle-0.12.1+0.4.16.zip is up, with the fixed mtkwifi in its Recovery folder. MtkWlanNative 0.4.16 only adds the 26.7.3 developer beta (25G416), so on 26.7.2 you can stay on 0.4.15. For later: the 26.7.3 release (25G342) works with 0.4.15 as well, only the beta needs 0.4.16.

A correction and a fix for point 1. I had the cause wrong: MtkFrontEnd was not coming from the Ethernet object. It is the driver's own setting key, and the registry kept showing its Info.plist default (ethernet) even when mtkfe=native overrode it.

0.12.2 writes the request back, so with mtkfe=native it now reads MtkFrontEnd = native. MtkFrontEndActive is still the line that says which front end runs. Nothing else changes for your card in this release, so there is no need to update for it.

Checked on this machine:

$ ioreg -r -c MtkWlan -l -w0 | grep -E 'MtkFrontEnd(Active|Wanted)|MtkNativeAbiBuild'
  "MtkFrontEndActive" = "native"
  "MtkFrontEnd" = "ethernet"
  "MtkFrontEndWanted" = "native"
  "MtkNativeAbiBuild" = "25G332"

So the native front end is active and the old key is the stale default, as you described. No networks on 2.4 GHz channels 12/13 here to test the US regulatory set with; I will report if one shows up.

For reference, the common channels in China are 2.4 GHz 1–13 (12/13 indoor) and 5 GHz 36–64 / 149–165. 6 GHz is not available for Wi-Fi here (allocated to IMT), so Wi-Fi 6E/7 in China has to run on 2.4/5 GHz only.

One question: is Wi-Fi 7 (802.11be / EHT, MLO) or 6 GHz support anywhere on the roadmap? The driver currently associates at VHT 80 MHz and the card's HE/EHT capability is unused; I am mainly asking whether that is a hard limit of the current approach or something you may look at later.

I will pick up 0.12.2 with the next bundle; staying on MtkWlanNative 0.4.15 on 26.7.2 as you suggested, and only need 0.4.16 if I move to the 26.7.3 developer beta.

Thanks for checking. That output is what 0.12.1 should show: the native front end runs, and from 0.12.2 on MtkFrontEnd no longer shows the stale default. Thanks for the channel list too.

Wi-Fi 7 and 6 GHz: not a hard limit, but not something I'm working on now. The card's firmware can do HE and EHT. What's missing is in the driver: the association only offers HT and VHT, so the link tops out at VHT 80 MHz, and the core doesn't scan or join on 6 GHz at all (6 GHz also requires WPA3, which isn't in yet). HE on 5 GHz would be the first step, and where you are it's also the only one that matters. MLO is much further away, because the macOS side of it would have to be worked out as well. I can't give a date for any of it.

One change since yesterday: the driver, the menu part and the Bluetooth loader are now one kext, WTLWireless 0.14.0, and this repo was renamed to match. Nothing forces you to move. 0.12.1 with 0.4.15 keeps working on 26.7.2. When you do update, the README lists the three Kernel > Add entries that replace the old ones.