Two field incidents show an _nstat_rwlock/UDP socket mutex ABBA deadlock followed by a configd watchdog panic. Raw wait-owner records and UUID-matched KDK stacks identify the same cycle in each incident's earlier configd diagnostic and later panic. Affected systems Both kernels: xnu-13432.1.9~1. Kernel UUIDs are in the attachments. Report AReport BmacOS27.0 (26A428)27.0.1 (26A434)HardwareMac16,10 / T8132Mac15,6 / T6030CloudShell PID87443906Blocked configd threadPID 341, TID 19794593PID 113, TID 309370Our NEDNSProxyProvider can capture CloudShell's DNS UDP traffic and forward it via a separate upstream socket. Provider flows and CloudShell sockets have separate lifetimes. Symptoms and reproduction During DNS UDP forwarding and flow/socket cleanup, CloudShell blocks in final socket close. configd's IPConfigurationAgentQueue blocks creating a UDP socket: a diagnostic is captured after 60 seconds without check-ins, followed by panic/restart after 180 seconds: userspace watchdog timeout: no successful checkins from configd (1 induced crashes) in 180 secondsExpected: socket close completes or returns an error. We have no deterministic reproducer, measured failure rate, or reconstructed per-flow close history. Direct lock-owner evidence Raw waitInfo records (mutex tokens are opaque): Report A, 26A428: thread 18691491: kernel mutex 0x61c831d7f38edbc3 owned by thread 19491850 thread 19491850: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491 thread 19794593: krwlock 0xfffffe000cb41730 for writing owned by thread 18691491Report B, 26A434: thread 36984: kernel mutex 0x44aa649ef3095ae1 owned by thread 12555 thread 12555: krwlock 0xfffffe000ca01730 for writing owned by thread 36984 thread 309370: krwlock 0xfffffe000ca01730 for writing owned by thread 36984In each incident, the first two records form a cycle in both snapshots; the third is configd. All three threads are TH_WAIT / TH_UNINT. UUID-matched kernel stacks Caller-to-callee chains; listed offsets match in both kernels. Kernel worker (A: TID 18691491; B: TID 36984): nstat_idle_check + 808 -> in_pcb_checkstate + 128 -> udp_lock + 200 -> lck_mtx_lock_contended + 1212Holds _nstat_rwlock exclusively; waits for CloudShell's UDP socket mutex. CloudShell (A: TID 19491850; B: TID 12555): soclose + 212 -> soclose_locked + 2300 -> sofreelastref + 60 -> flow_divert_detach + 332 -> in_pcbdetach + 168 -> nstat_pcb_detach + 92 -> lck_rw_lock_exclusive + 180 -> lck_rw_lock_exclusive_gen + 912Holds the socket mutex; waits for _nstat_rwlock. XNU acquires these locks, not application code. configd (downstream victim): socket_common -> socreate_internal -> udp_attach -> nstat_udp_new_pcb -> lck_rw_lock_exclusivePossible enabling condition Matched 27 KDK disassembly shows a provider CLOSE path through cfil_sock_is_dead that directly marks the PCB DEAD and schedules GC without nstat cleanup. Public xnu-12377.121.6 (26.5) uses ordinary detach first. Provider CLOSE and final fd close are distinct. A DEAD PCB can retain an nstat locus/reference. Under _nstat_rwlock, nstat_idle_check removes the locus and releases the reference via in_pcb_checkstate(..., WNT_RELEASE, FALSE), which can take the socket mutex. Final close takes the reverse order; nstat_pcb_detach requests the nstat lock even when the locus is null. This is a possible enabling path from disassembly/source analysis, not proof of the preceding provider CLOSE in either incident. The older source already has opposite static lock orders; 26.5 is not proven immune. Questions for Apple Our provider calls closeReadWithError:nil and closeWriteWithError:nil when finished, as documented for NEAppProxyFlow. This does not validate the entire asynchronous lifecycle. Is this cycle known, and is there a fixed build? How is reverse locking avoided after the direct DEAD transition? Is there a supported workaround preserving flow cleanup? Close rate-limiting is not proven to eliminate the issue. Which diagnostics would help correlate provider CLOSE, DEAD, and final fd close? Attachments and timestamps Four EXCERPT attachments contain watchdog messages, raw frames, KDK annotations, and wait-owner records. Full reports are retained for private Feedback Assistant submission. 26A428_panic_excerpt.txt 26A428_configd_excerpt.txt 26A434_panic_excerpt.txt 26A434_configd_excerpt.txt 2026-10-15, +0800: configd capture -> embedded panic event: A: 04:24:43.1258 -> 04:26:44 B: 08:49:29.4349 -> 08:51:32 Use embedded panic times, not file/header timestamps. Original pairs match on boot identity; identifiers are omitted from excerpts. Sources: NEAppProxyFlow, XNU 26.5 comparison.

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

I have a free Apple Developer account and am evaluating an iPhone app that listens for LLDP frames from a USB Ethernet adapter using NWEthernetChannel. Apple’s documentation says this API requires com.apple.developer.networking.custom-protocol. Can this entitlement be used for development on a physical iPhone with free provisioning, or do I need paid Apple Developer Program membership? Does the entitlement require Apple’s approval or a capability request? Can an app with this entitlement be distributed through the App Store? I’m targeting iOS 25 and later. I can provide the adapter and iPhone models if useful.

I've been investigating memory consumption issues with a network extension. It seems as though the "leak" exists within the network extension framework. Looking at a memory graph, there appears to be a _socketFlows dictionary or similar in the network extension framework that holds all of the flows and they continue to pile up and consume memory. The problem seems to be particularly bad when I leave my MacBook plugged in and running over the weekend and come back on Monday. For instance, in that time period, the memory consumption grew from <100MB to >1GB. To try to narrow this down to see if it was an "us" problem or truly in the framework, I installed Objective-See Foundation's Lulu tool, which also uses a network extension. It similarly saw memory grow from around 30MB or less to 600MB in the same time frame. Has anyone else seen this? We do have an open feedback ticket FB18731867 that might be related that has to do with seeing multiple instances of the same data filter provider started and maybe running in a network extension.

I'm developing Androfest, a native Android app with a SwiftUI macOS companion. It provides user-authorized notification forwarding, automatic clipboard synchronization, file transfer, and phone-call controls, with experimental call-audio relay. I need a secure, direct connection between a nearby Android phone and a Mac without requiring both devices to join the same Wi-Fi network or using a cloud relay. Discovery, authenticated pairing, and a bidirectional IP data path are the requirements; application traffic uses certificate-pinned TLS. The Android side uses WifiAwareManager. My development devices are a Galaxy S24 FE running Android 16 / One UI 8 and an Apple silicon M4 Pro Mac running macOS 27.2. I read the DTS answer in “Do Mac computers support Wi-Fi Aware?” (https://developer.apple.com/forums/thread/827887), which explains that the presence of the framework for Mac Catalyst does not imply usable Wi-Fi Aware support on Mac. I am asking specifically about the provisioning information below and whether there is an approved path for this use case. In Certificates, Identifiers & Profiles → Register an App ID → Capabilities → Wi-Fi Aware, the information popover currently shows: Platform Support: iOS Provisioning Support: Development, Ad hoc, App Store Connect, Developer ID Entitlement Keys: com.apple.developer.wifi-aware This is confusing because Developer ID is listed while macOS is not listed under Platform Support. The native macOS SDK declarations I inspected mark the public Wi-Fi Aware APIs unavailable on macOS. Two previously generated Developer ID provisioning profiles for my test App ID had Platform = OSX, but neither contained com.apple.developer.wifi-aware. I also could not find a Wi-Fi Aware-specific approval request in the portal's Capability Requests list. Could Apple clarify the following? Does the Developer ID entry describe a usable configuration for native macOS or Mac Catalyst applications, or is it a portal metadata issue? Is there a supported API, managed entitlement, or approval process for Wi-Fi Aware discovery and IP data paths between a third-party macOS app and an Android device? If so, which target platform, capability, provisioning-profile type, and signing configuration are required? Can that configuration operate on a standard Mac with SIP enabled, default NVRAM/boot arguments, and normal code-signing enforcement? A distributable application needs to work under those conditions. If Wi-Fi Aware is not supported for this scenario, what supported transport would Apple recommend for router-independent Android–Mac communication? Where should I file an enhancement request, and should the portal's Developer ID entry be reported separately? I would appreciate guidance on the supported integration route and any missing provisioning or entitlement step. Thank you.

Hello Apple Developer Community, I’m developing an iOS application and investigating an unusual, persistent HTTPS connectivity issue. I would appreciate guidance from developers experienced with URLSession, CFNetwork, and iOS networking. Environment Main app: React Native / Expo SDK 57. Independent diagnostic app: native Swift using URLSession with a long-lived ephemeral session. Backend: Node.js/Fastify behind Nginx on a Linux VPS. Affected device: physical iPhone 15 Pro running iOS 27.0.1. Comparison device: physical iPhone 11 running iOS 18.7.8. HTTPS API using a publicly trusted TLS certificate. Observed behavior The iPhone 11 generally communicates reliably with the API when its VPN is disabled. The iPhone 15 Pro experiences intermittent connectivity failures over both Wi-Fi and cellular LTE. Successful requests often complete within 100–300 ms. Failed requests receive no HTTP response and terminate with a timeout after approximately 15 seconds. The issue affects authentication, conversation retrieval, and message sending. It is not limited to chat functionality. What we have tested Replaced Expo Fetch with React Native Fetch. The issue persisted. Built a completely independent native Swift diagnostic app using URLSession. The same issue reproduced. Added X-Request-ID tracing to both Nginx and Fastify. During one native diagnostic run of 20 sequential GET requests, the first seven returned HTTP 401 in approximately 149–200 ms (likely due to an expired access token). The following 13 ended with URLSession error -1001, without any HTTP response. The request IDs for these 13 timed-out requests were absent from the checked Nginx and Fastify logs. A separate manual POST /auth/login also timed out with URLSession error -1001 after 15.6 seconds. NWPathMonitor continued to report satisfied over the cellular interface. URLSessionTaskMetrics for failed requests showed a transaction but lacked DNS, TCP, TLS, and response timing data. The server remained running and successfully handled other requests. We have not yet captured TCP packets during an actual failed request. Therefore, we cannot determine whether the failure occurs during DNS resolution, TCP connection establishment, TLS negotiation, or another stage. Questions What could cause URLSession to intermittently time out on one physical iPhone while another device can reach the same HTTPS endpoint? How should we interpret URLSessionTaskMetrics containing a transaction but no DNS/TCP/TLS timing information? Which additional iOS diagnostics would best identify the stage where the request stalls? Are there known differences in CFNetwork connection handling, DNS resolution, IPv6, or network configuration that would be worth investigating? I’m specifically looking for a systematic way to isolate the root cause rather than rewriting the application. Thank you for your help.

I'm developing an iOS app that includes the following Network Extension providers: NEPacketTunnelProvider NEFilterDataProvider NEFilterControlProvider I want to analyze CPU usage, memory footprint, and battery/energy impact for these extensions after release, using data collected from production devices. I've been looking into MetricKit, including MXMetricManager and MXMetricPayload, and would appreciate clarification on its support for app extensions. Specifically: API support: Can MetricKit be initialized and registered as a subscriber from within a Network Extension provider's process? Are there any restrictions specific to these extension types? Metric availability: If registration is supported, do the resulting metric payloads contain CPU, memory, and energy metrics attributable to the extension itself, or do they cover only the containing app? Production reliability: Can I rely on MetricKit to collect these metrics consistently across production devices and app versions? Are reports generated for extensions independently, and are there known limitations in report delivery or coverage? Memory and CPU: Is there a supported way to obtain the extension's peak memory footprint and CPU consumption through MetricKit? If these metrics aren't available through MetricKit, what APIs or reporting mechanisms does Apple recommend? Energy and battery: Can MetricKit provide energy-impact metrics specifically attributable to a Network Extension provider, rather than aggregated metrics for the containing app? Recommended approach: For post-release analysis of these extensions, should I use MetricKit, Xcode Organizer's Energy reports, custom telemetry within the extension, or a combination of these? My goal is to monitor resource consumption and identify regressions in production without relying on Instruments profiling on individual devices. I'd appreciate clarification on which of these capabilities are officially supported for Network Extension providers and which approach Apple recommends for reliable production monitoring. Thanks!

Apple blocked the eight compromised eMudhra intermediate CAs (CVE-2026-111943) for Security.framework clients. But on macOS 27.0.1 (26A434), /usr/bin/curl and /usr/bin/python3 still accept certificates from them. These tools verify against /etc/ssl/cert.pem and do not check revocation. The file (dated Sep 24) still contains both roots that the compromised intermediates chain to: emSign ECC Root CA - G3 AAA Certificate Services To reproduce, with SSL_CERT_FILE and CURL_CA_BUNDLE not set: /usr/bin/curl -sS -o /dev/null -w '%{exitcode}\n' https://dv-g3b-emudhra.we-have-a-problem.com/ # 0 — the connection succeeds grep -E 'emSign ECC Root CA - G3|AAA Certificate Services' /etc/ssl/cert.pem # both roots are presentWith a CA bundle that does not have these roots (Homebrew ca-certificates), the same command fails with "unable to get local issuer certificate". So the system bundle is the cause. softwareupdate -l shows no update. Questions: Does Apple plan to update /etc/ssl/cert.pem for this, and will the security notes say so? Until then, is setting SSL_CERT_FILE to a separate bundle the recommended workaround for the system tools?

Hello, With Xcode 27.1 RC 1, the Background Assets override inside of developer settings is now a blank page. I see there's a new setting for background assets under Scheme < Options. Will the URL replacement return? Thanks

I'm developing an iOS app that aims to manage network usage on an iPhone acting as a Personal Hotspot. I'd like to know whether there is a supported public API that allows a third-party iOS app running on the host iPhone to limit the download speed of devices connected through Personal Hotspot. For example, I'd like to limit the download speed of tethered devices to a maximum of 1 Mbps, without limiting the host iPhone's own network traffic. Is this technically possible using public iOS APIs, or is this type of bandwidth control restricted to the system? Thank you for your guidance.

Steps to reproduce: Open captive network (DHCP + DNS → portal, hotspot-detect.html returns 302). Scan the Wi-Fi QR code with Camera and tap "Join". Stay in Camera. Expected: CNA is presented after a Camera-initiated join, as it is after a join from Settings > Wi-Fi. Actual: CNA is not presented until the user manually opens Settings > Wi-Fi. Impact: In-flight Wi-Fi with no internet, where the portal is mandatory. QR codes are the only onboarding method, and most users stay in Camera. Environment: iOS 18.7, iPhone 15 Pro max Questions: Is there any supported way to have the CNA presented after a Camera-initiated Wi-Fi join, without requiring the user to open Settings or Safari? If not, is this expected behavior, or a bug worth tracking?

We're moving our VPN client's firewall off pf (TN3165) and, following the advice in https://developer.apple.com/forums/thread/781996, relying on enforceRoutes plus a content filter. That works well for keeping traffic in the tunnel, but it has a side effect we can't work around. We add excluded routes at runtime (hostname-based split tunnelling), so the provider calls setTunnelNetworkSettings while connected. With enforceRoutes = true, any connected socket to a tunnelled destination (TCP, or UDP after connect()) that sends during the update gets EPIPE and stays broken until the app reopens it. It happens with identical settings too, and the EPIPE raises SIGPIPE, so apps that don't ignore it are terminated. From a sysdiagnose, every update logs "Resetting the virtual interface", the utun's address is removed and re-added about 5 ms later, and a socket that sends in that gap is marked defunct by necp_socket_find_policy_match ("Marking socket in state 258 as defunct"). With enforceRoutes = false nothing dies, but packets for tunnelled destinations leave on the physical interface during the update. It reproduces on macOS 15.7, 26.5, 27.0 and 27.2 beta 3 (26B5101f). I filed FB25176278 with a minimal sample (a packet tunnel provider that echoes UDP, so no server is needed) and a sysdiagnose from 27.2 beta 3. Two questions: Is there a supported way to change excludedRoutes on a running tunnel without the interface reset? If not, is there anything a provider can do to avoid this today, short of not updating routes while connected? Thanks!

Hi, We're in the process of following Apple’s guidance on transitioning away from Packet Filter (pf) and migrating to a Network Extension-based solution that functions as a firewall. During this transition, we've encountered several limitations with the current Content Filter API and wanted to share our findings. Our VPN client relies on firewall functionality to enforce strict adherence to split tunneling rules defined via the routing table. This ensures that no traffic leaks outside the VPN tunnel, which is critical for our users for a variety of reasons. To enforce this, our product currently uses interface-scoped rules to block all non-VPN traffic outside the tunnel. Replicating this behavior with the Content Filter API (NEFilterDataProvider) appears to be infeasible today. The key limitation we've encountered is that the current Content Filter API does not expose information about the network interface associated with a flow. As a workaround, we considered using the flow’s local endpoint IP to infer the interface, but this data is not available until after returning a verdict to peek into the flow’s data—at which point the connection has already been established. This can result in connection metadata leaking outside the tunnel, which may contain sensitive information depending on the connection. What is the recommended approach for this use case? NEFilterPacketProvider? This may work, but it has a negative impact on network performance. Using a Packet Tunnel Provider and purely relying on enforceRoutes? Would this indeed ensure that no traffic can leak by targeting a specific interface or by using a second VPN extension? And more broadly—especially if no such approach is currently feasible with the existing APIs—we're interpreting TN3165 as a signal that pf should be considered deprecated and may not be available in the next major macOS release. Is that a reasonable interpretation?

Hi Apple engineers and developers, I am developing a consumer digital-wellbeing app called Ghostie and am trying to determine the correct Apple-supported architecture for its iOS version before continuing implementation. Ghostie's core functionality is to let the user temporarily disconnect selected third-party apps from the Internet while keeping the rest of the device online. For example: WhatsApp: blocked Instagram: blocked Slack: blocked Maps: remains online Banking: remains online Music: remains online On Android, this is implemented using VpnService with per-app traffic handling. For iOS, I have been researching Network Extension, including: NEFilterDataProvider / NEFilterControlProvider content-filter-provider NETunnelProvider / packet-tunnel-provider per-app VPN configurations Apple's current documentation appears to indicate restrictions around per-app configurations and content filtering on iOS, including managed/supervised-device requirements in certain cases. My question is specifically about a normal consumer application distributed through the App Store, where the user owns and controls their personal device and Ghostie is not an MDM/enterprise product. Is there currently an Apple-supported API, entitlement, or Network Extension architecture that would allow Ghostie to: identify selected installed third-party apps; prevent those selected apps from establishing network connections; leave all other apps' network connectivity unaffected; and allow the user to turn this blocking on and off from Ghostie? If this is not possible for an ordinary consumer App Store application, could an Apple engineer please confirm which specific iOS restriction prevents it and whether there is any alternative supported architecture? I am trying to establish the technically and commercially viable architecture before implementing the iOS version. Thank you!

Feedback ID: FB25211847 Since 2026-10-11 the root DNSKEY RRset is signed only by KSK-2024 (key tag 38696). With DNSSEC required using nw_parameters_set_requires_dnssec_validation(parameters, YES), mDNSResponder fetches the full chain (icann.org A/DNSKEY/DS, org DNSKEY/DS, root DNSKEY) from the local resolver. All records are present and all signatures validate. After the root DNSKEY query concludes, no validation result is logged, no result or error is delivered to the getaddrinfo request, and later requests for the same name attach as duplicates to the stuck questions and also never return. Without DNSSEC required, the connection succeeds immediately. Suspected cause: KSK-2024 missing from the built-in trust anchors. Secondary issue: validation failure is not reported to the client; the request hangs indefinitely.

Title: NEFilterDataProvider — fail-closed behaviour after provider crash or suspension I'm investigating the documented failure behaviour of NEFilterDataProvider on macOS. For a content filter handling outbound socket flows: If the data provider process crashes, is terminated, or disconnects unexpectedly, what happens to existing allowed, paused and partially released flows? If the provider is suspended or its callback queue stops making progress, does macOS retain existing verdicts indefinitely, block further data, or apply some other behaviour? Can an existing passBytes allowance remain usable after the provider becomes unavailable? Is there a supported mechanism for independently confirming that all relevant existing flows and outstanding release allowances have been fenced? I'm particularly interested in documented guarantees, rather than implementation behaviour observed in individual tests. Any relevant Apple API documentation or technical clarification would be appreciated.

Windows 11 Pro 25H2 – Bonjour 3.1.0.1 / mdnsNSP.dll – Code Integrity Event ID 3033 Hello Apple Developer Community, I am seeking technical assistance with a persistent Windows Code Integrity event involving Apple's Bonjour for Windows, specifically mdnsNSP.dll. PowerShell diagnostics, signature checks, service checks, Winsock inspection, and Event Viewer analysis have not yet established a permanent fix. I would appreciate guidance from Apple engineers or developers familiar with Bonjour, Winsock Name Space Providers, and Windows signing policies. 1. SYSTEM Windows 11 Pro 25H2, build 26200 iTunes 12.10.11.2 (classic Windows desktop application) Bonjour 3.1.0.1 Bonjour directory: C:\Program Files\Bonjour\ Affected file: C:\Program Files\Bonjour\mdnsNSP.dll Reported DLL version: 3.1.0.1; reported date: August 12, 2015 iTunes manages a large local music library. The existing iTunes application, its library database, metadata, and media files must be preserved. I do not want to migrate to Apple Music or Apple TV. 2. ERROR AND EVIDENCE Windows Event Viewer reports: Provider: Microsoft-Windows-CodeIntegrity Event ID: 3033 Affected process: C:\Windows\System32\svchost.exe Referenced DLL: C:\Program Files\Bonjour\mdnsNSP.dll The diagnostic message indicates that the DLL does not meet the Microsoft signing-level requirements of the affected process. Yet signature verification reports a valid Apple digital signature. I have not determined the precise policy requirement or root cause. A signing-level incompatibility with Windows 11 25H2 is a possibility, not an established finding. This event alone does not prove that Bonjour as a whole is broken or that the DLL has a security vulnerability. 3. FINDINGS AND CHECKS Bonjour service: startup type Automatic; status Running. mDNSResponder.exe is running. This does not prove that every Bonjour component works. mdnsNSP.dll: publisher Apple; digital signature reported Valid. Winsock catalog: two entries reference mdnsNSP.dll. Whether these are expected separate registrations is not yet established. Examined Bonjour components, versions, service and process status, digital signatures, Windows networking configuration, Winsock catalog, and Event Viewer using PowerShell and Windows tools. No permanent repair has been confirmed. No broad Winsock reset or speculative registry modification is desired. 4. QUESTIONS 1) Is Bonjour 3.1.0.1, especially mdnsNSP.dll, known to have a compatibility or signing-level issue on Windows 11 25H2? 2) Why might an Apple-signed DLL with a valid Authenticode signature not meet the signing-level requirements of the svchost.exe process attempting to load it? Which diagnostics identify the exact policy? 3) What is the latest Apple-supported Bonjour version for this Windows environment? Is there a supported repair or update path independent of classic iTunes? 4) Is it normal for mdnsNSP.dll to appear twice in the Winsock catalog? If so, why? 5) Can Bonjour be repaired or reinstalled without modifying iTunes 12.10.11.2 or its library, and without disrupting other Winsock providers or network services? 6) Would the full Event ID 3033 XML, DLL signature details, and relevant Winsock entries help Apple determine the root cause? I can share appropriately redacted diagnostics on request. 5. SECURITY AND PRESERVATION REQUIREMENTS I am looking for a documented, targeted, reversible where possible, and lasting solution—not merely a way to silence Event ID 3033. Please do not recommend disabling Code Integrity, Memory Integrity, or other Windows protections. The repair must not introduce security risks or impair other applications, network providers, or Windows services. I want to retain iTunes 12.10.11.2 and the entire music library, and avoid reinstalling Windows or installing Apple Music/TV. I am comfortable running specific PowerShell diagnostics and reporting results. Personal identifiers, addresses, and unredacted logs have intentionally been excluded from this public report. Thank you for your technical guidance. REFERENCES Apple Bonjour: https://developer.apple.com/bonjour/ Microsoft Windows Security: https://support.microsoft.com/en-us/windows/security/windows-security/device-security-in-the-windows-security-app#bkmk_lsa-protection Microsoft Learn (LSA protection / Code Integrity events): https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

I'm trying to invoke a 3rd party command line tool from a launch agent to connect to a server on my LAN. It seems impossible. I have a little shell script that does what I need, and it works fine invoked in Terminal.app. The first time I run it that way I get permission prompts and I agree to them all. Subsequent invocations work. Now I put a launch agent in ~/Library/Launch Agents. It does nothing more than invoke my shell script at some specific time daily. launchd launches it, but it fails to access the LAN, with a 'no route to host' error message. The command line tool I'm trying to use is not a macOS-provided one, but one from MacPorts/HomeBrew (I tried both). It doesn't even matter which tool I'm using, I tried a very simple case of just using nc/netcat. If I use the macOS-provided nc, then I can access my LAN. If I install nc from MacPorts /HomeBrew, that nc cannot access my LAN. This I've reproed on a literally brand new Mac, then updated to newest Sequoia (15.3.2), then done all I've described above. I've ruled out DNS by working with raw IP addresses. I've disabled gatekeeper with sudo spctl --master-disable. I've tried using cron instead of launch agents, same results. I've tried codesigning with codesign -dvvv /opt/homebrew/bin/nc, no help. I've read TN3179 Understanding local network privacy. In summary: Terminal.app -> script -> macOS/brew nc -> internet/LAN = works launchagent -> script -> macOS nc -> internet = works launchagent -> script -> macOS nc -> LAN = works launchagent -> script -> brew nc -> internet = works launchagent -> script -> brew nc -> LAN = fails How can I make that last case work?

libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.

We run a Wi-Fi network with our own captive portal and want iOS clients to be told that Private Relay is not available here, as described in Prepare your network or web server for iCloud Private Relay and WWDC21 session 10096. Our setup: Resolver: Unbound, handed out via DHCP, with local-zone: "mask.icloud.com" always_nxdomain and local-zone: "mask-h2.icloud.com" always_nxdomain. The network is IPv4-only. The captive portal intercepts all UDP port 53 traffic and drops everything else (e.g. port 853). TCP port 53 is not served. We also tried NXDOMAIN for mask-api.icloud.com, apple-native-relay.apple.com, mask.apple-dns.net, mask-api.fe.apple-dns.net and mask-t.apple-dns.net, with no change. [Result of our resolver log: do queries for the mask hosts arrive from the test iPhone, and what do we answer? Before and after captive-portal login?] What the documentation promises: “users will be alerted that they need to either disable Private Relay for that network, or choose another network.” What happens: On [iPhone model], iOS [exact version/build], with Private Relay enabled in iCloud settings and “Limit IP Address Tracking” [on/off] for this Wi-Fi, joining our network shows no message at all. [What the user sees instead: Safari loads normally / pages fail / nothing changes.] Counter-observation: On a hotel guest network (Marriott) the same kind of device did show a notice, so the feature seems to still work on current iOS. We do not know how that network blocks Private Relay. Related reports: thread 687684 and thread 722315 describe a similar gap (network-level NXDOMAIN gives no alert, on-device DNS filtering does). Our own report: FB[number], no response so far. Questions: Which conditions must be met for iOS to show the message? Is NXDOMAIN for the two documented names enough, or does the alert also depend on other hostnames, the DNS response type (NXDOMAIN vs. NODATA), or the state of the network (e.g. before/after captive login)? Is the alert suppressed when “Limit IP Address Tracking” was turned off for that Wi-Fi earlier, or when Private Relay has already connected successfully on another network? Is the documentation still accurate for current iOS releases? If not, could it be updated?