Inner value of `CWPHYMode` appears to change between integer and bitflags index between macOS versions

[keabarnes]

In the code below, the inner value of CWPHYMode which is returned by interface.activePHYMode() differs based on the macOS version.

unsafe {
  let client = CWWiFiClient::sharedWiFiClient();

  let interface = client.interface().unwrap();

  let phy_mode = interface.activePHYMode();
}

From observation I've noticed that

• on macOS 14.5 the inner value is represented by an integer that maps well to the const ... Self(n) constants on the enum
• on macOS 15.0 it seems like the value represents the naive conversion from a bitflag to an integer
  • 802.11n is returned as CWPHYMode(16) but should be CWPHYMode(4)
  • 802.11ax is returned as CWPHYMode(64) but should be CWPHYMode(6)

---

Cargo.toml for context

objc2 = { version = "0.5", features = ["apple"] }
objc2-foundation = { version = "0.2", features = ["apple"] }
objc2-core-wlan = { version = "0.2", features = [
  "CWInterface",
  "CWNetwork",
  "CWWiFiClient",
  "CWChannel",
  "CoreWLANTypes",
] }

[simlay]

Huh. This is interesting. I ran the example code. I'm on macOS 15 with an 802.11ac network. I get a CWPHYMode(32) when I presume it should be CWPHYMode(5). I get the same incorrect result mentioned above with an 802.11n network.

The mapping looks like:

• CWPHYMode(4) is returned as CWPHYMode(16)
• CWPHYMode(5) is returned as CWPHYMode(32)
• CWPHYMode(6) is returned as CWPHYMode(64).

Looks like the pattern is a bitmask rather than an integer?

[madsmtm]

I'm still on macOS 14.7, and can't test this in a virtual machine (since the virtual machines don't have WiFi), so could I get one of you to test the following:

1. RUSTFLAGS="-Clinker-flavor=ld" cargo run (in case this is dependent on the minos/sdk version in the binary)
2. The equivalent Swift code:

   import CoreWLAN
   
   let client = CWWiFiClient.shared()
   let interface = client.interface()!
   let phy_mode = interface.activePHYMode()
   print(phy_mode.rawValue)

[keabarnes]

Sorry for the delay in my response, after running all the variants you asked for above, I only realized that the output had been fixed. I'm not sure if it was in this repo or the underlying framework, but it seems right now right?

I'd appreciate understanding if it was the underlying macOS version so I know to expect incorrect values from a specific version of the OS or of this crate, if you know? I'm now on macOS 15.1.1.

fn main() {
    use objc2_core_wlan::CWWiFiClient;

    unsafe {
        let client = CWWiFiClient::sharedWiFiClient();

        let interface = client.interface().unwrap();

        let phy_mode = interface.activePHYMode();

        println!("{:?}", phy_mode);
    }
}

Without flag:

❯ cargo run --example madsmtm_objc2_issues_662

Compiling ...
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 56s
Running `target/debug/examples/madsmtm_objc2_issues_662`

CWPHYMode(6)

With flag:

❯ RUSTFLAGS="-Clinker-flavor=ld" cargo run --example madsmtm_objc2_issues_662

Compiling ...    
Finished `dev` profile [unoptimized + debuginfo] target(s) in 3m 27s
Running `target/debug/examples/madsmtm_objc2_issues_662`

CWPHYMode(6)

Swift:

import CoreWLAN

let client = CWWiFiClient.shared()
let interface = client.interface()!
let phy_mode = interface.activePHYMode()
print(phy_mode.rawValue)

6
Program ended with exit code: 0

[keabarnes]

Running above Rust code snippet again on macOS 15.0.1 with the same version of objc2-* results in the original CWPHYMode(64) issue, regardless of wether the example was run with the RUSTFLAGS set or not. It seems like this is the an issue with the underlying OS framework, do you have precedent in the codebase to handle things in a specific way given a specific version of the OS?

[madsmtm]

Running above Rust code snippet again on macOS 15.0.1 with the same version of objc2-* results in the original CWPHYMode(64) issue, regardless of wether the example was run with the RUSTFLAGS set or not.

Damn! Could you check macOS 15.0 and macOS 15.1 too, just to be sure of the full range of (non-beta) versions that this happens on?

It seems like this is the an issue with the underlying OS framework, do you have precedent in the codebase to handle things in a specific way given a specific version of the OS?

Hmm, not really, especially not something like this. But I think you'd be able to handle it with something like:

1. Modify objc2-core-wlan/translation-config.toml to contain class.CWInterface.methods.activePHYMode.skipped = true, and re-run the header translator (if it's difficult for you to set up, then I can do that part myself).
2. Add a file that contains something like:

   impl CWInterface {
       #[cfg(feature = "CoreWLANTypes")]
       fn activePHYMode(&self) -> CWPHYMode {
           let inner: CWPHYMode = unsafe { msg_send![self, activePHYMode] };
           // These versions had a bug [explanation]
           if available!(macos = 15.0) && !available!(macos = 15.1) {
               CWPHYMode(inner.0 >> 2)
           } else {
               inner
           }
       }
   }

If it affects CWNetwork::supportsPHYMode too, then something similar should be done there as well.

[madsmtm]

Are you still interested in this @keabarnes?

Personally, I'm leaning towards "do nothing" here, since this was fairly clearly a bug in Apple's code which has since been fixed. I'd rather recommend that if you do want to support those buggy versions of macOS, that you do the conversion in your own code. Again, it can be done with just the available! macro:

use objc2_core_wlan::{CWPHYMode, CWInterface};
use objc2::available;

fn fixed_activePHYMode(interface: &CWInterface) -> CWPHYMode {
    let inner = unsafe { interface.activePHYMode() };
    // These versions had a bug [explanation]
    if available!(macos = 15.0) && !available!(macos = 15.1) {
        CWPHYMode(inner.0 >> 2)
    } else {
        inner
    }
}