Wi-Fi speed test: Intel AX200 vs BCM94360NG

[atanvarno]

Broadcom Wi-Fi driver fixing leads to root-patching macOS Sonoma and keeping it that way so the downgraded frameworks/kexts can be loaded. I really don't like running macOS in that state thus I put together a small test build, with ASUS ROG Strix B550-I board which has Intel AX200 card.

I aimed to test stability of the latest OpenIntelWireless drivers on Sonoma (version is 2.3.0 alpha) and see what I am missing by using Airportitlwm.kext. That's yet to be done properly (AirDrop, Handoff, Continuity etc). So far, both Wi-Fi and Bluetooth work as expected — connecting to my local network is pretty much instant, Bluetooth devices are visible etc.

I also tested the speed difference. I have super fast fiber connection which is much faster than what my current mesh router (Netgear Orbi RBK53) can handle. What I know the router can give me is 500Mbps download and 100Mbps upload.

Here's the result from Broadcom 94360NG card that I have been using purely because everything works with it, it's natively supported up to Ventura.



And here's the result with Intel AX200 card, from the same spot in the office:



I mean...WOW! It's rather near the maximum possible speed of the router.
I tested this multiple times just to be sure and it's always like this.

Now I'm wondering do I even need AirDrop that much.

 

[Edhawk]

421 Mbps may be the maximum or close to the max, as the router will never give you the full 500Mbps WiFi speed, due to overheads etc.

My tests with an AX210 card were similar, in that I could reach 80-90% of the theoretical WiFi speed provided by my router (600 Mbps).

Speeds from M.2 AX210 card on PCIe adapter.

Higher download/lower upload speed in this test, no changes made to network.

Speed when using Ethernet connection.

920 Mbps is the max I am expecting to see on my fibre connection, using Ethernet.

These tests were undertaken running macOS Sonoma using the Alpha release for Airportitlwm.kext.

 

[errevi]

If you guys want to try this kext for Sonoma taken from GITTER Official chat room for itlwm and HeliPort ...

 

[atanvarno]

If you guys want to try this kext for Sonoma taken from GITTER Official chat room for itlwm and HeliPort ...

What are the changes here from official alpha..?
This file seems to be from Sep, while 2.3.0-alpha is Oct 18. Thus nothing to gain by trying, I guess.

 

[atanvarno]

These tests were undertaken running macOS Sonoma using the Alpha release for Airportitlwm.kext.

Do you have issues with sleep in Sonoma, when using Airportitlwm.kext?

This build I have worked flawlessly in Ventura, sleep / wake were perfect, with 94360NG.
Now with AX200 and OpenIntelWireless, choosing Sleep from the Apple menu does nothing except turns the display off. No bad side-effects, monitor turns back on keyboard or mouse taps but still, no sleep.

I left some logs to the dev but I'm not sure it's really this kext, maybe it's something else.

 

[Edhawk]

Yes, the system doesn't like going to sleep, and while the display will go blank the system will wake nearly immediately, with the display on without the need for a key to be pressed or mouse moved.

It could be this kext, as it is still underdeveloped and only issued as an Alpha release. But it could as easily be any other kext or the CSPNEvaluation wake issue discussed in this thread over at Tonymacx86.

https://www.tonymacx86.com/threads/solved-ventura-sonoma-random-scheduled-pm-wake-from-sleep.323359/

 

[atanvarno]

It could be this kext, as it is still underdeveloped and only issued as an Alpha release. But it could as easily be any other kext or the CSPNEvaluation wake issue discussed in this thread over at Tonymacx86.

That's quite some investigation, impressive.
Sadly, none of those is the issue here.

I just tested, simply disabling Airportitlwm.kext in the config.plist and sleep works, as well as wake. Thus it's 100% something in the kext.

 

[atanvarno]

I expected AirDrop, Handoff and other Continuity features to not work with OpenIntelWireless. I could live without those features.

But for two days now, Messages and FaceTime refuse to sign in. iCloud works but these two — which are essential for me on the desktop — do not. This is such a bummer.

 

[Edhawk]

I've just checked my Intel AX210 card, which I have installed in an old Intel Hack running Sonoma, and Messages works just fine it syncs with iCloud as expected sends and receives messages.

I don't have a Webcam connected to the system so don't know if FaceTime would work, but as iCloud, Messages and the App Store all work just fine I don't see why FaceTime would be any different.

Have you checked that your SMBIOS data in your config.plist is correct and not used by a real Mac? As that is usually the cause of Messages and other Apple services not working on a Hack.

 

[atanvarno]

I believe I checked everything. en0 is present, marked as built-in, taken by Ethernet. Wi-Fi is en1, also built-in.
SMBIOS is fine, I used it previously for another build and with 94360NG. That build is now disbanded, thus not used.

Maybe I need to generate an entirely new set of SMBIOS params, since Wi-Fi/Bt have changed..?

 

[Edhawk]

Maybe I need to generate an entirely new set of SMBIOS params, since Wi-Fi/Bt have changed..?

That is not something I would expect to have to do when changing the WiFi/BT card.

Generating a new SMBIOS is usually required when upgrading macOS to a release that the current SMBIOS doesn't support. MacPro7,1 and iMacPro1,1 both support all recent macOS releases, so if you are using one of these then I wouldn't encourage or expect you to need to change the SMBIOS data.

But if you do generate a new SMBIOS:

• Make sure you sign out of iCloud and any other Apple services, before you use the new SMBIOS.
• Check the new Serial Number against the Apple Support page - https://checkcoverage.apple.com/
• Also remember to use the ResetNvramEntry.efi driver from the OC boot screen so any old settings are removed when you boot with the new SMBIOS.
• I would use a spare USB pen drive to test the EFI containing the new SMBIOS data, before replacing the EFI on your macOS drive.

 

[atanvarno]

This is a test build to figure out if AX200 is viable, I don't care much about it. So I can try anything.

So generated entire new set of serials, logged-in back into iCloud, data / files syncing etc.
But here — it picks up the iCloud account and tries to logs into iMessage...forever.



Super confused, honestly. This is my 6th or 7th Hackintosh, never had a behavior like this.

 

[Edhawk]

Does the Intel WiFi/BT card work in Windows or Linux?
Does the WiFi work in macOS, i.e. if you disconnect the Ethernet, can you still access the internet?

We need to confirm if this is a macOS issue or a hardware issue.

 

[Edhawk]

I assume from your first post that the WiFi works OK.

How did you generate the new SMBIOS?
When you generated the new SMBIOS, did you replace all four elements, i.e. MLB, ROM, Serial Number and SystemUUID in the config.plist? So you were using a complete set of new data, not a mix from different SMBIOS.

 

[Shaneee]

My Intel Laptop uses an AX200 and runs Sonoma. iCloud/iMessage and FaceTime are all logged in. iMessage has synced as has FaceTime call log but I'm unable to send messages or make any FaceTime calls from it. I'm sure it worked on Ventura however I can't be 100% on that. Memory isn't what it used to be

 

[atanvarno]

I assume from your first post that the WiFi works OK.

Yep, works great. Bluetooth too.

How did you generate the new SMBIOS?
When you generated the new SMBIOS, did you replace all four elements, i.e. MLB, ROM, Serial Number and SystemUUID in the config.plist? So you were using a complete set of new data, not a mix from different SMBIOS.

GenSMBIOS, checked validity, replaced all 4 elements.

I honestly think this is Apple being smart-ass. Like when they ask for the passcode from one of my oldest test iPhones because that one passcode is what encrypts the data in iCloud instead of the iPhone I use most frequently. Utterly ridiculous.

What really annoys me is that I can't find anything useful / actionable in the system logs.

 

[atanvarno]

I am occasionally trying Messages / FaceTime, to see would it work, as I continue to fiddle with this build. Thus one thing I did last night was: moved my custom USB map kext before the Ethernet / Wi-Fi / Bt kexts. (Read a random post that it might influence something around iServices.)
After that, I tried to login into these two services and results are...strange.

FaceTime appeared to login but none of the audio calls would actually connect. It rings on my side but never on the other.
Messages showed the list of alternative email addresses and phone number that are enabled on my Messages/iCloud account — thus indicating that login actually succedded — but fails to initiate any conversation and it still keeps spinning in the Settings/Account, apparently still getting...something.

I have to admit I am completely stumped how the hell did Apple implement these services. Being a developer for almost 30 years, I can't understand how it can work partially, like this. What the hell are they doing...

 

[Shaneee]

Same results with AX210 on my main rig now. Messages and FaceTime are refusing to work when previously working with BCM card. Continuity camera now works without issues though which is strange.

 

[atanvarno]

In all my tests, Messages start sending then blue progress bar appears, gets to near the end and just stays there. This is all on Sonoma, the only build I have with Intel card.

Was this — Messages/FaceTime + Intel WiFi — working for anyone in BigSur, Monterey or Ventura..?

 

[atanvarno]

I remembered I had half-working Monterey build on my son's computer, also with Strix B550I and Intel AX200.
Updated that build to OC 0.9.6 and using 2.2.0 Monterey version of Airportitlwm, it behaves exactly the same — Messages logs in but message sending timeouts. Literally identical behavior like on my build with Sonoma.

I suspect this could be something related to end-to-end encryption. Meaning they possibly use some hw crypto function or crypto parameter / value that is present or different on Broadcom chips versus Intel ones. Some form of validation is done that silently fails along the way and it simply timeouts on sender's end.

(That could (partially) explain with Messages/FaceTime remained proprietary Apple thing all these years. Remember when Steve Jobs said that FaceTime will be open standard and later it became known that developers heard about that for the first time when he said it on stage. It was never designed as such and who knows what it's doing under the hood. If we are lucky, EU Commission with its DMA law might force Apple to clean this up by next year.)