Wi-Fi is way more complex than you might think. This post attempts to explain some of that complexity, and how that affects the design of your network apps. Note I’m not a Wi-Fi expert. All of the following is the result of hard-won experience gained while investigating various oddball Wi-Fi problems. As a result it’s a vast simplification of how things really work. If you actually get to talk to a Wi-Fi expert, they’ll be happy to explain to you how Wi-Fi is even more complex than what I’ve explain below. Terminology As this post is going to talk about the fundamentals of Wi-Fi, I’m going to use Wi-Fi technical terms. Specifically: STA (station) — This is a Wi-Fi ‘client’ device. AP (access point) — This is the hardware running a single Wi-Fi network. The definition of Wi-Fi network is more complex than you might think, as I’ll explain next. SSID (Service Set Identifier) — This is what most folks think of as the Wi-Fi network. It’s the user-visible network identifier string that you see throughout the system. BSSID (Basic Service Set Identifier) — This defines a single Wi-Fi network at the Wi-Fi level. It’s identified by the MAC address - https://en.wikipedia.org/wiki/MAC_address of the AP, something that’s generally not user visible. In a typical home Wi-Fi network there’s a one-to-one relationship between SSID and BSSID. This is not true in more complex Wi-Fi setups. For example, in my home I have an Ethernet backbone with multiple APs bridged on to that backbone. Each AP has a different BSSID, but they all share the same SSID so that STAs can roam between APs without disrupting their network. This sort of setup is very common in enterprise environments. I also use various terms that are less widely accepted but are, nevertheless, important when discussing common scenarios: Wi-Fi hotspot — This is a Wi-Fi network where the user must interact with the network to gain access to the wider Internet (1). Wi-Fi accessory — This is an accessory which communicates over Wi-Fi. I use accessory in favour of device because, when working in the Apple ecosystem, device refers to your iOS device. Finally, I don’t use the term ad-hoc Wi-Fi. In my experience this term is so heavily overloaded as to be meaningless. See the next section for more. (1) Apple APIs are not as consistent about this as they should be. For example, the hotspot in NEHotspotHelper - https://developer.apple.com/documentation/networkextension/hotspot_helper is correct but the hotspot in NEHotspotConfigurationManager - https://developer.apple.com/documentation/networkextension/wi-fi_configuration is not (the API can be used to configure the device to join any Wi-Fi network, not just a Wi-Fi hotspot). Ad-Hoc Wi-Fi I don’t use the term ad-hoc Wi-Fi because, in my experience, this term means different things to different people: Some folks interpret it to mean IBSS - https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29#Independent. Some folks interpret it to mean Wi-Fi Direct - https://en.wikipedia.org/wiki/Wi-Fi_Direct. Some folks interpret it to mean Apple peer-to-peer Wi-Fi (aka AWDL or its predecessor). This is the mechanism used by Network framework when you set the includePeerToPeer - https://developer.apple.com/documentation/network/nwparameters/3020639-includepeertopeer flag, Multipeer Connectivity, and so on. Some folks interpret it to mean an infrastructure Wi-Fi network that doesn’t lead to the wider Internet, for example, one published by a Wi-Fi accessory. Given this confusion it’s best to avoid this term in favour something more specific. Unicasts Wi-Fi implements a link-level positive acknowledgement mechanism for unicast traffic. This is really important because the physical packet loss on a Wi-Fi network is pretty bad. In Wi-Fi, all unicast traffic is from STA to AP or vice versa. This makes sense when you think about it. You can’t send from STA to STA because: The STAs might be located such that each STA can see the AP but the STAs can’t see each other (for example, this might be a home network with the AP located in the middle of the home and the STAs located on the extremities) The STAs might be talking to different APs (that is, they’re on different BSSIDs) Wi-Fi unicast traffic is fast because the AP can set the speed of the link to be appropriate for the STA in question. Some APs refuse to forward STA-to-STA traffic. This is most often seen with Wi-Fi hotspots, where the hotspot isolates each STA as a security measure (this is, IMO, security theatre - https://en.wikipedia.org/wiki/Security_theater but there you go). Broadcasts Note In this context, broadcasts also includes multicasts. Wi-Fi broadcasts work very differently from Wi-Fi unicasts. In a broadcast, the STA sends the packet to the AP and the AP then transmits the broadcast and hopes that all the other STAs pick it up. The AP does two things to help improve the chances that the STAs will pick up the broadcast: It sends the broadcast at the lowest supported speed — This makes sense when you think that the AP might have a mix of STAs, some of which support high speed modes and some of which don’t. It typically ramps up its transmission power. These measures help, but they don’t guarantee that all the STAs will pick up the broadcast. If the network has multiple APs, the AP will typically forward the broadcast to the other APs and they will also broadcast the packet. However, this does not always happen. Many organisations have large flat networks, and thus put a limit on Wi-Fi broadcasts to prevent the whole network being flooded with broadcasts. In fact, the AP might not even forward broadcasts from its own STAs (for example, a hotspot that implements STA isolation as I discussed earlier). IMPORTANT When you’re designing a network protocol that will commonly run over Wi-Fi, you must take into account the peculiarities of Wi-Fi’s broadcast support. For example, if you’re only transmitting to a few peers (less than 10 say), it may be better to send a unicast to each peer rather than send a broadcast; the unicasts may be faster (because Wi-Fi will send each one at the highest speed supported by that peer) and will certainly be more reliable. Power Managerment A STA will often turn off its radio in order to save power. When this happens the STA sends the AP a packet telling it how long it’s going to have its radio off, and the AP buffers packets for that STA for the duration. Cool beans! This feature is also used to support radio and antenna multiplexing. On iOS there are two scenarios where that’s necessary: iOS devices commonly have a single antenna for Bluetooth and Wi-Fi, so the device must periodically turn off Wi-Fi so it can use the antenna for Bluetooth. If the device has a single Wi-Fi radio (which is common), it may need to change the channel on that radio in order to deal with peer-to-peer Wi-Fi. It should go without saying that, if the AP sends a broadcast while the STA isn’t listening, the STA won’t see that broadcast. Examining Wi-Fi Mechanics If you’re interested in seeing how Wi-Fi really works, you can take a Wi-Fi level packet trace using the instructions in Recording a Wi-Fi Packet Trace - https://developer.apple.com/documentation/network/recording_a_packet_trace/recording_a_wi-fi_packet_trace. This will show you STA-to-AP traffic, AP-to-STA traffic, link-level positive acknowledgement and retransmission, Wi-Fi power management, and so on. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + "@apple.com" Change history: 18 Apr 2016 — First posted. 1 Mar 2019 — Fix a link to QA1176, which is no more. Minor editorial changes. 11 May 2021 — Added the Ad-Hoc Wi-Fi section. Expanded the Terminology section. Minor editorial changes.

This post explains how to investigate network latency problems. It does not necessarily show how to fix the problem, but it describes techniques to find the problem and, from there, contemplate potential fixes. A latency problem in the general case looks like this: sending app receiving app | | libraries libraries | | kernel kernel | | network driver network driver | | +------ network ------+ The problem is that that the sending app sends a packet of data which is not received by the receiving app in a timely fashion. This discussion assumes that the sending and receiving apps are both running on Apple platforms (macOS, iOS, tvOS). If you’re using another platform, you’ll have to ask that platform vendor about equivalent techniques. Note Apple platforms have a user-space networking stack that runs in parallel to the networking stack in the kernel. To simplify this discussion, I’m using the term kernel to encompass both stacks. The first step is to simplify the environment as much as possible. Specifically: Test with Bluetooth off — On iOS devices specifically, Bluetooth and Wi-Fi present unique coexistence challenges. If you’re primarily interested in Wi-Fi, test with Bluetooth off to see if that affects things. Eliminate user space libraries — If you’re using a user space library (something like Multipeer Connectivity) it’s possible, albeit unlikely, that your latency problem is related to that library. The library itself might have a bug, or you might be using it incorrectly. To eliminate this possibility, switch to a low-level API, either BSD Sockets or NWConnection. Disable peer-to-peer networking — Peer-to-peer networking is a common cause of network latency issues on Wi-Fi, so make sure it’s disabled. Peer-to-peer networking is not supported by BSD Sockets, so there’s nothing to do there. If you’re using Network framework, leave the includePeerToPeer property at its default value of false. Also, check other parts of your code to make sure that you haven’t enabled peer-to-peer networking in some other, unrelated place. Switch to UDP — TCP is a complex protocol and it can have a non-obvious impact on latency. If you’re using TCP, switch to UDP. IMPORTANT The steps listed above are part of the investigation, not an end in themselves. You may find that, once you understand the real cause of the latency, you go back to using your user space library, or go back to using TCP. However, run your initial investigation with a BSD Sockets or Network framework UDP program. IMPORTANT Turn off Bluetooth using Settings > Bluetooth. On modern systems turning off Bluetooth in the Control Center does not turn it off completely. The next step is to simplify your network environment. Ideally you’d want to directly connect the two machines, and thus avoid any possibility that network infrastructure is causing the latency. However, if you’re working with iOS, which while it supports Ethernet is not commonly used with it, it’s likely that you’ll need to use at least a Wi-Fi access point (AP). In that case I recommend that you use an Apple AP: an AirPort base station or Time Capsule. These aren’t necessarily better than third party APs — although there are a lot of broken APs out there! — but, by using an Apple AP, you guarantee that any problems you see are the responsibility of one vendor. Note While discussing Wi-Fi I tend to slip into the habit of using low-level Wi-Fi terms, like AP. For an explanation of those, see Wi-Fi Fundamentals. After following the steps above your setup will look something like this. sending app receiving app | | | <-- A | <-- F | | kernel kernel | | | <-- B | <-- E | | Wi-Fi driver Wi-Fi driver | | +------ AirPort ------+ ^ ^ C D From there, you can insert probes into the network path to see where the latency is coming from. Specifically: Add logging to your app to probe points A and F. Use a standard packet trace to probe points B and E. Use receive timestamps to probe point E. In BSD Sockets, set the SO_TIMESTAMP option and access the timestamps by looking at the SCM_TIMESTAMP value returned from recvmsg. In Network framework, set the shouldCalculateReceiveTime property and access the timestamps using the receiveTime property. Use a Wi-Fi level packet trace to probe points C and D. On the Mac, use DTrace to probe between A and B and between E and F. IMPORTANT Use tcpdump on your Mac to record a packet trace. If you’re working on iOS, set up an RVI interface. Both of these are explained in Recording a Packet Trace, but you will also want to look at the tcpdump man page. For instructions on how to record a Wi-Fi level packet trace, see Recording a Wi-Fi Packet Trace. With all of these probes in place you can understand where the packet got delayed. For example: A delay between A and B would be pretty unusual when using UDP, but could be the result of congestion within the kernel’s TCP/IP stack. If there’s a delay between B and C, you know that the sending device is having problems sending, either because of a problem within the Wi-Fi driver or because of a Wi-Fi level problem, for example, link-layer retransmissions. To investigate the latter in more depth, use a Wi-Fi level packet trace. If there’s a delay between C and D, that could be an AP problem, an issue with Wi-Fi QoS, or the receiving Wi-Fi driver entering low-power mode. Again, the Wi-Fi level packet trace will help you understand this. A delay between D and E is most likely caused by the receiving Wi-Fi driver but there could be other causes as well, like link-layer retransmission. A delay between E and F could be caused by a bug in the kernel, congestion within the TCP/IP stack, or a thread scheduling problem within your app. In the last case, use the System Trace instrument to investigate thread scheduling delays. Once you understand the cause of your latency, you can then think about how to reduce it. This might be something you can do yourself. For example, you might uncover a thread scheduling bug in your app. OTOH, the fix might be something that only Apple can do. For example, this might be a bug in the Wi-Fi driver and so all you can do is report that bug. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2022-01-25 — Added a discussion of peer-to-peer Wi-Fi. Mentioned Network framework as an alternative to BSD Sockets. Added a note about the user-space networking stack. Made other editorial changes. 2021-02-27 Fixed the formatting. Made minor editorial changes. 2019-03-01 Fixed some links now that QA1176 has been retired. 2018-09-11 Added a description of how to really turn off Bluetooth, along with some minor editoral changes. 2016-01-19 Made more editorial changes. 2015-10-09 Made minor editoral changes. 2015-04-03 Added a section about turning off Bluetooth.

In some cases the user connects to a WiFi network that doesn't have internet access. The OS itself is able to display a warning in System Settings: However, in my app NWPathMonitor reports that the WiFi path is satisfied. How could I detect that the internet access is not working while WiFi is connected? I could try to connect to my own servers and report failures to the user, but that takes a long time to receive the timeout error. I cannot reduce the timeout, because maybe the user is on a very slow network and long loading time might be expected. But iOS can detect that there is not internet within a few seconds and display a warning, so I wonder how does Apple implement it in System Settings and if there is something I can implement in my app.

I have a pretty simply macOS application which I've just been trying to fix since a long time ago. It's origin is really old, using the apple 802.11 framework located in /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Apple80211 and it's supposed to just scan the area and display information about the local networks nearby. For some reason when I run the application and press the button to scan for local networks (wifi scan) It errors out and in the Xcode console I get Process WiFiInfo is missing entitlement required for Wi-Fi user-client access: &amp;lt;key&amp;gt;com.apple.private.driverkit.driver-access&amp;lt;/key&amp;gt; &amp;lt;string&amp;gt;com.apple.private.wifi.driverkit&amp;lt;/string&amp;gt; If I add those two lines to the entitlements, Xcode fails to sign my application and fails to build and run Provisioning profile "Mac Team Provisioning Profile: com.troger.WiFiInfo" doesn't include the com.apple.private.driverkit.driver-access entitlement. Any way I can fix this? I would really like to get this application back up to its running state as it once was before but am completely lost on how to fix this

I have a Python script that returns a scan result with scanForNetworksWithName using CoreWLAN with PyObjC. It provides info on ssid and such like the airport command. When upgrading to MacOS 14.4 however SSID is now Null. I read this was due to changes in permissions and location services needed to be enabled. I have enabled access to location services and I am able to use CoreLocation to get a location however I still do now see the SSID. Here is my script, that does both location and scan: import CoreWLAN import CoreLocation from time import sleep import re wifi_interface = CoreWLAN.CWInterface.interface() networks, error = wifi_interface.scanForNetworksWithName_error_(None, None) location_manager = CoreLocation.CLLocationManager.alloc().init() location_manager.startUpdatingLocation() max_wait = 60 # Get the current authorization status for Python for i in range(1, max_wait): authorization_status = location_manager.authorizationStatus() if authorization_status == 3 or authorization_status == 4: print("Python has been authorized for location services") break if i == max_wait-1: exit("Unable to obtain authorization, exiting") sleep(1) coord = location_manager.location().coordinate() lat, lon = coord.latitude, coord.longitude print("Your location is %f, %f" % (lat, lon)) print(f"{'SSID' : >32} {'BSSID' : <17} RSSI CHANNEL HT CC SECURITY") for i in networks: print(f"{'SSID' : >32} {'BSSID' : <17} RSSI CHANNEL HT CC SECURITY") for i in networks: print(f"{i.ssid() or '' : >32} {i.bssid() or '' : <17} {i.rssiValue() : <4} {i.channel() : <6}") It worked fine in MacOS 13.6 but with MacOS 14.4 I have the null SSID issue. We went through something similar with MacOS 10.15 where BSSID became Null. At the time I couldn't find a workaround, but sometime around MacOS 13.x I was able to generate the request for location services. After granting the request I was able to see BSSID again. It seems like we have a similar bug to this again. Thread about the BSSID issue: https://github.com/ronaldoussoren/pyobjc/issues/484

With the deprecation of the airport binary in macOS 14.4 I am re-writing my own network tool to directly use CoreWLAN. In doing this and testing and comparing to previous results from the Apple airport binary under various versions of macOS I believe CoreWLAN has a 'bug' which as a result was exhibited in the Apple airport binary and equally my own code. As detailed below. This applies to the release version of macOS 14.4 (23E214) macOS Sonoma 14.3.1 and previous versions of macOS going back many, many years have included an official Apple binary at the following location. /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport Whilst this is now officially deprecated in macOS 14.4 it is obvious that this tool will have itself been utilising the official Apple framework CoreWLAN. As part of the process of re-writing my own tool which formerly used the above Apple binary, I have re-written my tool to directly utilise CoreWLAN myself via the Objc interface. In doing this I have been able to in my own tool reproduce an incorrect behaviour formerly exhibited by the airport binary and still exhibited with my own tool directly utilising CoreWLAN. It therefore appears the issue is in CoreWLAN and not the now deprecated airport binary. Using the airport binary in macOS 14.3.1 (the last working version) I get a result like the following. SSID BSSID RSSI CHANNEL HT CC SECURITY (auth/unicast/group) vodafone20645C -89 6 Y -- RSN(PSK/AES/AES) vodafone20645C -89 60 Y -- RSN(PSK/AES/AES) You can see the column for CC which stands for country code is empty and hence shows ‘--‘. This field should indicate the country the WiFi access point is configured to support. (This affects the available choices of WiFi channels, transmitter strength and other aspects in order to render the access point LEGAL to use in various countries.) Using my own code under the same version of macOS written to directly call CoreWLAN and obtain the same information I get the same results i.e. CoreWLAN does not return any country code information. My code under both macOS 14.3.1 and 14.4 returns the same results i.e. no country code. As a comparison here is the output from the airport binary included in macOS 12.7.4 (21H1123) SSID BSSID RSSI CHANNEL HT CC SECURITY (auth/unicast/group) vodafone20645C -89 6 Y -- RSN(PSK/AES/AES) vodafone20645C -89 60 Y -- RSN(PSK/AES/AES) As you can see it is identical confirming this bug has existed for a long time. To show this however DID NOT USE TO EXIST here is the result from a much older macOS X Yosemite 10.10.5 (14F2511) SSID BSSID RSSI CHANNEL HT CC SECURITY (auth/unicast/group) VM2833142 cc:58:30:07:32:48 -88 108 Y NL WPA2(PSK/AES/AES) EE WiFi 62:e5:32:e3:ab:35 -61 11 Y GB NONE EV home 78:85:f4:42:02:58 -57 11 Y CN WPA2(PSK/AES/AES) SKYGW3RD 3c:45:7a:fe:6b:0a -63 11 Y -- WPA2(PSK/AES/AES) BT-6FCW7K c4:e5:32:e3:ab:34 -61 11 Y GB WPA2(PSK/AES/AES) As you can see in this case it is listing access points that are set to respectively, Netherlands, Great Britain, China, ‘Unknown’, and Great Britain. (As an aside and not part of this bug I am reporting, CoreWLAN has not reported the BSSID aka MAC address for some time either.) Note: The countryCode field is still defined in CoreWLAN as retrieving it does not generate an error unlike picking a non-existent field name. See also - https://developer.apple.com/documentation/corewlan/cwinterface/countrycode()

TL;DR What's the replacement via CLI, programmatically, &| reliable AppleScript-fu. Scenario Auto-switching between Ethernet adapters (i.e., built-in MAC official/unofficial Ethernet adapters, third-party 10 GbE USB-C), and Wi-Fi. Problem Standard operation in post-Network Location macOS leads to assigning multiple IP addresses, causing havoc with applications and network services. Disabling Wi-Fi manually is non-starter. Goal Disassociate from Wi-Fi programmatically or from the CLI without powering off Wi-Fi to retain Wi-Fi PAN services such as AirDrop and AirPlay. (Previous) Solution Calls airport -z when needed to disassociate. Re-associate with other magic tools when Ethernet becomes unreachable. It worked reliably for over a year. Invocation sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -z Expected (previous) behavior Wi-Fi disassociates but remains powered on Actual behavior Output WARNING: The airport command line tool is deprecated and will be removed in a future release. For diagnosing Wi-Fi related issues, use the Wireless Diagnostics app or wdutil command line tool. (nothing happens) Platform 14.4 (23E214) m1/arm64

Our company's application is aimed at lot applications. When configuring device networking, we want users to select a certain WiFi information in the WiFi list. When we apply for a WiFi list, Apple asks us what protocol to choose and how to choose it? Our application's communication is done through HTTPS.

It was possible to excute: sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s on previous mac os version to get all SSID list. But now on mac os 14.4 it returns like: WARNING: The airport command line tool is deprecated and will be removed in a future release. For diagnosing Wi-Fi related issues, use the Wireless Diagnostics app or wdutil command line tool. Is there any other way to list all SSIDs? It's important to me since my code depends on this feature. P.S. Seems other airport command like "airport -I" didn't work too. Is there any other tool could replace airport?

Hi, I am trying to get a list of available WiFi networks for a sandboxed macOS app: CWInterface *wifi = [[CWWiFiClient sharedWiFiClient] interface]; NSError *err; NSSet *scanset = [wifi scanForNetworksWithSSID:nil error:&err]; // scanset is always empty (but not nil), no error is writting to "err" With macOS Sonoma the code always returns an empty list (with older macOS version it works fine). I already added Location permission (as described here: https://developer.apple.com/forums/thread/732431). Getting the currently connected WiFi SSID (using [CWInterface interface].ssid), as well as connecting to a WiFi network works. How can I get a list of available WiFi SSIDs in macOS Sonoma? Regards,

Hello Experts, After updating to Mac OS sonoma, I am not able to get SSID info and going through already issue, I can see that on update location access is mandatory to get SSID info from API - scanForNetworksWithName:includeHidden:error: Now my application is already able to get latitude and longitude info, but when I call API mentioned above, it gives nil in ssid name field. Questions - Is there any known issue? Is there any other better way to get CWNetwork object so that I can use it directly instead of scanning and then connecting? Note - I have created app package, but application has no GUI. Application is also combination of Golang and Objective-C

Hi Quinn, I have a macOS App (SwiftUI) which scans for available WifiNetworks using CWWiFiClient.shared().interface().scanForNetworks(withSSID: nil) The app is sandboxed and has "Outgoing Connections" (Client) checked. The app is Launched via a "LaunchAgents". During app init() I kickoff the scanForNetworks in a background thread. I do receive WifiNetworks but when I look at the SSID quite often all of the SSIDs are nil. If I loop the scanForNetworks() a few times with a delay of 1 second after a few tries the SSIDs will no longer be nil. Any idea why this happens? Should I file a bug report or is that expected behavior Thanks very much, Martin (your old friend from Germany)

In the context of a system utility that reports OS stats periodically, the security type for a connected WiFi network could be obtained with Core WLAN via CWInterface.security. This used to work up to Ventur; howver, after upgrading to Sonoma, cwInterface.security now returns kCWSecurityUnknown. In other posts, I have read about changes in how Core WLAN works which are related to Sonoma. How can I determine the security type for a connected WiFi network on Sonoma? It would be preferable if the suggested approach would also work on previous macOS versions as well. Many thanks in advance! :-)

Hi, Question: Is there a way to detect Captive network and show the UI to authenticate to it from within a third party app/plugin on macOS? I tried using URLSession to detect the presence of captive portal by loading the detection URL http://captive.apple.com/hotspot-detect.html but the task fails with no internet connection error without the delegate getting any calls about redirect or auth challenge. Same behavior with WKWebView when I try to load the detection URL, the provisional navigation simply fails with no internet connection error. Context: I'm building an Auth plugin to do something before users log in to their mac and it requires internet connectivity. I wanted to let the users connect to a wifi network if they aren't already connected. I got connecting to regular networks working but not the captive networks.

Hello! Is it possible to add location permissions to a macOS system extension? We have a network firewall system extension that also considers WIFI connections in its rules. With the release of Sonoma, interface information is only accessible while having location permissions, which we are having trouble asking for. We have the entitlements, the usage description, but the authorizationStatus of CLLocationManager stays at .notDetermined and no window for location permission pops up after calling requestAlwaysAuthorization(). What we need is to get the SSID of the network that the interface is connected, its security and encryption type. If the permission is not possible, is there a workaround? Cheers

After the upgrade of Sonoma 14.0 (23A344), after the 802.1x connection is successful, the system will send logoff and then fail. It is normal before the upgrade, but after the upgrade of the system. How can I view more detailed information? I'm sure it's an update to Sonoma 14.0 (23A344), which has been tested on multiple machines. Please help me！

Hi Team, I have been recently working on MacOS native application which interactes with Native API's to fetch SSID but recently this below mentioned API is returning nil as response on Sonoma OS Version. Below is the Objective - C for code reference CWWiFiClient *client = [CWWiFiClient sharedWiFiClient]; CWInterface *interface = [client interface]; NSString *ssid = [interface ssid]; I'm referring to following API - https://developer.apple.com/documentation/corewlan/cwwificlient?language=objc And trying to retrieve ssid https://developer.apple.com/documentation/corewlan/cwinterface?language=objc Note : The API is working on MacOS 13.0+ version and this seems to have broken in 14.0+ version Could you please provide us more details on the API issue, or any alternatives that can be followed, because from the documentation the above code seems to be a valid operation and nothing that is deprecated or restricted.

Hi Experts, I am working on a application where I am calling Objective-C Core WLAN API from golang with below code, darwin_lib.m void ConnectWiFi(char * cInterfacename, char * cSSID, char * cSecurity, char *cSubsecurity, char * cPassphrase, char * cOnexuser, char * cOnexpass) { @autoreleasepool { NSString * interfacename = [[NSString alloc] initWithUTF8String:cInterfacename]; NSString * ssid = [[NSString alloc] initWithUTF8String:cSSID]; NSString * security = [[NSString alloc] initWithUTF8String:cSecurity]; NSString * subsecurity = [[NSString alloc] initWithUTF8String:cSubsecurity]; NSString * passphrase = [[NSString alloc] initWithUTF8String:cPassphrase]; NSString * onexuser = [[NSString alloc] initWithUTF8String:cOnexuser]; NSString * onexpass = [[NSString alloc] initWithUTF8String:cOnexpass]; NSError * connecterr = nil; CWWiFiClient * cwwificlient = [CWWiFiClient sharedWiFiClient]; CWInterface *a = [cwwificlient interfaceWithName:interfacename]; NSSet<CWNetwork *> * network = [a scanForNetworksWithName:ssid error:&connecterr]; **** some more code ***** BOOL result = [a associateToEnterpriseNetwork:network.anyObject identity:nil username:onexuser password:onexpass error:&connecterr]; main.go package main // #cgo CFLAGS: -x objective-c // #cgo LDFLAGS: -framework CoreWLAN // #cgo LDFLAGS: -framework Foundation // #include "clib.h" import "C" import "fmt" func main() { var status C.int = C.ConnectWiFi() time.Sleep(20) *** some more code and long running process *** } Now what I am trying to understand here from memory release point of view is, Is object created in C code will be freed once I reach time.Sleep(20) e.g cwwificlient a spcifically to Core WLAN side or do I have to call release specifically on object? I tried calling release on cwwificlient and program is crashing on second execution, not sure why it would crash on only second execution, why not first time itself? I tried calling release on a and program is not crashing. Do I have to free all the Core WLAN related object myself or autoreleasepool will take care of it? As whole code is inside autoreleasepool, will all the objects be released on it's own even though function is being called from go code? As go's garbage collector has no idea how many objects C code created so go's garbage collector won't be of any help here Is autoreleasepool, can also take care of releasing any alloc object e.g ssid created inside C code ?

Hello Experts, I am trying to connect Mac Pro through command line utility using Mac OS API. I am successfully able to connect client though when network goes down and comes up again, on GUI dialog is again asking for username and password even though it was connected earlier. So I tried to use helper method CWKeychainSetWiFiEAPUsernameAndPassword but unfortunately it is giving error code -108 Error: 0xFFFFFF94 -108 Failed to allocate memory. My little code snippet looks as below, BOOL result = [a associateToEnterpriseNetwork:network.anyObject identity:nil username:onexuser password:onexpass error:&amp;connecterr]; NSLog(@"Association Result: %d", result); NSLog(@"Error: %@", connecterr); NSData *nssid = [network.anyObject ssidData]; CWKeychainDomain d = kCWKeychainDomainUser; OSStatus er = CWKeychainSetWiFiEAPUsernameAndPassword(kCWKeychainDomainUser, nssid, onexuser, onexpass); NSLog(@"Status: %d", er); Now I am not sure what could be the cause of error? Any pointers would be appreciated.

FB12755685 Sent a feedback through feedback assistant and wanted to elaborate more over here. Our application configures and connects to wireless networks using CoreWLAN. We started seeing crashes while connecting with the latest Beta versions of Sonoma. The crashes showed EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) which led me to believe it might be a CPU architecture issue due to the mention of i386 but that was completely wrong. Turns out the error is due to: *** CFRetain() called with NULL *** CFRetain.cold.1 [CWInterface associateToEnterpriseNetwork:identity:username:password:error:] + 127 Sample code to consistently reproduce the crash on Sonoma CWInterface* interface = [CWInterface interfaceWithName:@“en0”]; NSError *scanError = nil; NSSet* testNetworks = [interface scanForNetworksWithName:@“SSIDName” error:&amp;testScanError]; CWNetwork* network = [testNetworks anyObject]; NSError* connectionError = nil; BOOL connected = [interface associateToEnterpriseNetwork:network identity:identityRef username:nil password:nil error:&amp;connectionError]; //&lt;--crash here The associateToEnterpriseNetwork function expects a CWNetwork object. In the Beta versions of macOS Sonoma, the CWNetwork object has (null) values in the ssid field. This causes a cold CFRetain runtime error when trying to associate to the network. If we can detect a broadcasting "SSIDName" SSID and try to associate to it, we will always crash on the last line. The reason for the crash seems to be due to a difference in how the CWNetwork objects are handled in Sonoma. Sonoma: &lt;CWNetwork: 0x6000036cb590&gt; [ssid=(null), bssid=(null), security=WPA2 Enterprise, rssi=-53, channel=&lt;CWChannel: 0x6000036fce90&gt; [channelNumber=1(2GHz), channelWidth={20MHz}], ibss=0] Ventura: &lt;CWNetwork: 0x6000010ffa60&gt; [ssid=Chris640, bssid=(null), security=WPA2 Enterprise, rssi=-45, channel=&lt;CWChannel: 0x6000010ffca0&gt; [channelNumber=1(2GHz), channelWidth={20MHz}], ibss=0] Is my assumption that the crash is due to the (null) in the SSID field correct?

I've had a little personal utility running for several versions of macOS that uses let client = CWWiFiClient.shared() if let ssid_name = client.interface()?.ssid() to get the current SSID name and prints it (along with a bunch of other active network details. With the most recent Sonoma Beta 2 and Xcode beta 2, this always returns nil. Doing the same thing in a playground works as expected. Is this a purposeful change or a bug I should file?