I am trying to correctly manage about 20 Mac, iPhones and PC inside a Wi-Fi network built through System Settings > Sharing > Internet Sharing To achieve this task I defined a complete configuration file: /etc/bootpd.plist which is used by /usr/libexec/InternetSharing. But every time /usr/libexec/InternetSharing is starting the file /etc/bootpd.plist is overwritten by another file and my configuration is thus fully lost. How to set a correct /etc/bootps.plist file and avoid its total overwrite by /usr/libexec/InternetSharing? Is it necessary to write this bootpd.plist in some other directory for /usr/libexec/InternetSharing to load it without destroying it? I got the same configuration total erase on macOS Big Sur and Sequoia.

I have an swift command line tool that changes proxy settings in system preferences via SystemConfiguration framework, does some stuff, and in the end reverts proxy settings back to original. Here is simplified code: var authorization: AuthorizationRef? let status = AuthorizationCreate(nil, nil, [], &authorization) let prefs = SCPreferencesCreateWithAuthorization(nil, "myapp" as CFString, nil, authorization) // change proxy setttings // do some stuff let prefs2 = SCPreferencesCreateWithAuthorization(nil, "myapp" as CFString, nil, authorization) // change proxy settings back to original When I try to change settings for the first time, the system dialog appears requesting permission to change network settings. If I try to change settings again within а short period of time, the dialog does not appear again. However, if it takes more than several minutes after first change, the dialog does appear again. Is there a way to create authorization, so that the dialog appears only once per app launch, no matter how much time passed since the first dialog?

Around 8/23/25, I installed macOS 15.6.1 on my work Mac. After this I can no longer log the application I am working on into our backend servers. My work Mac is running Palo Alto Global Protect VPN software along with a bunch of associated security software to lock down my computer. I had no issues with connecting to our backend servers behind the firewall before the macOS update and nothing has changed in the source code related to this. When I send the username the network call just hangs and never times out. On the other hand, if I turn off the VPN and point to the production environment the call succeeds with no problems. Any Ideas?

Hi everyone, I’m running a dual-homed IPv6-mostly LAN where two on-link routers advertise distinct global Provider-Assigned prefixes (one per ISP). On Linux, the host stack appears to follow RFC 8028. It keeps one default route per prefix, and packets appear to leave through a router that recognises their source address and pass ISP BCP 38 (https://datatracker.ietf.org/doc/bcp38/) checks. On macOS Sequoia, I'm only seeing a single un-scoped default route. As a result, traffic sourced from prefix B often exits via router A and is dropped upstream. Questions: Is the single-default-per-interface model in macOS an intentional design choice or simply legacy behaviour that has not yet been updated to RFC 8028? Does the kernel perform any hidden next-hop selection that isn’t reflected in netstat -rn output? Are there any road-map items for fully adopting RFC 8028 in macOS? As a bonus, I'd be very interested in any info you might be able to provide on the status of implementation/support for https://datatracker.ietf.org/doc/html/rfc8978 (Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events).

Recently, we have observed that after upgrading to OS 15.4.1, some devices are experiencing network issues. We are using a Network Extension with a transparent app proxy in our product. The user encounters this issue while using our client, but the issue persists even after stopping the client app. This appears to be an OS issue. Below is the sytem logs. In the system logs, it says [C669.1 Hostname#546597df:443 failed transform (unsatisfied (No network route), flow divert agg: 2)] event: transform:children_failed @0.001s In scutil --dns, it says not reachble. DNS configuration resolver #1 flags : reach : 0x00000000 (Not Reachable) resolver #2 domain : local options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 flags : reach : 0x00000000 (Not Reachable) order : 301000 We need to restart the system to recover from the issue.

Hi, our CourAudio server plugin utilizes the SystemConfiguration.framework to store and restore specific shared system wide settings. While our application can authenticate to utilize the SystemConfiguration.framework to gain write access to the shared configuration settings the CoreAudio server plugin obviously can't have any user interaction and therefor does not authenticate. Is it possible to authenticate the CoreAudio server plugin to gain write permissions? Are there any entitlements or other means that would allow this? Thanks!

When setting up a packet tunnel with a profile that has includeAllNetworks set to true, we seemingly cannot send any traffic inside the tunnel using any kind of an API. We've tried using BSD sockets, as we ping a host only reachable within the tunnel to establish whether we have connectivity - this does not work. When using NWConnection from the Network framework and specifying the required interface via virtualInterface from the packet tunnel, the connection state never reaches ready. Our interim solution is to, as ridiculous as it sounds, include a whole userspace networking stack so we can produce valid TCP packets just to send into our own tunnel. We require a TCP connection within our own tunnel to do some configuration during tunnel setup. Is there no better solution?

I would like to develop a macOS app that would automatically switch Network Locations based on certain criteria. I want to publish this on the Mac App Store, but I'm unsure if this functionality is permitted. I've searched through the App Store Review Guidelines and documentation on NetworkExtension and SystemConfiguration frameworks, but I haven't found clear information on whether: Programmatically changing Network Locations is allowed in sandboxed App Store apps What specific entitlements would be required If there are any API-approved ways to do this without shell commands I'd like to avoid investing significant development time if this type of functionality would ultimately be rejected. As a relatively new Apple platform developer, any guidance on: The appropriate frameworks/APIs to use Required entitlements Whether this functionality is even permitted for App Store distribution would be incredibly helpful. Thank you in advance for any insights!

Hello everyone, I have added a Settings.bundle to my Xcode project, but it does not appear in the iOS app settings. The file is correctly copied into the target, but nothing shows up in the settings. I have already checked and tried several things, but without success. What I've tried so far: Ensuring that Settings.bundle is included in the project: Settings.bundle is listed under Build Phases → Copy Bundle Resources. Checking the structure of Root.plist: The file exists and has the following structure: Checking the structure of Root.plist -it has Checking if the file is included in the app -it is Restarting the simulator and reinstalling the app I reset the simulator and reinstalled the app completely, but the issue persists.

I'm building an app that helps manage my own wifi access points. Now, all my wifis emit SSIDs starting with the same prefix. Is it possible for me to list down all the SSIDs near me that start with that prefix, so that determine which of my wifis are near me? (Swift) Can NEHotspotHelper or NEHotspotConfigurationManager help in this regard?

Hi, I’m working on a case in our organisation where we encounter regular wireless network disconnections - 30 and 60 minutes. ~ 1800 sec session is widely seen across hundreds if not thousand Macbooks. We excluded internal wireless configuration issue and vendor specific problem as the disconnections happen on both Cisco and Ubiquiti Access Points. Wireless Controller debugging most often show EAP timeout error. Sniffer shows that the disassociation is initiated by Macbook. MacOS logs show wifianalyticsd performing some actions before the disconnection (generated with sudo log show --debug [time]): 2025-02-04 14:16:31.219169+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4238:SDNS: WiFi Not Primary - setting suppressedReason kSymptomsDnsWiFiInterfaceNotPrimary 2025-02-04 14:16:31.219192+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateTimeSincePreviousTriggerForStudy:msgKey:dictKey:]::913:msgkey:WFAAWDWASDS_symptomsDnsTimeSincePreviousTriggerMinutes dictKey:dps_lastSymptomsDpsTrigger previous_TS:(null) current_TS:Tue Feb 4 14:16:31 2025 difference:0 2025-02-04 14:16:31.219704+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateScreenState]::198:DPS Fast Reset Recommendation Engine: (screenON & foreGrnd traffic) is DETECTED 2025-02-04 14:16:31.219713+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine recommendSymptomsDpsRecovery:symptomsDnsStats:awdlState:currentSymptomsCondition:isLANPingSuccessful:appUsage:averageCCA:]::966:PeerDiagnostics: Data not received from peerDiagnostics 2025-02-04 14:16:31.219714+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine checkForPriorityNetwork]::256:Priority Network Check Disabled: NO IsPriorityNetwork: YES 2025-02-04 14:16:31.219732+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine isResetAllowedForKey:forPrefSelector:]::330:key:symptomsDps_lastScreenOnRecoveryWD previousWD_TS:(null) currentWD_TS:Tue Feb 4 14:16:31 2025 recommendation:YES 2025-02-04 14:16:31.219735+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateSymptomsDPSRecoveryWDStatsForKey:]::210:Added key: symptomsDps_numRecommendedScreenOnRecoveryWD value:1 dict:(null) 2025-02-04 14:16:31.219737+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine recommendSymptomsDpsRecovery:symptomsDnsStats:awdlState:currentSymptomsCondition:isLANPingSuccessful:appUsage:averageCCA:]::1023:PeerDiagnostics: Recommendation for DNS Symptoms Recovery: Reassoc 2025-02-04 14:16:31.219740+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4276:PeerDiagnostics: Triggering Reassoc for symptoms-dps 2025-02-04 14:16:31.219741+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4277:SDNS: Recommendation - kSymptomsdDPSReassoc, triggering reassoc wiith reason ReassociateOnDNSSymptoms 2025-02-04 14:16:31.220001+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: (IO80211) Apple80211SetWithIOCTL:11858 Processing APPLE80211_IOC_REASSOCIATE_WITH_CORECAPTURE 2025-02-04 14:16:31.387985+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: (IO80211) Apple80211SetWithIOCTL: Processed APPLE80211_IOC_REASSOCIATE_WITH_CORECAPTURE Ioctl error:0 WAEngine and DPSQuickRecoveryRecommendationEngine functionalities (?) play significant role in here recommending Reassociation We can see that reassociation is being triggered because of DNS symptoms - why and where can I find them?
Recommendation for DNS Symptoms Recovery: Reassoc