search

dortania / bugtracker

Dortania Bugtracker
108 stars 7 forks source link

Compatible wireless chart #204

Open vit9696 opened 3 years ago

vit9696 commented 3 years ago

Guide: Wireless Buyers Guide (link)

At least some people here remember a table made by Skvo, which outlined Wi-Fi compatibility (https://github.com/acidanthera/bugtracker/issues/1629#issuecomment-833034654). This table was an intuitive way to see which Wi-Fi card is supported natively and which Wi-Fi card required device-id spoofing. It also lists the compatible macOS versions Wi-Fi protocol support.

Unfortunately at this time the table is rather outdated, and all the alternatives we have seen or been linked to (see the link above for an example) contain multiple errors or are simply misleading. For example, the one in question has the following errors at the very least:

I suggest us build a new version of the table that can be maintained on community basis and have much less errors compared to the tables that exist now and more information in a convenient form compared to Dortania guides.

@1alessandro1, since you started the matter, would you like to build a new table correcting the issues that I listed and taking the original Skvo table into account. This could give us a base, so that @Andrey1970AppleLife would review it and request more corrections. Afterwards we could put it somewhere like this Dortania guide.

1alessandro1 commented 3 years ago

That document also present on a different revision here came back in my mind when I was looking for additional info in an Atheros card (more info on that at the end).

I already started translating the Google drive sheet, but if the info on the original made by Skvo doesn't have the problems which affect the Google drive sheet, I can apply the changes from an already trusted source.

It's worth to mention that I can maintain the new sheet, and I could provide my experience only with the WiFi cards I've tested myself, such as:

From my perspective, I can tell only the state of support of the Wi-Fi cards I've worked with and a couple more (like the Intel 3165 with itlwm.kext) but a lot of additional info like Bluetooth behaviour has to come from the end users.

For that matter, a Google drive document might not be the best choice for usability, since this extensive and detailed documentation has to be treated as AppleALC codecs support where there are a gigazillion of codecs and users can easily contribute with a PR which is later approved by the team.

How to reach the public?

To accomplish this we should advice all users from forums to collect the required data, either by opening a topic on insanelymac and applelife that redirects users to open pull requests on the Wireless buyers guide for the extensive information (for cards are quite revision dependent) and where the team can check the reported data from a given card, e.g. the DW1830, the DW1820A and its flaws.

The main resource for Wireless documentation must be the buyers guide, since the excel document might have its limitations on the available data, about that I think it's best to provide a template to populate the excel document with the necessary data to document a card for example:

Data Type Value
Commercial name Fenvi T919
Card model BCM94360CD
Card device-id 14e4:43a0
Device-id Spoof required No
Card Form factor PCIe X1
2.4 GHz Speed 450Mbps
5 GHz Speed 1300Mbps
802.11 Support a/b/g/n/ac
Bluetooth version 4.0
Is BcrmPatchRAM required No
Is ExtendBTFeatureFlags required No
Antennas max count 4
Minimum macOS support (no patches) 10.12?
Maximum macOS support (no patches) Current
Additional kexts/injectors required from AirportBrcmFixup No

Notes:

Data Type Value
Device-id Spoof required Yes, <"vendor:device-id">, <"compatible", "device-id in little endian">

For Intel WiFi there's plenty of info/support for cards already available, but:

  1. itlwm.kext has the following limitations:

    • (1.1) It has a minimum macOS support of 10.9 (Darwin 13.0.0) but the card is treated as an ethernet device, so no features support like Airdrop/Handoff/Continuity
    • (1.2) Features like Find My do not work, since it relies on Wi-Fi data (like what networks are around you). This likely means that other location services don't work as well.

  2. AirportItlwm.kext has the following limitations:

    • (2.1) DHCP is broken in macOS Big Sur, workaround: use itlwm.kext with HeliPort.
    • (2.2) Handoff and Universal Clipboard are the only supported Continuity features
    • (2.3) Instant Hotspot from iPhone can be recognized but may likely fail to connect, workaround: use itlwm.kext with HeliPort.
    • (2.4) Apple Bluetooth peripherals may fail to connect, workaround: use itlwm.kext with HeliPort or disable iCloud.
    • (2.5) Unable to connect to Hidden Networks.
    • (2.6) A sleep/wake cycle might break wifi, and requires at least 10.13 to work, so it has to be mentioned somewhere

Atheros support is a little controversial on my perspective:

  1. In particular, the card which I mentioned in the beginning, it was the Atheros AR5B95 (pci168c,002b)
    • (3.1) There're already some resources kindly provided by @khronokernel of previous versions of IO802Family.kext, but plugins like AirPortAtheros40.kext is present in OpenCore docs with a different link and I don't actually know what could be the difference, if they're the same, or if one approach (loading the kext) is preferred over the other (loading IO80211HighSierra + AirportAtheros40.kext as a plugin)
    • (3.2) in the Wireless Buyers guide AR5B95 is present, but it has a different device-id: pci168,002b which is not included, at first I thought spoofing if it makes sense, and if that's true, what would be the preferred choice, e.g. 002a on what basis? image.png
    • (3.3) Then I've read @vit9696 reply that reports quote: Atheros Wi-Fi cards do not work with a device-id, and this led to even more confusion (how should I deal with that, just plug and don't care about the device-id or just trash that card? :P)

Sorry for the long read, let me know your thoughts when you can

vit9696 commented 3 years ago

Hi,

If this sounds good enough, it would be great if you start. I am generally fine with the format, but I guess it will help to see some results in case anything else comes to our minds.

1alessandro1 commented 3 years ago

If this sounds good enough, it would be great if you start. I am generally fine with the format, but I guess it will help to see some results in case anything else comes to our minds.

@vit9696

I've made a table with the data which came from the original google docs document (draft only, just as an example)

https://github.com/1alessandro1/Wireless-Compatibilty-Chart-for-macOS/blob/main/Chart.md

But from my point of view it's uneditable from markdown format (I can easily get lost when edititing a cell from the raw .md file)

I'll keep the google docs document here, and maybe convert it once it's corrected from there. For other users input, I still cannot find a good version control system that keeps the interface usable, for now users can open issues in the repository where the markdown is located, https://github.com/1alessandro1/Wireless-Compatibilty-Chart-for-macOS/issues to help me correcting their cards.

vit9696 commented 3 years ago

Makes sense. Could you add a column regarding Bluetooth support? Should mostly be easy to google out.

khronokernel commented 3 years ago

So with OpenCore Legacy Patcher, we have all wireless modules from 2008 Macs+ working quite nicely. I'll give a break down on our patch set. Note that for Atheros, BCM94322 and BCM94328 do not have Bluetooth modules integrated on genuine Macs

# Native Wireless Modules
BCM4360Wifi = [
    "43BA",  # BCM43602
    "43A3",  # BCM4350
    "43A0",  # BCM4360
]
# Modules that simply require a fake ID to a BCM94360 for Big Sur+ support
BCM94331Wifi = [
    "4331",  # BCM94331
    "4353",  # BCM943224
]
# Modules that rely on IO80211Mojave for Catalina+ support
BCM94322Wifi = [
    "432B",  # BCM94322
]
# Modules that rely on IO80211ElCap for Sierra+ support
BCM94328Wifi = [
    "4311", # BCM4311 - never used by Apple
    "4312", # BCM4311 - never used by Apple
    "4313", # BCM4311 - never used by Apple
    "4318", # BCM4318 - never used by Apple
    "4319", # BCM4318 - never used by Apple
    "431A", # Unknown - never used by Apple
    "4320", # BCM4306 - never used by Apple
    "4324", # BCM4309 - never used by Apple
    "4325", # BCM4306 - never used by Apple
    "4328", # BCM94328
    "432C", # BCM4322 - never used by Apple
    "432D", # BCM4322 - never used by Apple
]
# Modules that rely on IO80211HighSierra for Mojave+ support
AtherosWifi = [
    "0030", # AR93xx
    "002A", # AR928X
    "001C", # AR242x / AR542x
    "0023", # AR5416 - never used by Apple
    "0024", # AR5418
]
dhinakg commented 3 years ago

Regarding a proper format, I think the best idea is storing it in version control as a CSV (so you can edit with your favorite editors) and then converting it to Markdown where appropriate (ie. for the guides).

1alessandro1 commented 3 years ago

Regarding a proper format, I think the best idea is storing it in version control as a CSV (so you can edit with your favorite editors) and then converting it to Markdown where appropriate (ie. for the guides).

@dhinakg thanks for the tip, PR are welcome once the csv is editable from everyone, I exported the latest version in my repository here

Makes sense. Could you add a column regarding Bluetooth support? Should mostly be easy to google out.

@vit9696 Done, I'd like to know your opinion on the new columns, you can check either the csv or the google drive doc, they are in synch, any advice is appreciated

I'll give a break down on our patch set.

@khronokernel is there a lower limit for any of the broadcom cards? I suppose that the BCM94360NG is not compatible with 10.6, but requires at least 10.12? I need to know the lower limit too for every Wireless kext (hence in which macOS version it was introduced, for example the BCM94360CD - Fenvi T919 was approved by FCC February 8, 2013 does this mean that the next OSX release already includes that kext - 10.9?)

Also, regarding the Atheros support, some cards in the Wireless buyers guide are marked as compatible, but their device-ids are not included in the list provided in the Readme of IO80211-Patches, that's the case of the AR5B95, what should be done in this case? Should I load IO80211-HighSierra and the relative plugin, AirportAtheros_40, plug the card and pray 😆 ?

vit9696 commented 3 years ago

Hi @1alessandro1,

The mistakes I spotted:

For the Intel cards I suggest using yellow, and using the AirportItlwm as a value for 10.13+ and itlwm as a value for older versions instead of YES. This is more practical. Perhaps 10.13+ and <10.13 yellow colours should also be different, as the experience with AirportItlwm is reasonably better than itlwm, but it is still far from a native card feature-wise.

As for the BT column, in my opinion, you would want a separate column for the device-id and a status column with colouring. Green for native BT, yellow for BrcmPatchRAM solutions, which can have either BrcmPatchRAM+FW or BrcmPatchRAM values. The latter means BrcmPatchRAM needs to spoof the identifier, and the former means that it also needs to load the firmware.

It is unclear to me what Force IO80211Family means, looks like garbage at a glance. Is it about prelinking support? If so, the issue is not with Catalina but rather with installing macOS without a Wi-Fi card, and then not running sudo touch /System/Library/Extensions to add the kext to the cache after installing the card. Enabling secure boot should also workaround such a problem.

Regarding Broadcom driver support the support really varies over the macOS versions. You can check https://github.com/khronokernel/Apple-Kext-Clone. It has IO80211Family.kext, where you can find the relevant Info.plists and check if the card is supported. For 10.6 I attached the IO80211Family below. IO80211Family-10.6.8.zip

1alessandro1 commented 3 years ago

Hi Vit, thanks for checking it out

  1. BCM94360NG has BT4.0 [Fixed]
  2. BCM94360NG speeds should be 300 for 2.4 and 867 for 5.0 [Fixed]
  3. BCM94360CD speed for 2.4 must be 300, 2.4 cannot give more than 300. [Fixed]

For the T919, I've read that Fenvi advertises its card for 1750Mbit/s which could be the result of the sum 1300 + 450, so I looked online for some additional info and 450Mb/s for 2.4 was plausible under ideal contitions, so I opted out for 450 before, now it's set to 300Mb/s

It is unclear to me what Force IO80211Family means, looks like garbage at a glance

For the Force IO80211Family (in BCM94331xxx chipsets) I meant two things, first that device ids dropped in e.g. Big Sur/Catalina as the Wireless Buyers Guide reports (the second one coming at the end of the message) image

Regarding Broadcom driver support the support really varies over the macOS versions. You can check https://github.com/khronokernel/Apple-Kext-Clone. It has IO80211Family.kext, where you can find the relevant Info.plists and check if the card is supported. For 10.6 I attached the IO80211Family below. IO80211Family-10.6.8.zip

I'm going to have a look into that, thanks for pointing it out

If a given OS does not include a device-id, should I write Device id spoof to [other model] what if the card was completely dropped?

[11]

    AirPortBrcm4360: removed
    AirPortBrcm4331: removed
    AirPortBrcmNIC: 43ba, 43a3, 43a0, IOProbeScore = 1400
    AirPortBrcmNIC-MFG: removed

In macOS 11, I suppose that older chipsets require the missing kexts to be loaded manually (hence the improper Force IO80211Family but I meant to load a kext from an older macOS version) Is my hypotesis correct?

vit9696 commented 3 years ago

For the Force IO80211Family (in BCM94331xxx chipsets) I meant two things, first that device ids dropped in e.g. Big Sur/Catalina as the Wireless Buyers Guide reports (the second one coming at the end of the message)

Force is there to avoid prelinkedkernel not having IO80211. An alternative is to enable secure boot. However, this can happen with any device, so I do not get why this device has it written specifically. I would opt with dropping this part from the chart and from the guide, but including somewhere below in the troubleshooting part. For the chart you should just write DeviceID spoof. CC @dhinakg @khronokernel

If a given OS does not include a device-id, should I write Device id spoof to [other model] what if the card was completely dropped?

Google, if there are success reports, then yes. If there are none, then write either unsupported or unknown.

In macOS 11, I suppose that older chipsets require the missing kexts to be loaded manually (hence the improper Force IO80211Family but I meant to load a kext from an older macOS version) Is my hypotesis correct?

I think only @khronokernel or @dhinakg can answer that. I don't know.

1alessandro1 commented 3 years ago

I found dealing with individual models very time consuming, since every device has to be googled for its peculiarities, but for now, I've compiled a new sheet extracting the native device-ids (hence no Device-id fix/Quirk is reported) for every macOS version:

https://docs.google.com/spreadsheets/d/1CNrDxBsmCbCTL_y9ZB7m3q3jHw5X2N8YaYb7IonQ3MI/edit?usp=sharing

This can be a good starting point, and for Intel, I suggest the end user to check OpenIntelWireless docs for now since the device-ids/models/speeds are really a ton of data, and the only thing one should take into account is that he can use itlwm.kext for 10.9+ (with Heliport) and AirportItlwm.kext for 10.13+, ensuring the device is present in this list

Let me know your thoughts, cc @khronokernel @dhinakg @vit9696

1alessandro1 commented 3 years ago

Today I added to the sheets file additional info for Intel wireless device-ids, for reference I used the docs and inspected the source code of OpenIntelWireless/itlwm to find all the supported device-ids.

Hyperlinks were put at the beginning of each new block of WiFi cards, here's where they were taken from:

1alessandro1 commented 3 years ago

Added support for macOS 12 IDs.

Seems like now Broadcom cards are not included in IO80211Family.kext but IO80211FamilyLegacy.kext, where users can find AirportBrcmNIC.kext with the same IDs as those which can be found in macOS 11.

p.s. Apple likes to drop support for stuff so easily these days.

dreamwhite commented 3 years ago

I found dealing with individual models very time consuming, since every device has to be googled for its peculiarities, but for now, I've compiled a new sheet extracting the native device-ids (hence no Device-id fix/Quirk is reported) for every macOS version:

https://docs.google.com/spreadsheets/d/1CNrDxBsmCbCTL_y9ZB7m3q3jHw5X2N8YaYb7IonQ3MI/edit?usp=sharing

This can be a good starting point, and for Intel, I suggest the end user to check OpenIntelWireless docs for now since the device-ids/models/speeds are really a ton of data, and the only thing one should take into account is that he can use itlwm.kext for 10.9+ (with Heliport) and AirportItlwm.kext for 10.13+, ensuring the device is present in this list

Let me know your thoughts, cc @khronokernel @dhinakg @vit9696

In the table that @1alessandro1 linked, I noticed that some device-ids introduced in Yosemite, such as 14e4:4353, are supported both from AirPort4331 and AirPort4360. Which one of them is effectively used to support such cards? Is there any kind of priority?

In addition to that, to obtain Atheros support on newer OSs (such as Big Sur) should we load just AirportAtheros40 or the whole IO80211Family+AirportAtheros40 (IO80211Family took from High Sierra 10.13.6 and properly patched)?

What are your thoughts on that?

cc @khronokernel @dhinakg @vit9696

Many thanks and have a nice day