I'm working on two Swift applications which are using QUIC in Network.framework for communication, one serve as the listener (server) and the other serve as the client so that they can exchange data, both the server and the client app are running under the same LAN, the problem I met is that when client try to connect to the server, the connection will fail due to boring SSL, couple questions: Since both the server app and client app are running under the same LAN, do they need TLS certificate? If it does, will self-signed certificate P12 work? I might distribute the app in App Store or in signed/notarized dmg or pkg to our users. If I need a public certificate and self signed wouldn't work, since they are just pair of apps w/o fixed dns domain etc, Is there any public certificate only for standalone application, not for the fixed web domain?

HI, I am currently prototyping an app that compares transport protocol performances using a peer to peer connection. I have already setup TCP and UDP connections and am sending data between the clients, it works like I want it to. Next I was trying to setup a connection using QUIC, but the NWConnection.State stays in the preparing state and I couldn't find a way to get more information from the framework or the instances about why it was not fully connecting. After searching the internet and stumbling across the forum I noticed that the missing encryption might be the issue, so I created a local root certificate*. Then I used the SecPKCS12Import function to read/extract the SecIdentity instance of the p12 file (cert + private key) stored in my bundle** and set it as a local identity with the sec_protocol_options_set_local_identity function***. //function that creates/returns different NWParameteres //... let quicOptions = NWProtocolQUIC.Options() quicOptions.alpn = ["test"] if let identityPath = Bundle.main.path(forResource: "QUICConnect", ofType: "p12"), let identityData = try? Data(contentsOf: URL(fileURLWithPath: identityPath)) { if let identity = loadIdentityFromPKCS12(p12Path: identityPath, password: "insecure") { //**** sec_protocol_options_set_local_identity(quicOptions.securityProtocolOptions, sec_identity_create(identity)!) } } let parameters = NWParameters(quic: quicOptions) parameters.includePeerToPeer = true return parameter The documentation comments had me thinking that setting a local identity could be enough, since it consists of the private key for the "server" and the cert for the "client". Set the local identity to be used for this protocol instance. Unfortunately at this stage the QUIC Connection is still stuck in preparing state and since I don't know how to extract more information from the networking connection instances/framework, I am stuck. I have seen the following other functions in Quinns answer and am confident that I could somehow figure it out with some more time put into it, but not really understanding why or how I could do it better in the future. So I am also wondering how I could have found info about this more efficiently and tackled this more strategically without needing to browse through so many forums. sec_protocol_options_set_verify_block sec_protocol_options_set_challenge_block I would really appreciate any help, many thanks. BR Matthias! TLDR: I want to establish a peer to peer QUIC Connection but the state is stuck in preparing. Secondary question is how I could approach a similar topic more efficiently next time, instead of browsing many forums. * I had to create it with the openssl CLI since the keychain app created a cert, that when using the openssl CLI to get the info would throw an error unless used with the -legacy flag. The root cert, created form the keychain app also wasn't able to be imported by the SecPKCS12Import function. No clue why but it worked with a cert created from the openssl CLI. There's a chance that I messed up something else here, but these were my experiences. Info: Since QUIC is limited to TLS v1.3 I can't use PSK, afaik. Therefore the TicTacToe doesn't help me anymore. ** I know this is highly insecure, I am just using it for prototyping. *** Forum users Info: One needs to use the sec_identity_create function to convert the SecIdentity instance to the expected parameter type. **** func loadIdentityFromPKCS12(p12Path: String, password: String) -> SecIdentity? { guard let p12Data = try? Data(contentsOf: URL(fileURLWithPath: p12Path)) else { print("didnt find p12 file at path") return nil } let options: NSDictionary = [kSecImportExportPassphrase as String: password, kSecImportToMemoryOnly as String: kCFBooleanTrue!] var items: CFArray? let status = SecPKCS12Import(p12Data as CFData, options, &items) if status == 0, let dict = (items as? [[String: Any]])?.first { if let identity = dict[kSecImportItemIdentity as String] { return identity as! SecIdentity } else { return nil } } else { return nil } } PS: For TCP and UDP I am using bonjour to discover the peer and connect to the advertised ports. AFAIK I can't just use _testproto._quic to advertise a QUIC service like with tcp and udp. Therefore I am using the local domain name (it's just for prototyping and always the same device) and a hard coded port number to create the peer connection. When using a wrong name the DNS threw an error telling it could not find a peer, so the lookup itself is working I guess. The lookup should come from the cache since I already looked up when connecting to the same peer via Bonjour. //Server //.... listener = try NWListener( using: transportProtocol.parameters, on: Config.quicPort ) //... listener.newConnectionHandler = { [weak self] connection in self?.connection?.cancel() self?.connection = nil self?.connection = C(connection) //here C is a generic that conforms to a custom connection interface, nothing to worry about :) self?.connectionStatus.value = "Connection established" } listener.stateUpdateHandler = { [weak self] state in self?.connectionStatus.value = "\(state)" } listener.start(queue: .global()) //Client //... nwConnection = NWConnection(host: "iPad.local.", port: Config.quicPort, using: transportProtocol.parameters) //...

I'm running a Node.js server on my MacBook with Apple M4 Pro chip, macOS Sequoia 15.4, and Node.js v23.10.0. The server starts normally on port 5000 and logs show that it's listening correctly. However, when I try to access it via browser or Postman (http://localhost:5000/api/...), I get a 403 Forbidden error. After checking with lsof -i :5000, I noticed that the ControlCenter process is listening on port 5000 under the name commplex-main. Interestingly, this doesn't happen on M3 Pro machines. On those devices, Node.js runs fine on port 5000 and can be accessed from Postman and browsers. Is port 5000 now internally reserved by macOS or used by some system-level service in Sequoia or Apple Silicon (M4 Pro)? Should I avoid using this port going forward? Any official clarification would be appreciated.

Hi there! We are working on our SkyElectric App which is being developed in Flutter framework, where we need user to connect with the Wifi of the the inverter. We are trying to direct user to WiFi Settings page of the iOS in general settings where all the available WiFi Networks are listed but unfortunately user is being directed to App's Settings page. We are using package of app_settings and launcher. I've read that Apple changed a policy in 2019 where it restricts Apps to navigate to OS pages. Question: Could you please verify if I APPLE allows us to access the General Settings or WiFi Settings through clicking a button in our App name "Open WiFi Settings", If not then Why?

Feedback Ticket: FB13812251 Problem Statement: We are currently facing internet connectivity issue with our VPN application where we try to disconnect the VPN from the Packet Tunnel Network Extension using - (void)cancelTunnelWithError:(nullable NSError *)error. Which API to use to disconnect the VPN from Packet Tunnel as VPN app is not running such that device retains its internet connectivity as soon as VPN disconnects. Configuration: We have configured PacketTunnelProvider with the following settings: (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.includeAllNetworks = YES; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.excludeLocalNetworks = NO; (NETunnelProviderManager *)tunnelProvider.protocolConfiguration.enforceRoutes = NO; These settings are applied from the VPN app and allow us to successfully establish a VPN connection, with all traffic being routed through the tunnel as expected.We are setting above properties to address local net attack. Issue we are facing: However, we encounter a problem when we attempt to disconnect the VPN from. When we call the following method from PacketTunnel network extension: (void)cancelTunnelWithError:(nullable NSError *)error Upon calling this method, the VPN disconnects as expected, but the device loses all internet connectivity and is unable to access any resources. This is not the desired behavior. Observation : Interestingly, when we call the following method from the app side. The VPN disconnects and the device retains its internet connectivity. [enabledConfig.connection stopVPNTunnel]; We would like to achieve the same behavior when disconnecting the VPN from the Network Extension. So we are looking for an API that could be called from NE without causing any internet connectivity issue. Any guidance on how to resolve this issue would be greatly appreciated.

I have some concerns related to shortening the lifetime of certificates, as per https://support.apple.com/en-gb/102028 Does this apply to Private CA root certificates? And if yes: does it apply if I use ATS and higher level API like URLSession does it apply it I carry my root CA cert in my app payload and use low level libraries without ATS support?

I'm simply trying to use a proxy to route a http request in Swift. I've tried using a URLSession Delegate but that results in the same issue with the iOS menu. proxy format: host:port:username:password When I run the code below I am prompted with a menu to add credentials for the proxy. I closed this menu inside my app and tried the function below again and it worked without giving me the menu a second time. However even though the function works without throwing any errors, it does NOT use the proxies to route the request. I've spent days on this and the only solution I found was using a NWConnection but this is super low level and now I need a shared session to manage cookies. If you want to see the NWConnection solution I made its here func averageProxyGroupSpeed(proxies: [String], completion: @escaping (Int, String) -> Void) { let numProxies = proxies.count if numProxies == 0 { completion(0, "No proxies") return } var totalTime: Int64 = 0 var successCount = 0 let group = DispatchGroup() let queue = DispatchQueue(label: "proxyQueue", attributes: .concurrent) let lock = NSLock() let shuffledProxies = proxies.shuffled() let selectedProxies = Array(shuffledProxies.prefix(25)) for proxy in selectedProxies { group.enter() queue.async { let proxyDetails = proxy.split(separator: ":").map(String.init) guard proxyDetails.count == 4, let port = Int(proxyDetails[1]), let url = URL(string: "http://httpbin.org/get") else { completion(0, "Invalid proxy format") group.leave() return } var request = URLRequest(url: url) request.timeoutInterval = 15 let configuration = URLSessionConfiguration.default configuration.connectionProxyDictionary = [ AnyHashable("HTTPEnable"): true, AnyHashable("HTTPProxy"): proxyDetails[0], AnyHashable("HTTPPort"): port, AnyHashable("HTTPSEnable"): false, AnyHashable("HTTPUser"): proxyDetails[2], AnyHashable("HTTPPassword"): proxyDetails[3] ] let session = URLSession(configuration: configuration) let start = Date() let task = session.dataTask(with: request) { _, _, error in defer { group.leave() } if let error = error { print("Error: \(error.localizedDescription)") } else { let duration = Date().timeIntervalSince(start) * 1000 lock.lock() totalTime += Int64(duration) successCount += 1 lock.unlock() } } task.resume() } } group.notify(queue: DispatchQueue.main) { if successCount == 0 { completion(0, "Proxies Failed") } else { let averageTime = Int(Double(totalTime) / Double(successCount)) completion(averageTime, "") } } } Delegate example class ProxySessionDelegate: NSObject, URLSessionDelegate { let username: String let password: String init(username: String, password: String) { self.username = username self.password = password } func urlSession(_ session: URLSession, task: URLSessionTask, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { if challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodHTTPBasic { let credential = URLCredential(user: self.username, password: self.password, persistence: .forSession) completionHandler(.useCredential, credential) } else { completionHandler(.performDefaultHandling, nil) } } }

When our content filter is deployed, some customers report issues which show that the content filter activation was performed but the filter is showing the state [activated waiting for user]. This typically happens if the customer isn't deploying a profile to pre-authorise the system extension. The customers report that there was no popup shown for them to allow the filter to complete activation. Once the filter is in this state, there doesn't seem to be a way to clear it without resorting to disabling SIP. Attempting a deactivation does not work, the filter remains in the same state. Is there a way we can we resolve this "stuck" state when it happens without disabling SIP?

I am looking for a lightweight server that can run inside an app. The key requirement is that it must support local IP communication over HTTPS. I have searched Google and found several frameworks, but as far as I know, support for HTTPS in this environment has been discontinued or is no longer available. If anyone knows a solution that meets these criteria, I would greatly appreciate your guidance. Thank you in advance!😀

I am trying to commission an ESP32-H2 Matter device using the chip-tool. It's running the Light Switch sample. I can commissioning it using the iOS Home App, so I know the code on it's working okay. I would like to understand more about the Fabric process, so I'd like to use the Home Pod powered Thread network rather than setting up an instance of Open Thread Border Router. I have created a simple iOS app and can fetch the activeOperationalDataSet from the Preferred network using func obtainPreferredNetworkCredentials() async -> (Void) { let client = THClient() let bIsPreferredAvailable = await client.isPreferredAvailable() if bIsPreferredAvailable == true { var credential: THCredentials? do { credential = try await client.preferredCredentials() if let dataset = credential?.activeOperationalDataSet { print(dataset.hexDescription) } } catch { print("Failed to get the credentials") } } } The hexDescription comes from this extension extension Data { var hexDescription: String { return reduce("") {$0 + String(format: "%02x", $1)} } } I am decoding the Data and displaying it as a hex string. It looks something like this: 0e080000000000000000000300001935060004001fffc002089f651677026f48070708fd9f65167702000ee90914b5d1097de9bb0818dc94690c0402a0f7f8 However, when I attempt to commission the device, it fails during ThreadSetup. Googling the issue says most likely the Operational Dataset is wrong in some way. Before I spend too much time on this, I want to make sure I'm doing the right thing in terms of getting the Operational Dataset to use with the chip-tool. Any help is appreciated!

Hi, I am working on a case in our organisation where hundreds if not a thousand wireless network clients are affected by regular, usually 30 sometimes 60 minute sometime they are unnoticeable but often people having meetings notice that a lot. We excluded wireless network configuration issue since disconnections happens to clients both connected to Cisco and Ubiquiti Access Points. WLC logs mostly show EAP timeout errors - clients are getting disauthenticated and authenticated back - usually without any action needed - but the meeting is being interrupted. What I found in Macbook logs with sudo log show [options] is the main reason of network disconnection: 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 Do you guys have any idea where can I see that DNS symptoms? I can also see some reading like: 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::4235:DNS Symptoms pre-decision check:: Associated:YES Primary:YES isCaptive:NO isValidDnsConfig:YES 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 WiFi Not Primary - how if this is my only interface? - I removed all other Killing and disabling wifianalyticsd does not help - the process is being spawned by launchd on airportd request: 2025-02-04 08:54:11.903825+0100 0xb85274 Default 0x0 627 0 airportd: (WiFiAnalytics) [com.apple.wifi.analytics:Default] -[WAClient _establishDaemonConnection]_block_invoke::1057:XPC: establishing connection to daemon with token ending in: <private>... 2025-02-04 08:54:11.907779+0100 0xb8504a Default 0x0 627 0 airportd: (IO80211) [com.apple.WiFiManager:] Info: <airport[627]> -[dpsManager submitDpsSymptom:isCriticalApp:]_block_invoke: 2025-02-04 08:54:11.907943+0100 0xb8504a Default 0x0 627 0 airportd: (IO80211) -[dpsManager submitDpsSymptom:isCriticalApp:]_block_invoke: Error preparing DPSNotification for submission: Error Domain=com.apple.wifi.analytics.errordomain Code=9014 "WAErrorCodeDaemonContactTimeout" UserInfo={NSLocalizedFailureReason=WAErrorCodeDaemonContactTimeout}, or null WAMessageAWD 2025-02-04 08:54:11.908055+0100 0xb8504a Default 0x0 627 0 airportd: (IO80211) [com.apple.WiFiManager:] <airport[627]> -[dpsManager submitDpsSymptom:isCriticalApp:]_block_invoke: Error preparing DPSNotification for submission: Error Domain=com.apple.wifi.analytics.errordomain Code=9014 "WAErrorCodeDaemonContactTimeout" UserInfo={NSLocalizedFailureReason=WAErrorCodeDaemonContactTimeout}, or null WAMessageAWD 2025-02-04 08:54:11.910453+0100 0xb85274 Default 0x0 627 0 airportd: (libxpc.dylib) [com.apple.xpc:connection] [0x80fe64640] activating connection: mach=true listener=false peer=false name=com.apple.wifianalyticsd 2025-02-04 08:54:11.911105+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] internal event: WILL_SPAWN, code = 0 2025-02-04 08:54:11.911229+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] service state: spawn scheduled 2025-02-04 08:54:11.911233+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] service state: spawning 2025-02-04 08:54:11.911384+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd:] launching: ipc (mach) 2025-02-04 08:54:11.920272+0100 0xb85382 Default 0x0 1 0 launchd: [system/com.apple.wifianalyticsd [86459]:] xpcproxy spawned with pid 86459 Do you guys have any idea what is the cause of this behaviour? Or how to disable wifianalyticsd process for good?

I have an NEPacketTunnelProvider that's configured using NEPacketTunnelNetworkSettings. I'm using NEDNSSettings to configure the DNS resolver of the packet tunnel, and would like to specify the exact domains that should use this resolver using the matchDomains member variable. While it's not explicitly mentioned in the documentation [1], I've noticed that if a domain is present in matchDomains, then all subdomains of it will also be resolved using this resolver, as if a wildcard match rule is in place. I wanted to ask if this the intended behavior, and if so, is there any way to disable it so that only exact domain matches will be resolved? I.e., if "example.com" is in the matchDomains list, I would like requests for this domain be resolved using the configured DNS resolver, while ignoring requests to the subdomain"test.example.com". [1] https://developer.apple.com/documentation/networkextension/nednssettings/matchdomains

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

Using NEHotspotConfigurationManager.joinAccessoryHotspot(_ accessory: ASAccessory, passphrase: String) to connect the WiFi, but this function implicitly sets joinOnce to YES. Is there any api that can use ASAccessory to connect to WiFi while maintaining JoinOnce = false. Is it possible to open up this feature？

Firstly, I'm completely new to native Swift/iOS Development so apologies if this is a simple question that I'm seemingly misunderstanding. I have an app which has the Multicast Networking entitlement and works fine on my own iPhone, however it only has one interface when I list them (en0) The multicast networking, however, fails entirely on another test iPhone but this also appears to have one or more 'ipsecX' interfaces both with the IP 192.0.0.6 - I'm guessing but I wonder if this is related to a connection to Apple Watch as I've noticed two devices that have these additional interfaces, and both of them are connected to Apple Watch (with no VPNs configured) and that's the only thing that differentiates them from my own iPhone. I can reproduce the symptoms on my own iPhone by connecting to a VPN which creates a utunX interface (but in my case disconnecting from the VPN removes this interface and it works as expected) I expect a solution would be to bind my Multicast Group to the WiFi IP but I've tried a few things without success; Setting params.requiredInterfaceType = .wifi Looping through each interface to try and 'find' en0 and bind this way; let queue = DispatchQueue(label: "En0MonitorQueue") monitor.pathUpdateHandler = { [weak self] path in // Find the en0 interface if let en0 = path.availableInterfaces.first(where: { $0.name == "en0" }) { monitor.cancel() // Stop monitoring once found let params = NWParameters.udp params.allowLocalEndpointReuse = true params.requiredInterface = en0 guard let multicast = try? NWMulticastGroup(for: [ .hostPort( host: NWEndpoint.Host(self?.settings.multicastIP ?? "224.224.0.77"), port: NWEndpoint.Port(rawValue: UInt16(self?.settings.multicastPort ?? 23019)) ) ]) else { print("Failed to Start Multicast Group") return } let group = NWConnectionGroup(with: multicast, using: params) // previous multicast stuff is here } else { print("en0 interface not found, waiting...") } } monitor.start(queue: queue) Neither seems to work. I feel I must be missing something simple, because it should not be the case that simply enabling a VPN (or having another interface created by something else) breaks Multicast on en0/WiFi. That said, I also don't want to limit the user to en0 as they may wish to use Ethernet interfaces, but for now it would be good to make it work to confirm this is the problem.

We're encountering an issue with our Network Extension (utilizing NEPacketTunnelProvider and NETransparentProxy) on macOS 14.5 (23F79). On some systems, the VPN fails to automatically start after a reboot despite calling startVPNTunnel(). There are no error messages. Our code attempts to start the tunnel: ....... do { try manager.connection.startVPNTunnel() Logger.default("Started tunnel successfully") } catch { Logger.error("Failed to launch tunnel") } ...... System log analysis reveals the tunnel stopping due to userLogout (NEProviderStopReason(rawValue: 12)) during reboot. However, the Transparent Proxy stops due to userInitiated (NEProviderStopReason(rawValue: 1)) for the same reboot. We need to understand: Why the VPNTunnel isn't starting automatically. Why the userLogout reason is triggered during reboot. Additional Context: We have manually started the VPN from System Settings before reboot.

CFNetwork None CFURLResponseGetRecommendedCachePolicy None 0 CFNetwork None CFHTTPCookieStorageUnscheduleFromRunLoop None 0 CFNetwork None /_/_CFNetworkAgentMessageProcessorMain None 0 CFNetwork None CFURLDownloadCancel None 0 CFNetwork None CFURLDownloadCancel None 0 libdispatch.dylib None /_dispatch/_block/_async/_invoke2 None We've observed intermittent crashes in our production environment, exclusively affecting customers running macOS 10.15 and 11. The crash logs consistently show a stack trace involving CFHTTPCookieStorageUnscheduleFromRunLoop and CFURLDownloadCancel within the CFNetwork framework. This suggests potential issues with cookie storage management and/or URL download cancellation. Could the team please analyze these crash logs and provide insights into: The root cause of the crashes. Potential race conditions or synchronization issues. Recommendations for mitigating or resolving the problem. Your assistance in resolving this issue is greatly appreciated."

We've observed intermittent crashes in our production environment, pls help to take a look at this, thx

We have an old iOS app and an old camera that connects using Wi-Fi either using an access point or Ad Hoc network, e.g., iPhone/iPad connects to the camera's Wi-Fi directly... How it works (old legacy app/system, which cannot be redesigned): Camera is configured to Ad Hoc Wi-Fi network (insecure TCP). iPhone connects to this insecure Wi-Fi. Camera uses Bonjour service to broadcast its IP address. App reads in IP address and begin to send messages to the camera using NSMutableURLRequest, etc. All this works fine for iOS 17. But in iOS 18 step 4 stopped working. App simply doesn't get any responses! We believe we have configured ATS properly (App Store version): In panic we have also tried this in Test Flight version: The latter actually seemed to make a difference when running the app on macOS Apple Silicon. But on iOS it didn't seem to make any difference. Occasionally, I was lucky to get connection on on iPhone 16 Pro with iOS 18. But for the 'many' iPads I have tried I couldn't. I also tried to install CFNetwork profile and look at the logs but I believe I just got timeout on the requests. Questions: Why it iOS 18 different? Bonjour works fine, but NSSURLRequests doesn't Do we configure ATS correctly for this scenario? What should I look for in the Console log when CFNetwork profile is installed? Should I file a TSI? Thanks! :)

Title: Loss of Internet Connectivity on iOS Device When Packet Tunnel Crashes Feedback ticket: https://feedbackassistant.apple.com/feedback/14162605 Product: iPhone 12 Version: iOS - 17.5.1 Configuration: NETunnelProviderManager Configuration Description: We are developing an iOS VPN client and have configured our packet tunnel provider according to Apple's guidelines. The configuration is as follows: includeAllNetworks = YES excludeLocalNetworks = NO enforceRoutes = NO This setup works as expected when the VPN successfully connects. However, we encounter a blocker issue where the device loses internet connectivity if the packet tunnel crashes. Steps to Reproduce: Configure the NETunnelProviderManager with the above settings. Connect the VPN, which successfully establishes a connection. Verify that resources are accessible and internet connectivity is functional. Packet tunnel to crash unexpectedly.Observe that the NE process (Packet Tunnel) restarts automatically, as expected and attempts to reconnect the VPN; however, the device now lacks internet connectivity, preventing VPN reconnection. Try accessing resources using Safari or any other internet-dependent app, resulting in an error indicating the device is not connected to the internet. Actual Results: The device loses internet connectivity after the packet tunnel crashes and fails to regain it automatically, preventing the VPN from reconnecting. Expected Results: The device should maintain internet connectivity or recover connectivity to allow the VPN to reconnect successfully after the packet tunnel process restarts. Workaround - iPhone device needs a restart to regain internet connectivity .