So it seems the NetworkFramework is still not able to support Broastcast Mode am I correct? As soon as I switch broadcast mode to On in my game I receive console messages instead of receiving data. nw_path_evaluator_create_flow_inner failed NECP_CLIENT_ACTION_ADD_FLOW (null) evaluator parameters: udp, definite, server, attribution: developer, reuse local address, context: Default Network Context (private), proc: 2702288D-96FB-37DD-8610-A68CC526EA0F, local address: 0.0.0.0:20778 nw_path_evaluator_create_flow_inner NECP_CLIENT_ACTION_ADD_FLOW 1FB68D7E-7C9B-47B2-B6AC-E5710CD9C9CD [17: File exists] nw_endpoint_flow_setup_channel [C2 192.168.178.221:52716 initial channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] failed to request add nexus flow nw_endpoint_flow_failed_with_error [C2 192.168.178.221:52716 initial channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] already failing, returning nw_endpoint_handler_create_from_protocol_listener [C2 192.168.178.221:52716 failed channel-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] nw_endpoint_flow_pre_attach_protocols nw_connection_create_from_protocol_on_nw_queue [C2] Failed to create connection from listener nw_ip_channel_inbox_handle_new_flow nw_connection_create_from_protocol_on_nw_queue failed I won't be able to receive data which is a real shame, so I guess I am stuck with the lower level code: // Enable broadcast var enableBroadcast: Int32 = 1 if setsockopt(socketDescriptor, SOL_SOCKET, SO_BROADCAST, &enableBroadcast, socklen_t(MemoryLayout<Int32>.size)) == -1 { let errorMessage = String(cString: strerror(errno)) throw UDPSocketError.cannotEnableBroadcast(errorMessage) }

We have a setup where the system uses proxy settings configured via a PAC file. We are investigating how NWConnection behaves inside a Network Extension (NETransparentProxyProvider) with a transparent proxy configuration based on this PAC file. Scenario: The browser makes a connection which the PAC file resolves as "DIRECT" (bypassing the proxy) Our Network Extension intercepts this traffic for analysis The extension creates a new connection using NWConnection to the original remote address. The issue: despite the PAC file’s "DIRECT" decision, NWConnection still respects the system proxy settings and routes the connection through the proxy. Our questions: Is it correct that NWConnection always uses the system proxy if configured ? Does setting preferNoProxies = true guarantee bypassing the system proxy? Additionally: Whitelisting IPs in the Network Extension to avoid interception is not a viable solution because IPs may correspond to multiple services, and the extension only sees IP addresses, not domains (e.g., we want to skip scanning meet.google.com traffic but still scan other Google services on the same IP range). Are there any recommended approaches or best practices to ensure that connections initiated from a Network Extension can truly bypass the proxy (for example, for specific IP ranges or domains)?

iOS 18.4 introduced some requirements on the Key Usage of 802.1x server certificates, as described here. https://support.apple.com/en-us/121158 When using TLS_ECDHE_RSA or TLS_DHE_RSA cipher suites, 802.1X server certificates containing a Key Usage extension must have Digital Signature key usage set. When using the TLS_RSA cipher suite, 802.1X server certificates containing a Key Usage extension must have Key Encipherment key usage set. It reads like the change is supposed to affect 802.1x only. However, we have found out that the new restrictions are actually imposed on all TLS connections using the Network framework, including in Safari. Unlike other certificate errors which can be either ignored by users (as in Safari) or by code (via sec_protocol_options_set_verify_block), these new ones can't. Even if passing completion(true) in the TLS verification block, the connection still ends up in waiting state with error -9830: illegal parameter. I understand that these requirements are valid ones but as a generic TLS library I also expect that Network framework could at least allow overriding the behavior. The current treatment is not consistent with those on other certificate errors. Since I can't upload certificates, here is how to reproduce a certificate that fails. Create a OpenSSL config file test.cnf [ req ] default_bits = 2048 distinguished_name = dn x509_extensions = v3_ca prompt = no [ dn ] CN = example.com [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = CA:TRUE keyUsage = critical, keyCertSign, cRLSign Generate certificate and private key openssl req -x509 -new -nodes -keyout key.pem -out cert.pem -days 365 -config test.cnf And here is the client code to test. // Target server and port let host = NWEndpoint.Host("example.com") let port = NWEndpoint.Port("443")! // Configure insecure TLS options let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { _, _, completion in // Always trust completion(true) }, DispatchQueue.global()) let params = NWParameters(tls: tlsOptions) let connection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: params) connection.stateUpdateHandler = { newState in switch newState { case .ready: print("TLS connection established") case .failed(let error): print("Connection failed: \(error)") case .cancelled: print("Connection canceled") case .preparing: print("Connection preparing") case .waiting(let error): print("Connection waiting: \(error)") case .setup: print("Connection setup") default: break } } connection.start(queue: .global()) Output Connection preparing Connection waiting: -9830: illegal parameter Previously reported as FB17099740

Question 1: After NetworkExtension is installed, when the software receives a pushed uninstall command, it needs to download the entire software but fails to uninstall this NetworkExtension. Are there any solutions? Question 2: How can residual, uninstalled NetworkExtensions be cleaned up when SIP (System Integrity Protection) is enabled?

I have read all the information and forum posts about local network, such as TN3179, etc., and have added NSLocalNetworkUsageDescription, but it does not solve my problem. The problem I encountered is described as follows: Device: iOS18.1.1 Signing method: automatic Xcode debug directly runs, and the app can access 17.25.11.128 normally. However, relase run or packaged into adhoc installation, this IP cannot be accessed. There is a phenomenon that the app package of the App Store can also be used. Our test team has few iOS18+ devices, and internal testing is not possible. Please contact us as soon as possible, thank you. ======= 我已经了解了所有关于local network 相关的资料和论坛帖子，比如TN3179 等等， 已经添加了 NSLocalNetworkUsageDescription， 但是不解决我的问题。 我遇到的问题描述如下： 设备：iOS18.1.1 签名方式：自动 xcode debug 直接运行，app是可以正常访问17.25.11.128的。 但是 relase run 或者 打包成 adhoc 安装，就无法访问这个IP了。 有一个现象， App Store 的app包 也是可以的。 我们的测试团队，iOS18+的设备就没几个，还不能内部测试了。请尽快联系我们，谢谢。

[Q] How many instances of the same NEFilterDataProvider subclass can there be in a single running Network Extension at any given time? I would expect that there can be only 1 instance but I'm looking at a memgraph where 2 instances are listed. As it's the Network Extension framework that is responsible for creating, starting and stopping these instances, this is rather strange.

In my Packet Tunnel Provider, I'm setting the NEDNSSettings to localhost as I have a local DNS server listening on port 53 (this is a dns forwarder which conditionally forwards to different upstreams based on rules). On iOS it works just fine, I'm able to listen on localhost:53 in the Network Extension, then set NEDNSSettings servers to "127.0.0.1". However on macOS due to the port being under 1024, I get a Permission denied OS code 13 error. I'm assuming this is due to the Network Extension not running as root. Can this be changed? This could be rectified if you could customize the port in NEDNSSettings, as the listener could be on port 5353, but it doesn't look like it is possible? Just wondering if there is some other way to accomplish what I'm trying to do in the macOS Network Extension?

Hi Dev Forums and Quinn "The Eskimo!", Short version Is there sample NWConnection code available that behaves in a similar way to the higher level URLSession and URLRequest APIs? Long version I have not been able to make this question get past the "sensitive language filter" on the dev forums. I figured it might be 'fool' or 'heck', or the X link, but removing each of those still triggers the sensitive language filter. Please see this gist: https://gist.github.com/lzell/8672c26ecb6ee1bb26d3aa3c7d67dd62 Thank you! Lou Zell

Hello there, Starting from iOS 18.4, support was included for QWAC Validation and QCStatements. Using the official QWAC Validator at: https://eidas.ec.europa.eu/efda/qwac-validation-tool I was able to check that the domain "eidas.ec.europa.eu" has a valid QWAC certificate. However, when trying to obtain the same result using the new API, I do not obtain the same result. Here is my sample playground code: import Foundation import Security import PlaygroundSupport PlaygroundPage.current.needsIndefiniteExecution = true @MainActor class CertificateFetcher: NSObject, URLSessionDelegate { private let url: URL init(url: URL) { self.url = url super.init() } func start() { let session = URLSession(configuration: .ephemeral, delegate: self, delegateQueue: nil) let task = session.dataTask(with: url) { data, response, error in if let error = error { print("Error during request: \(error)") } else { print("Request completed.") } } task.resume() } nonisolated func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -&gt; Void) { guard let trust = challenge.protectionSpace.serverTrust else { completionHandler(.cancelAuthenticationChallenge, nil) return } if let certificates = SecTrustCopyCertificateChain(trust) as? [SecCertificate] { self.checkQWAC(certificates: certificates) } let credential = URLCredential(trust: trust) completionHandler(.useCredential, credential) } nonisolated func checkQWAC(certificates: [SecCertificate]) { let policy = SecPolicyCreateSSL(true, nil) var trust: SecTrust? guard SecTrustCreateWithCertificates(certificates as CFArray, policy, &amp;trust) == noErr, let trust else { print("Unable to create SecTrust") return } var error: CFError? guard SecTrustEvaluateWithError(trust, &amp;error) else { print("Trust evaluation failed") return } guard let result = SecTrustCopyResult(trust) as? [String : Any] else { print("No result dictionary") return } let qwacStatus = result[kSecTrustQWACValidation as String] let qcStatements = result[kSecTrustQCStatements as String] print("QWAC Status: \(String(describing: qwacStatus))") print("QC Statements: \(String(describing: qcStatements))") } } let url = URL(string: "https://eidas.ec.europa.eu/")! let fetcher = CertificateFetcher(url: url) fetcher.start() Which prints: QWAC Status: nil QC Statements: nil Request completed. Am I making a mistake while using the Security framework? I would greatly appreciate any help or guidance you can provide.

Hi everyone, I'm developing an enterprise iOS application and need to access the WiFi connection channel. I understand that Apple's privacy and security policies restrict direct access to certain network details, including the WiFi connection channel. After some research, I found that this data might be accessible via the private API MobileWiFi.framework. However, when I tried to use this framework, I encountered the following error: Missing com.apple.wifi.manager-access entitlement I reached out to Apple regarding this entitlement, but they were not familiar with it, suggesting it might be deprecated. Here are my questions: Is there an official or supported way to access the WiFi connection channel in an enterprise iOS app? If not, is there any workaround or additional steps required to use the MobileWiFi.framework without encountering the entitlement error? Are there any specific entitlements or provisioning profile configurations that I need to be aware of to resolve this issue? Any guidance or suggestions would be greatly appreciated. Thank you!

On one test machine, our extension wouldn't load, because [NETransparentProxyManager loadAllFromPreferencesWithCompletionHandler] can't find a manager, saying Skipping configuration appname because it is of the wrong type. This is the first time I've seen this behaviour. (The containing app tries to find a configuration, if it can't find it it creates one, then modifies whatever it found or created, then stores it. I don't have the right logging yet for that, so I can't see the error messages. [NSLog instead of os_log_error.])

Hi everyone, I’m working on an iOS project where an iPhone needs to connect to external scanners (dedicated hardware devices) over Wi-Fi. The goal is to: Discover available Wi-Fi networks from the scanner devices (broadcasting their own networks). Allow the user to seamlessly connect to the chosen scanner network. Network Discovery: Is there a way to programmatically list available Wi-Fi networks (SSIDs) on iOS without private APIs? If not, are there workarounds (e.g., Bonjour/mDNS)? Seamless Connection: As I see, we can use NEHotspotConfigurationManager to connect to and disconnect from specified networks and there will always be a system alert asking about do we really want to join this network Hardware/Firmware/Software Alternatives: If iOS restrictions prevent this, what alternatives exist? For example: Hardware: Scanners supporting Bluetooth LE for initial pairing, then Wi-Fi provisioning. Firmware: Scanners acting as clients on the same network as the iPhone (e.g., via user’s home/office Wi-Fi). Software: A companion app for the scanner that shares network credentials via QR code/NFC, or a local web server on the scanner for setup. Context: Target: iOS 16+ No jailbreaking; App Store compliance is a must. Scanners can be configured to act as APs or clients.

I am in the middle of investigating an issue arising in the call to setsockopt syscall where it returns an undocumented and unexpected errno. As part of that, I'm looking for a way to list any socket content filters or any such extensions are in play on the system where this happens. To do that, I ran: systemextensionsctl list That retuns the following output: 0 extension(s) which seems to indicate there's no filters or extensions in play. However, when I do: netstat -s among other things, it shows: net_api: 2 interface filters currently attached 2 interface filters currently attached by OS 2 interface filters attached since boot 2 interface filters attached since boot by OS ... 4 socket filters currently attached 4 socket filters currently attached by OS 4 socket filters attached since boot 4 socket filters attached since boot by OS What would be the right command/tool/options that I could use to list all the socket filters/extensions (and their details) that are in use and applicable when a call to setsockopt is made from an application on that system? Edit: This is on a macosx-aarch64 with various different OS versions - 13.6.7, 14.3.1 and even 14.4.1.

As a third-party application on Apple Watch, can it be located in the same LAN httpServer? Currently, when testing to initiate an http request in the LAN, the connection timeout is returned, code: -1001 self.customSession.request("http://10.15.48.191:9000/hello").response { response in switch response.result { case .success(let data): dlog("✅ 请求成功，收到数据：") if let html = String(data: data ?? Data(), encoding: .utf8) { dlog(html) } case .failure(let error): dlog("❌ 请求失败：\(error.localizedDescription)") } } 执行后报错 Task <B71BE820-FD0E-4880-A6DD-1F8F6EAF98B0>.<1> finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001 "请求超时。" UserInfo={_kCFStreamErrorCodeKey=-2102, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <B71BE820-FD0E-4880-A6DD-1F8F6EAF98B0>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <B71BE820-FD0E-4880-A6DD-1F8F6EAF98B0>.<1>", "LocalDataPDTask <B71BE820-FD0E-4880-A6DD-1F8F6EAF98B0>.<1>", "LocalDataTask <B71BE820-FD0E-4880-A6DD-1F8F6EAF98B0>.<1>" ), NSLocalizedDescription=请求超时。, _kCFStreamErrorDomainKey=4, NSErrorFailingURLStringKey=http://10.15.48.191:9000/hello, NSErrorFailingURLKey=http://10.15.48.191:9000/hello}

Hi! I recently had an idea to build an iOS app that allows users to create a system-level block of specified web domains by curating a "blacklist" on their device. If the user, for instance, inputs "*example.com" to their list, their iPhone would be blocked from relaying that network traffic to their ISP/DNS, and hence return an error message ("iPhone can't open the page because the address is invalid") instead of successfully fetching the response from example.com's servers. The overarching goal of this app would be to allow users to time-block their use of specified websites/apps and grant them greater agency over their technology consumption, and I thought that an app that blocks traffic at the network level, combined with the ability to control when to/not to allow access, would be a powerful alternative to the existing implementations out there that work more on the browser-level (eg. via Safari extension, which is isolated to the scope of user's Safari browser) or via Screen Time (which can be easy to bypass by inputting one's passcode). Another thing to mention is that since the app would serve as a local DNS proxy (instead of relying on a third party DNS resolver), none of their internet activity will be collected/transmitted off-device and be used for commercial purposes. I feel particularly driven to create a privacy-centered app in this way, since no user data needs to be harvested to implement this kind of filtering. I'd also love to get suggestions for a transparent privacy policy that respects users control over their device. With all this said, I found that the Network Extension APIs may be the only way that an app like this could be built on iOS and, I wanted to ask if the above-mentioned use case of Network Extension would be eligible to be granted access to its entitlement before I go ahead and purchase the $99/year Apple Developer Program membership. Happy to provide further information, and I'd also particularly be open to any mentions of existing solutions out there (since I might have missed some in my search). Maybe something like this already exists, in which case it'd be great to know in any case! :). Thank you so much in advance!

We are implementing a connection between iPad and iPhone devices using LocalPushConnectivity, and have introduced SimplePushProvider into the project. We will have it switch between roles of Server and Client within a single project. ※ iPad will be Server and the iPhone will be Client. Communication between Server and Client is via TLS, with Server reading p12 file and Client setting public key. Currently, a TLS error code of "-9836" (invalid protocol version) is occurring when communicating from Client's SimplePushProvider to Server. I believe that Client is sending TLS1.3, and Server is set to accept TLS1.2 to 1.3. Therefore, I believe that the actual error is not due to TLS protocol version, but is an error that is related to security policy or TLS communication setting. Example: P12 file does not meet some requirement NWProtocolTLS.Options setting is insufficient etc... I'm not sure what the problem is, so please help. For reference, I will attach you implementation of TLS communication settings. P12 file is self-signed and was created by exporting it from Keychain Access. Test environment: iPad (OS: 16.6) iPhone (OS: 18.3.2) ConnectionOptions: TLS communication settings public enum ConnectionOptions { public enum TCP { public static var options: NWProtocolTCP.Options { let options = NWProtocolTCP.Options() options.noDelay = true options.enableFastOpen return options } } public enum TLS { public enum Error: Swift.Error { case invalidP12 case unableToExtractIdentity case unknown } public class Server { public let p12: URL public let passphrase: String public init(p12 url: URL, passphrase: String) { self.p12 = url self.passphrase = passphrase } public var options: NWProtocolTLS.Options? { guard let data = try? Data(contentsOf: p12) else { return nil } let pkcs12Options = [kSecImportExportPassphrase: passphrase] var importItems: CFArray? let status = SecPKCS12Import(data as CFData, pkcs12Options as CFDictionary, &amp;importItems) guard status == errSecSuccess, let items = importItems as? [[String: Any]], let importItemIdentity = items.first?[kSecImportItemIdentity as String], let identity = sec_identity_create(importItemIdentity as! SecIdentity) else { return nil } let options = NWProtocolTLS.Options() sec_protocol_options_set_min_tls_protocol_version(options.securityProtocolOptions, .TLSv12) sec_protocol_options_set_max_tls_protocol_version(options.securityProtocolOptions, .TLSv13) sec_protocol_options_set_local_identity(options.securityProtocolOptions, identity) sec_protocol_options_append_tls_ciphersuite(options.securityProtocolOptions, tls_ciphersuite_t.RSA_WITH_AES_128_GCM_SHA256) return options } } public class Client { public let publicKeyHash: String private let dispatchQueue = DispatchQueue(label: "ConnectionParameters.TLS.Client.dispatchQueue") public init(publicKeyHash: String) { self.publicKeyHash = publicKeyHash } // Attempt to verify the pinned certificate. public var options: NWProtocolTLS.Options { let options = NWProtocolTLS.Options() sec_protocol_options_set_min_tls_protocol_version(options.securityProtocolOptions, .TLSv12) sec_protocol_options_set_max_tls_protocol_version(options.securityProtocolOptions, .TLSv13) sec_protocol_options_set_verify_block( options.securityProtocolOptions, verifyClosure, dispatchQueue ) return options } private func verifyClosure( secProtocolMetadata: sec_protocol_metadata_t, secTrust: sec_trust_t, secProtocolVerifyComplete: @escaping sec_protocol_verify_complete_t ) { let trust = sec_trust_copy_ref(secTrust).takeRetainedValue() guard let serverPublicKeyData = publicKey(from: trust) else { secProtocolVerifyComplete(false) return } let keyHash = cryptoKitSHA256(data: serverPublicKeyData) guard keyHash == publicKeyHash else { // Presented certificate doesn't match. secProtocolVerifyComplete(false) return } // Presented certificate matches the pinned cert. secProtocolVerifyComplete(true) } private func cryptoKitSHA256(data: Data) -&gt; String { let rsa2048Asn1Header: [UInt8] = [ 0x30, 0x82, 0x01, 0x22, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x82, 0x01, 0x0f, 0x00 ] let data = Data(rsa2048Asn1Header) + data let hash = SHA256.hash(data: data) return Data(hash).base64EncodedString() } private func publicKey(from trust: SecTrust) -&gt; Data? { guard let certificateChain = SecTrustCopyCertificateChain(trust) as? [SecCertificate], let serverCertificate = certificateChain.first else { return nil } let publicKey = SecCertificateCopyKey(serverCertificate) return SecKeyCopyExternalRepresentation(publicKey!, nil)! as Data } } } }

We need your assistance as we are currently facing an issue without a workaround for users on macOS 15.4 and 15.5. FeedbackID: FB17547675 The problem has been observed on macOS versions 15.4 and 15.5. Apple has acknowledged this issue and confirmed that it is fixed in the macOS 15.6 beta. Although we tried to reproduce the issue in our environment, it did not occur, even on macOS 15.5. Therefore, we cannot verify if the fix in macOS 15.6 beta resolves the problem. We are actively working to identify an appropriate workaround for users on macOS 15.5. Some users have reported a failure to obtain an IP address over Wi-Fi, possibly due to a DHCP failure. As a temporary solution, we added logic to restart Wi-Fi programmatically when either an APIPA address (169.254.x.x) or no IPv4 address is detected on the active interface. However, restarting Wi-Fi does not always resolve the issue, and the device may still fail to obtain an IP address over Wi-Fi or Ethernet. Could you advise if there is a reliable method to detect DHCP failure and recover the device from this state? Also, any idea, how we can reproduce this scenario in our machine? Below is the failure. default 2025-06-27 10:07:57.055003 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:07:57.055269 -0700 configd DHCP en0: status = 'no server' default 2025-06-27 10:08:23.336215 -0700 airportd WiFiUsageBssSession:: ChannelAfterRoam=0; ChannelAtJoin=36; FaultReasonApsdTimedOut=0; FaultReasonArpFailureCount=0; FaultReasonBrokenBackhaulLinkFailed=0; FaultReasonDhcpFailure=0; default 2025-06-27 10:08:23.367852 -0700 configd DHCP en0: status = 'media inactive' default 2025-06-27 10:08:23.367909 -0700 configd DHCP en0: INACTIVE default 2025-06-27 10:08:23.988565 -0700 configd DHCP en0: status = 'media inactive' default 2025-06-27 10:08:23.988703 -0700 configd DHCP en0: INACTIVE info 2025-06-27 10:08:23.988852 -0700 configd DHCPv6 en0: Inactive default 2025-06-27 10:08:35.656415 -0700 configd DHCP en0: status = 'network changed' default 2025-06-27 10:08:35.656817 -0700 configd DHCP en0: INIT default 2025-06-27 10:08:35.656821 -0700 configd DHCP en0: supplying device type 'Mac' info 2025-06-27 10:08:35.656934 -0700 configd DHCP en0: busy default 2025-06-27 10:08:35.657351 -0700 configd DHCP en0: INIT waiting at 0 for 1.358613 info 2025-06-27 10:08:35.657404 -0700 configd DHCPv6 en0: Inactive default 2025-06-27 10:08:37.019229 -0700 configd DHCP en0: INIT waiting at 1.36206 for 2.113913 default 2025-06-27 10:08:39.136955 -0700 configd DHCP en0: INIT waiting at 3.47937 for 4.462224 default 2025-06-27 10:08:43.602229 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:08:43.603143 -0700 configd DHCP en0: INIT waiting at 7.94533 for 8.128784 default 2025-06-27 10:08:51.735532 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:08:51.735846 -0700 configd DHCP en0: INIT waiting at 16.0786 for 8.749985 default 2025-06-27 10:09:00.488315 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:09:00.488550 -0700 configd DHCP en0: INIT waiting at 24.8313 for 8.496864 default 2025-06-27 10:09:08.988284 -0700 configd DHCP en0: ARP router: No leases to query for default 2025-06-27 10:09:08.988310 -0700 configd DHCP en0: reported address acquisition failure symptom default 2025-06-27 10:09:08.988579 -0700 configd DHCP en0: INIT waiting at 33.3312 for 8.300735 default 2025-06-27 10:09:17.294478 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:17.294485 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:17.295454 -0700 configd DHCP en0: INIT waiting at 41.6373 for 8.798768 default 2025-06-27 10:09:26.096673 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:26.096688 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:26.097553 -0700 configd DHCP en0: INIT waiting at 50.4394 for 8.807943 default 2025-06-27 10:09:34.909050 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:34.909054 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:34.909375 -0700 configd DHCP en0: INIT waiting at 59.2517 for 8.877971 default 2025-06-27 10:09:43.792458 -0700 configd DHCP en0: ARP router: No leases to query for info 2025-06-27 10:09:43.792464 -0700 configd DHCP en0: symptom failure already reported default 2025-06-27 10:09:43.793641 -0700 configd DHCP en0: status = 'no server' info 2025-06-27 10:09:43.794145 -0700 configd DHCP en0: not busy DNS failure 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 Route table Destination Gateway Flags Netif Expire 127 127.0.0.1 UCS lo0 127.0.0.1 127.0.0.1 UH lo0 169.254 link#14 UCS en0 ! 169.254.160.160/32 link#14 UCS en0 ! 224.0.0/4 link#14 UmCS en0 ! 224.0.0.251 1:0:5e:0:0:fb UHmLWI en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI en0 255.255.255.255/32 link#14 UCS en0 !

My laptop (M1 Pro, macOS 15.3.2) is connected to a dual stack network via Wi-Fi. The home.arpa. domain is supplied as a search domain via both DHCPv4 (options 15 and 119) and DHCPv6 (option 24). "Details…" for the network connection in System Settings show this domain under the DNS tab. The laptop uses a Forwarding DNS Resolver of my router, which in turn forwards requests for home.arpa. (including subdomains) to a local DNS server (CoreDNS) which is authoritative for this zone. The DNS server is configured via the following zone file: $ORIGIN home.arpa. $TTL 3600 @ IN SOA @ nobody.invalid. (1 3600 1200 604800 3600) @ NS @ @ AAAA ….1 gateway A ….1 gateway AAAA …::1 b._dns-sd._udp PTR @ lb._dns-sd._udp PTR @ db._dns-sd._udp PTR @ _services._dns-sd._udp PTR _smb._tcp _smb._tcp PTR Media._smb._tcp Media._smb._tcp SRV 0 0 445 gateway Media._smb._tcp TXT ("path=/media" "u=guest") Output of dig(1) looks like: $ dig @….1 -t PTR lb._dns-sd._udp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43291 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;lb._dns-sd._udp.home.arpa. IN PTR ;; ANSWER SECTION: lb._dns-sd._udp.home.arpa. 1993 IN PTR home.arpa. ;; AUTHORITY SECTION: home.arpa. 2771 IN NS home.arpa. $ dig @….1 -t PTR _services._dns-sd._udp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9057 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;_services._dns-sd._udp.home.arpa. IN PTR ;; ANSWER SECTION: _services._dns-sd._udp.home.arpa. 3600 IN PTR _smb._tcp.home.arpa. ;; AUTHORITY SECTION: home.arpa. 3600 IN NS home.arpa. $ dig @….1 -t PTR _smb._tcp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44220 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;_smb._tcp.home.arpa. IN PTR ;; ANSWER SECTION: _smb._tcp.home.arpa. 3599 IN PTR Media._smb._tcp.home.arpa. ;; AUTHORITY SECTION: home.arpa. 3599 IN NS home.arpa. $ dig @….1 -t SRV Media._smb._tcp.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45878 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;Media._smb._tcp.home.arpa. IN SRV ;; ANSWER SECTION: media._smb._tcp.home.arpa. 3600 IN SRV 0 0 445 gateway.home.arpa. ;; AUTHORITY SECTION: home.arpa. 3600 IN NS home.arpa. $ dig @….1 -t A gateway.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2782 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;gateway.home.arpa. IN A ;; ANSWER SECTION: gateway.home.arpa. 86400 IN A 192.168.99.1 ;; AUTHORITY SECTION: home.arpa. 3578 IN NS home.arpa. $ dig @….1 -t AAAA gateway.home.arpa. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17297 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;gateway.home.arpa. IN AAAA ;; ANSWER SECTION: gateway.home.arpa. 3600 IN AAAA fd6f:9784:5753::1 ;; AUTHORITY SECTION: home.arpa. 3600 IN NS home.arpa. Output of dns-sd(1): /usr/bin/dns-sd -test … Testing for error returns when various strings are > 63 bytes: PASSED Running basic API input range tests with various pointer parameters set to NULL: Basic API input range tests: PASSED $ dns-sd -m -F Looking for recommended browsing domains: DATE: ---Fri 11 Apr 2025--- 8:50:17.846 ...STARTING... Timestamp Recommended Browsing domain 8:50:17.847 Added (More) local 8:50:17.847 Added arpa - > home $ dns-sd -B _smb._tcp home.arpa. Browsing for _smb._tcp.home.arpa. DATE: ---Fri 11 Apr 2025--- 8:59:10.044 ...STARTING... $ dns-sd -L Media _smb._tcp home.arpa. Lookup Media._smb._tcp.home.arpa. DATE: ---Fri 11 Apr 2025--- 9:15:53.328 ...STARTING... $ dns-sd -Q _smb._tcp.home.arpa. PTR IN DATE: ---Fri 11 Apr 2025--- 9:16:52.208 ...STARTING... Timestamp A/R Flags IF Name Type Class Rdata 9:16:52.210 Add 40000002 0 _smb._tcp.home.arpa. PTR IN 0.0.0.0 No Such Record 9:16:52.222 Add 2 0 _smb._tcp.home.arpa. PTR IN 0.0.0.0 No Such Record Similarly, when I open Finder->Network I see home.arpa but it's empty. Of interest is that on the DNS server side I see the following requests being made: 2025-04-11 09:03:15 container,info,debug [INFO] […]:56541 - 21555 "SOA IN _afpovertcp._tcp.home.arpa. udp 44 false 512" NXDOMAIN qr,aa,rd 112 0.000755089s 2025-04-11 09:03:15 container,info,debug [INFO] […]:56077 - 58266 "SOA IN _smb._tcp.home.arpa. udp 37 false 512" NOERROR qr,aa,rd 105 0.001012632s 2025-04-11 09:03:15 container,info,debug [INFO] […]:45274 - 45976 "SOA IN _rfb._tcp.home.arpa. udp 37 false 512" NXDOMAIN qr,aa,rd 105 0.000762339s 2025-04-11 09:03:15 container,info,debug [INFO] […]:54387 - 32090 "SOA IN _adisk._tcp.home.arpa. udp 39 false 512" NXDOMAIN qr,aa,rd 107 0.001058132s 2025-04-11 09:03:15 container,info,debug [INFO] […]:35855 - 51155 "SOA IN _tcp.home.arpa. udp 32 false 512" NOERROR qr,aa,rd 100 0.000664963s I suppose that an attempt to locate services is made but it's unsuccessful and I'm not sure why. What further debugging can I attempt?

Hey, We also opened a feedback assistant request, and also opened a ticket with Apple Developer Technical Support a while ago that notice the unmount problem also but it was before we pin point the problem to the Network Extension. After a further investigation, we've found out that the root cause of this problem is cause by having a network filter from the NetworkExtension provider on (Specifically we have tested with the NEFilterDataProvider) while having a Xsan volume. The NEFilterDataProvider causing problems for the Xsan, and is stalling the shutdown until we get a panic from watchdog timeout, and only then the mac is fully shutdown. The problem from what we investigated and also talked with you, is that the Xsan process can't unmount the volume and stuck. We have also noticed that if we install a network extension and allow the popup of the network filters, i.e enabled the NEFilterDataProvider the computer is stuck, and the finder is in a non responsive state until a reboot (Also probably due to the fact the Xsan is now in a problematic state). This tests was done on latest versions of MacOs 13 & 14. We have taken a sysdiagnose from the computer while we have tested. Do you familiar with the problem (We got no answer on the feedback assistant)? Thank you, Idan

(iOS 17.3) I'm using the Apple supplied iOS sample project "ConfiguringAWiFiAccessoryToJoinTheUsersNetwork" as a base to write an App to configure an existing WiFi device using the NEHotspotConfiguration API's. I have almost everything working, and can join the network and send a packet to the device to configure it. I know that it is working as the device responds properly to what I send it. But I am not able to receive the response back from the device to the packet sent. (Only need 1 packet sent and 1 packet received) However. If I run a packet sniffer on the phone before running my test App, then I do get a response. No packet sniffer running, no response. When I do a debugDescription on the NWConnection after it reaches ".ready", I notice that when the sniffer is running I'm using loopback lo0: [C1 connected 192.168.4.1:80 tcp, url: http://192.168.4.1:80, attribution: developer, path satisfied (Path is satisfied), viable, interface: lo0] and I get a packet response in the NWConnection receiveMessage callback. But with no sniffer running, I get interface en0: [C1 connected 192.168.4.1:80 tcp, url: http://192.168.4.1:80, attribution: developer, path satisfied (Path is satisfied), viable, interface: en0[802.11], ipv4, dns, uses wifi] and there is no callback to the receiveMessage handler and the NWconnection eventually times out. The interface used seems to be the only difference that I can see when I have a sniffer running. Any ideas as to why I can't see a response in "normal" operation?