I am testing NEURLFilter on macOS using the SimpleURLFilter sample, and I am seeing a failure from neagent while it is saving the local URL prefilter Bloom filter to its mmap file. The relevant log is: neagent +[NEBloomFilter mmapToFile:data:dataLength:numberOfBits:numberOfHashes:murmurSeed:tag:]: NEBloomFilter - failed to open mmap file /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF <errno 13 - Permission denied> neagent <NEAgentURLFilterExtension: 0xc8ce64280>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to save first fetch of pre-filter data Environment: macOS: 26.5.1 (25F80) Xcode: 26.5 (17F42) Platform: macOS Signing type: Apple Development (automatically manage signing) What I am doing: Build and run the containing app. Save and enable the NEURLFilterManager configuration. The URL filter provider starts. The provider's prefilter code is reached. neagent logs the mmap failure above while trying to open a temporary file under /private/var/db/urlPrefilter. Expected result: neagent should be able to create or open its system-managed URL prefilter cache / mmap file under /private/var/db/urlPrefilter, and the local Bloom filter should be loaded successfully. Actual result: neagent fails to open the temporary mmap file with errno 13 Permission denied: /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.<bundle/team-specific suffix> I am not manually creating, modifying, or chmod/chown-ing /private/var/db/urlPrefilter or anything inside it. The directory and its contents are entirely system-managed. The failure appears to happen inside neagent while it is handling the system-managed URL prefilter cache. The failure occurs at the mmapToFile: step while neagent saves the Bloom filter prefilter data. Directory state: drwxr-xr-x 2 root wheel 64 /private/var/db/urlPrefilter Has anyone else encountered this? Any suggestions on what could cause neagent to fail with errno 13 on its own mmap file under /private/var/db/urlPrefilter?

Hello, Feedback Assistant report: FB24876147. I develop a Unity-based iOS app. Some customers in mainland China report losing Internet access after an app update, while most installations continue working. We have received similar reports since at least iOS 16, across several years and multiple app releases. Earlier iOS versions are uncertain, and we cannot confirm that all historical occurrences share the same cause. Updates without networking-code changes can be followed by failures. A later update sometimes restores connectivity, but not consistently. Customer-reported recovery attempts: The app's wireless-data permissions appear enabled in Settings. Switching the app's network permission to another setting and back did not help users who reported trying it. Reset Network Settings also did not help users who reported trying it. Some users reported that deleting and reinstalling the app restored connectivity. At least one user reported that deletion and reinstallation did not help. These are customer reports, not controlled tests on our development devices. We would prefer a recovery that preserves local save data. Captured evidence from one affected installation: App version 1.89, build 1; Unity 2022.3.62f3. Device identifier: iPhone18,1; iOS 26.2.1. App in foreground. Capture time: 2026-09-07 13:04:31–13:04:32 UTC. An unfiltered Network.framework default-path monitor reported: status=unsatisfied reason=wifiDenied interface=Wi-Fi UnityWebRequest and a newly created native ephemeral NSURLSession both failed against our public HTTPS origin and Apple's independent test endpoint: https://www.apple.com/library/test/success.html The native requests failed after approximately 1 ms and 3 ms, with NSURLErrorDomain -1009, underlying kCFErrorDomainCFNetwork -1009, and no HTTP response. The native session allowed cellular, expensive and constrained network access, used normal TLS verification, and had waitsForConnectivity=false. It bypassed Unity's reachability precheck. CTCellularData changed from unknown to notRestricted. We understand this does not establish successful cellular connectivity or Wi-Fi permission. Important limitations: The native probes ran inside the same Unity-built process, not a separate standalone native app. The captured measurements demonstrate a Wi-Fi failure. Cellular failures and enabled Settings permissions are customer reports, not independently verified by these measurements. We cannot reliably reproduce the affected state on our development devices and do not have a focused Xcode project that reproduces it. An affected-device sysdiagnose is not yet available. Unity Customer QA reviewed this evidence, assessed it as an iOS network-policy issue rather than a Unity bug, and referred us to Apple. We are seeking Apple's investigation, not presenting that assessment as a confirmed root cause. The Code-Level Support form directed us to these forums because we cannot currently provide a focused reproducer. Questions: Which affected-device diagnostics or logging profiles would help identify why the effective network policy reports wifiDenied? How should we investigate an installation-specific issue when a new minimal app may not reproduce that installation state? Is there a supported, data-preserving recovery or application-side mitigation when permission changes and network resets do not help, and reinstallation is not consistently effective? We have diagnostic screenshots and relevant probe source available. Any customer system logs would be collected with consent and shared privately with Apple, not posted publicly. Thank you.

As part of the OpenJDK testing we run several regression tests, including for Java SE networking APIs. These APIs ultimately end up calling BSD socket functions. On macos, starting macos 26, including on recent 26.2 version, we have started seeing some unexplained but consistent exception from one of these BSD socket APIs. We receive a "ENOBUFS" errno (No buffer space available) when trying to construct a socket(). These exact same tests continue to pass on many other older versions of macos (including 15.7.x). After looking into this more, we have been able to narrow this down to a very trivial C code which is as follows (also attached): #include <stdio.h> #include <sys/socket.h> #include <string.h> #include <unistd.h> #include <sys/errno.h> static int create_socket(const int attempt_number) { const int fd = socket(AF_INET6, SOCK_STREAM, 0); if (fd < 0) { fprintf(stderr, "socket creation failed on attempt %d," " due to: %s\n", attempt_number, strerror(errno)); return fd; } return fd; } int main() { const unsigned int num_times = 250000; for (unsigned int i = 1; i <= num_times; i++) { const int fd = create_socket(i); if (fd < 0) { return -1; } close(fd); } fprintf(stderr, "successfully created and closed %d sockets\n", num_times); } The code very trivially creates a socket() and close()s it. It does this repeatedly in a loop for a certain number of iterations. Compiling this as: clang sockbufspaceerr.c -o sockbufspaceerr.o and running it as: ./sockbufspaceerr.o consistently generates an error as follows on macos 26.x: socket creation failed on attempt 160995, due to: No buffer space available The iteration number on which the socket() creation fails varies, but the issue does reproduce. Running the same on older versions of macos doesn't reproduce the issue and the program terminates normally after those many iterations. Looking at the xnu source that is made available for each macos release here https://opensource.apple.com/releases/, I see that for macos 26.x there have been changes in this kernel code and there appears to be some kind of memory accountability code introduced in this code path. However, looking at the reproducer/application code in question, I believe it uses the right set of functions to both create as well as release the resources, so I can't see why this should cause the above error in macos 26.x. Does this look like some issue that needs attention in the macos kernel and should I report it through feedback assitant tool?

Hello, I am tracking a severe local networking regression on macOS Golden Gate 27.2 Developer Beta (build 26B5086k) running on MacBook Pro M4 Pro hardware. Despite negotiating a strong physical Wi-Fi connection with high PHY rates (1200+ Mbps) and excellent RSSI, actual throughput collapses dramatically and local gateway latency spikes uncontrollably whenever AWDL and AirDrop discovery are actively processing. Key Diagnostic Metrics Observed AWDL Manually Disabled: Executing sudo ifconfig awdl0 down completely drops packet loss to 0%, stabilizes gateway latency entirely, and restores baseline throughput. AirDrop Turned Off (AWDL Active): Disabling AirDrop via System Settings while keeping AWDL active stops the catastrophic latency spikes. This strongly suggests the trigger is linked directly to AirDrop's continuous background discovery/scanning activity rather than basic AWDL link states. Environment Isolation Performed Safe Mode: The issue persists cleanly while booted into macOS Safe Mode, ruling out third-party launch kexts, background daemons, or custom VPN software. Cross-AP Testing: The behavior follows the Mac across completely different access points, occurring on a dedicated Wi-Fi 7 home environment (tested across 5GHz and 6GHz channels) as well as an iPhone Personal Hotspot over cellular. Control Device: Same-location control testing with an iPhone shows perfect gigabit-class speeds, confirming the RF environment and network backhaul are perfectly healthy. I have already submitted a comprehensive sysdiagnose archive and wireless diagnostic log package directly to Apple. Feedback ID: FB24842970 Curious if anyone else with an M4 Pro on this build is seeing similar behavior. If this is happening on your end too, it might be worth submitting a bug report and referencing FB24842970 so Apple can group our logs together and look into a patch.

The documentation is pretty much blank. The same thing applies to the root NetworkProtocolOptions protocol. What are ContentType, LegacyMessage, BelowProtocol, Metadata, and ProtocolStorage? I can't determine if I should use these or not.

Hello! Users of my app observed behaviour that some apps stopped working after update to 15.7.8 via Beta channel with transparent proxy network extension on. The app receives Protocol not available error, and I see setsockopt SO_FLOW_DIVERT_TOKEN failed [42: Protocol not available] error in Console. To reproduce, create two rules in basic NETransparentProxyProvider: [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolTCP], [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolUDP], You may even return NO in handleNewFlow, it does not matter. After that, Safari won't open some sites, and Weather app will work unreliably. Do anyone knows any workaround for this problem? I've also create a relevant FB23788740.

Summary On macOS 26.6.2 (25G83) (Tahoe), Chrome fails to load pages hosted on private/local IP addresses (e.g. http://192.168.0.43/, a home AV receiver's web setup page) with ERR_ADDRESS_UNREACHABLE, while Safari loads the identical URL without issue on the same Mac, same network. ping to the target IP succeeds normally. System Settings > Privacy & Security > Local Network shows "Allow" for Chrome — but this is not what's actually being enforced. Traced the root cause to nesessionmanager stuck in an infinite retry loop when attempting to install/update NetworkExtension path-rule policies. Because the daemon never completes a successful policy install, nehelper (the actual enforcement point) continues serving a stale cached "denied" decision indefinitely, regardless of what the Settings UI shows or how many times the toggle is flipped. Key evidence Chrome netlog (chrome://net-export/) shows a genuine TCP connect attempt (not an early permission rejection): text TCP_CONNECT_ATTEMPT --> address = "192.168.0.43:80" -TCP_CONNECT_ATTEMPT --> os_error = 65 -TCP_CONNECT --> net_error = -109 (ERR_ADDRESS_UNREACHABLE) os_error = 65 is BSD EHOSTUNREACH, returned by the kernel at the connect() syscall. Unified log (log stream --predicate 'subsystem == "com.apple.networkextension"') shows the actual enforcement decision: text nehelper: UUID cache hit for com.google.Chrome nehelper: Local network denied by preference for Google Chrome (com.google.Chrome) This reproduced identically across multiple attempts, minutes apart, and survived sudo pkill -f nehelper — confirming the decision is persisted, not just an in-memory cache. While toggling the Local Network switch in System Settings, expecting a pathRules dump, the log instead showed: text NESMPathControllerSession[...]: No UUIDs in the cache for PathRuleDefaultNonSystemIdentifier, populating the cache from the path rules NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 1 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 2 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 3 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 4 NESMPathControllerSession[...]: Will reinstall policies after 2000 milliseconds, retry 5 The retry counter kept incrementing with no observed successful completion, meaning any change made via the System Settings toggle can never actually propagate to nehelper. Also confirmed Local Network privacy is not TCC-backed at all: text $ sudo tccutil reset LocalNetwork tccutil: Failed to reset LocalNetwork $ sudo tccutil reset LocalNetwork com.google.Chrome tccutil: Failed to reset LocalNetwork approval status for com.google.Chrome Both fail outright rather than erroring on bad usage, confirming this permission lives entirely in the NetworkExtension path-rule system, with no supported reset command. What did not fix it Toggling the Settings UI switch off/on sudo tccutil reset SystemPolicyNetworkVolumes (wrong TCC service — doesn't apply here) sudo tccutil reset LocalNetwork (fails, see above) Full clean reinstall of Chrome, including all Application Support/Caches/Preferences Safe Mode boot sudo pkill -f nehelper Full normal system restart Launching Chrome with --no-sandbox (rules out Chromium's own internal sandbox as a factor — this is a system-level enforcement, not a Chromium-side block) Working fix Requires temporarily disabling SIP: text In macOS Recovery (csrutil only works from Recovery, not Safe Mode): csrutil disable Back in normal macOS: sudo rm /Library/Preferences/com.apple.networkextension.plist Back in Recovery: csrutil enable Restart normally. nesessionmanager rebuilds the NetworkExtension policy state from scratch on next boot. System Settings > Privacy & Security > Local Network shows a clean list afterward (also clears the separate, previously-known bug where every Chrome auto-update was creating a new duplicate entry in that list rather than updating the existing one). Chrome's next navigation attempt to a local IP correctly triggers a fresh permission prompt, and functions normally once granted. Why this matters Apple's own TN3179 states there's no supported way to reset an app's Local Network privilege to "undetermined." This bug compounds that: once nesessionmanager gets stuck in this retry loop, there is no path back to a working state short of disabling SIP and manually deleting a system preference file. The Settings UI also actively misrepresents the true enforcement state (shows "Allow" while nehelper enforces "denied") with no indication to the user that anything is wrong. This is likely not Chrome-specific — any app relying on Local Network access (smart-home apps, casting/streaming apps, IoT config tools) would hit the identical wall once a Mac's nesessionmanager enters this state. Also filed via Feedback Assistant. Happy to share the full decoded netlog trace if useful — didn't attach it here to keep this post scannable, but can paste the additional detail on request.

Hello, I'm desperately looking for a way to purge the contents of the Local Network allowlist in System Settings. Every version of a test app I've ever used gets an entry in there, and apparently so does each build of Chrome and Claude Code. Claude recommended I include the following context, and if there's a specific answer to that, great, but any way of purging this list would make me very happy. ==== Caution: slop below this line ==== macOS 27.0 (26A428), Apple silicon. The Local Network list has 471 entries, many dead: Chrome code_sign_clone paths that no longer exist, old ad-hoc builds, uninstalled apps. The pane can't remove any. Is there a supported way to remove entries or reset the list, short of Recovery? Editing /Library/Preferences/com.apple.networkextension.plist as root fails with EPERM, both rename-over and open-for-write. New files in that directory work. SIP is on, the file has no flags or xattrs, Full Disk Access didn't help, and there are no Sandbox/TCC denials in the log. What protects this file?

Hello everyone, I found an interesting post by a developer on social media that mentions that Apple has provided a new configuration profile. Is this a new feature? Does anyone have any additional information about it? And can anyone provide me with the link to download this profile?

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses. As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all. Here are important and related points: Our application is packaged as a .app package and distributed independently (not on the App Store). The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back. However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data. The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon. Workarounds that have been tried: Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here. Firewall: No difference is seen in behaviour with firewall being ON OR OFF. Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices. Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution. How can we get this bug/issue fixed in macOS Sequoia (and above)? Are there any other solutions/workarounds that we can try on our end?

We have a NEPacketTunnelProvider extension that intercepts and modifies DNS responses for specific hostnames as part of its normal operation. On iOS 27, we are seeing this interception being intermittently bypassed. Our extension still receives the DNS query, builds a response, and returns it promptly, but the client occasionally proceeds using a different address, presumably the actual DNS resolution result. This behavior does not reproduce on iOS 26 or earlier. The timing in our logs appears to correlate with the new Connectivity Assist feature (Settings → Wi-Fi), which Apple describes as using cellular data alongside Wi-Fi to improve reliability. Our suspicion is that Connectivity Assist may be performing DNS resolution over a cellular path in parallel, outside the tunnel, causing that resolution path to bypass our provider entirely. We have ruled out response timing and response format issues on our side. Varying the speed and format of our responses does not affect the outcome, suggesting that the behavior is occurring at a layer above the tunnel provider. We have the following questions: Does Connectivity Assist perform DNS resolution on a network path that can bypass an active NEPacketTunnelProvider? Is there any API, entitlement, or supported mechanism to disable Connectivity Assist for an app, or to ensure that all DNS resolution is routed through the active tunnel, similar to previous Wi-Fi Assist opt-out capabilities? Would a NEDNSProxyProvider-based DNS proxy be affected in the same way, or does it operate at a layer that Connectivity Assist cannot bypass? Any guidance, references to relevant documentation, WWDC session content, or confirmation of the expected behavior would be greatly appreciated.

I applied on the Multicast Networking Entitlement Request site, but I did not receive a response email. How long does a response usually take?

Hello, I am investigating a roaming network selection use case on iPhone and would like to know whether Apple provides any supported API, entitlement, carrier capability, or carrier-specific integration that allows an application or a mobile network operator to access or control PLMN selection while roaming. My specific use case is: Device: iPhone 17 iOS: 26.6.1 Home operator: Orange France Roaming country: Switzerland Automatically selected roaming network: Salt Preferred roaming network: Swisscom At this location, Salt has very poor cellular coverage while Swisscom has excellent coverage. The user can manually select Swisscom through: Settings → Cellular → Network Selection → Swisscom I would like to determine whether there is any supported mechanism for a carrier or a carrier-authorized application to: Read the currently selected roaming PLMN. Obtain the available roaming PLMNs. Programmatically select a specific PLMN. Configure a preferred roaming PLMN. Ask the modem to prefer one roaming partner over another. Access any carrier-only/private entitlement that provides such functionality. For example, could an authorized Orange carrier application or carrier integration request that Swisscom (MCC 228 / MNC 01) be preferred over Salt (MCC 228 / MNC 03) while roaming in Switzerland? I understand that Core Telephony provides access to some carrier information and that certain capabilities require Apple-granted entitlements. If this functionality is not available to third-party applications, is there a carrier integration, carrier configuration, SIM/eSIM profile mechanism, or other Apple-supported mechanism that can influence the preferred roaming PLMN? I am specifically looking for a supported solution and not a jailbreak or other unsupported/private API. Thank you.

I am developing an iOS application for carrier network testing and diagnostics, and I need to access the following cellular, carrier, subscriber, and device information: RSRP RSRQ SINR RSSI PCI Cell ID LTE/5G Band EARFCN / NRARFCN Carrier name Country code MCC MNC Mobile/subscriber number IMEI Enable/Disable/connect wifi Enable/Disable hotspot Insert/update/delete e-sim I understand that some or all of this information is not available through Apple’s public iOS APIs. My question is: If I request Apple’s Interoperability Access or a carrier-related entitlement for an application developed specifically for carrier network testing and diagnostics, can these APIs/data become available? If yes, could someone please clarify: Which of the above data points can be accessed with carrier-related entitlements? Which specific entitlements or APIs are required? Are RSRP, RSRQ, SINR, RSSI, PCI, Cell ID, Band, and EARFCN/NRARFCN available through any Apple-approved entitlement? Can carrier information such as carrier name, MCC, MNC, and country code be accessed? Is mobile/subscriber number accessible? Is IMEI accessible with a carrier entitlement? Is there a specific Apple WWDR/Interoperability request process for these requirements? This is for a legitimate carrier testing/diagnostics application. I would appreciate any clear guidance on what is technically possible on current iOS versions and which Apple approval/entitlement process I should follow.

I have a watchOS app on a cellular Apple Watch (Series 11, watchOS 26.6) that periodically uploads small HTTPS payloads to a backend. It needs to keep working when the paired iPhone is absent and the watch is on its own cellular connection. What I observe: Foreground, no phone, cellular: uploads work. Background, no phone, cellular-only (no Wi‑Fi): nothing uploads for hours. The instant the watch joins Wi‑Fi (app still in background): the whole backlog flushes at once via my background URLSession. My questions: Is a background URLSession transfer over cellular ever expected to run without Wi‑Fi (e.g. while charging), or is Wi‑Fi effectively required in practice? Any configuration that improves the odds? 2. During an active HKWorkoutSession (which keeps the app executing), will a high-level URLSession data task reliably complete over cellular with the phone absent? And is using a workout session to keep a non-fitness background uploader alive acceptable, or is there a sanctioned alternative? 3. Is there any other supported mechanism for periodic background cellular upload from a phoneless watch that I'm missing? Any help would be greatly appreciated. Thank you!

We ship a consumer VPN app on iOS, iPadOS and tvOS using a Personal VPN configuration: NEVPNManager with NEVPNProtocolIKEv2, EAP-MSCHAPv2, no MDM profile installed. After exactly 120 seconds with no traffic, iOS destroys the Child SA and disconnects the tunnel. I would like to know whether that timer is configurable, and if not, what the intended mitigation is. From a device sysdiagnose (iPhone, iOS 26.6, build 23G71): NEIPSecDBStatsUpdate: SA is idle for past 120 secs KernelSASession[1, IKEv2 Session Database] idle timeout SA Internal SAID = 2 SPI = C53320D1 Direction = Outbound ChildSA[1] state Connected -> Disconnected error Domain=NEIKEv2ErrorDomain Code=15 "IdleTimeout" <NEIKEv2Provider: Primary Tunnel>: stopping tunnel since Child disconnected nesessionmanager: plugin disconnected with reason "Tunnel was idle for too long" This happened 12 times across a 9.2 hour overnight capture on one idle device. Median time before the tunnel re-established was 14m35s. DISCONNECT-ON-IDLE IS NOT ENABLED The same sysdiagnose shows the plugin's own configuration as: disconnectOnIdle = NO disconnectOnIdleTimeout = 0 These are the stock defaults. There is no disconnectOnIdle property on the public NEVPNProtocol, so a Personal VPN app cannot set them either way. The installed SA parameters contain no idle field at all, only "Lifetime Seconds = 1800", which is honoured correctly: the same capture shows 20 clean rekey cycles. WHAT I HAVE RULED OUT iOS logs a distinct stop reason for each of the following, and none of them occurred across 24 teardowns: "On Demand Disconnect rule matched", "Tunnel was terminated by the server", "Server is not responding", "Network changed, tunnel no longer viable", "Device went to sleep", "Stop command received". The only reason recorded was "Tunnel was idle for too long". On the gateway (strongSwan), IKE rekey and reauth are disabled, uniqueids is never, and DPD is answered in roughly 200ms right up to the teardown. The gateway considers the tunnel healthy at the moment iOS tears it down. DPD does not reset the timer, which makes sense: DPD is an INFORMATIONAL exchange on the IKE SA, whereas the log shows the timer measuring the OUTBOUND Child SA (SAID 2). THE APP CANNOT SEE THIS HAPPEN NEVPNConnection.fetchLastDisconnectError() returns nil for this teardown, because the error is in NEIKEv2ErrorDomain rather than NEVPNConnectionErrorDomain. The app has no supported way to detect that the tunnel dropped for this reason, or to distinguish it from a user-initiated disconnect. It is only visible in a sysdiagnose. TRAFFIC IS NOT HELD DURING THE RECONNECT With Connect On Demand enabled (NEOnDemandRuleConnect, interfaceTypeMatch .any), traffic after the teardown does not wait for the tunnel. On device wake following one of these drops: 01:32:43 device wakes 01:32:43 [C331 ... :443] path:satisfied @0.001s, interface: en0[802.11], uses wifi 01:32:44 [C331 ... :443] flow:finish_connect @0.623s (over en0) 01:32:47 tunnel status changed to connected so flows complete over the physical interface for several seconds before the VPN re-establishes. On-demand triggered the reconnect but did not delay the traffic. For a VPN product this window is the part that concerns me most. QUESTIONS Is the 120 second Child SA idle timeout configurable for a Personal VPN using NEVPNProtocolIKEv2, from the app or from a configuration profile? If DisconnectOnIdle / DisconnectOnIdleTimer are meant to control it, why does the teardown occur when they are NO / 0? If it is not configurable, is application-generated keepalive traffic the intended workaround? If so, how is that expected to work while iOS has the app suspended, which is exactly when a tunnel goes idle? Would server originated traffic that elicits a client response be a supported approach? Is there any supported way for an app to be notified of this teardown, given that fetchLastDisconnectError() returns nil for it? Is the behaviour in "traffic is not held during the reconnect" expected for NEOnDemandRuleConnect, or should matching flows be delayed until the tunnel is up? Is includeAllNetworks the only supported way to close that window? Happy to supply the full sysdiagnose privately.

For a given instantiation, is the Instance object passed to each method of NWProtocolFramerImplementaion the same? If that includes the initializer, why do the other methods still want it?

I am developing an iOS app that uses Core NFC to communicate with an ISO 14443 / ISO 7816 smart card. For security reasons, I would like to minimize or temporarily prevent other external communications while an NFC read/write session is active. My questions are: Is there any supported iOS API or entitlement that allows an app to temporarily disable or block Wi-Fi, cellular, or Bluetooth communication while a Core NFC session is active? If device-wide communication cannot be controlled by a third-party app, is there a supported way to guarantee that the app’s own process performs no network communication during that NFC session? Does Apple recommend any architecture or security practice for implementing an offline-only Core NFC read/write operation? The NFC communication itself must remain available during the operation. Thank you.

I have written a small Python program that needs to continuously listen on port 2237. The packets are received from one program, which I will call P1. There is also another program, P2, that receives commands from P1. Both P1 and P2 use port 2237. My problem is that when I start my Python script, it successfully receives data from P1, but it fails to receive data from P2. The functionality only works again after I stop my program. The Python script for receiving the packets is: def run(udp_port: int): logger.info("Starting listener on port %d", udp_port) client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) client.setsockopt() client.bind(("", udp_port)) while True: data, addr = client.recvfrom(4096) src_ip, src_port = addr logger.debug("Received %d bytes from %s:%d", len(data), src_ip, src_port) hexdump(data, logging.DEBUG) try: payload = parse_message(data) if payload is not None: logger.info("%r", payload) except Exception as e: logger.error("Failed to parse header: %s", e) Does anyone know what the root cause of this issue is, and how we can fix it?

I have written a small Python program that needs to continuously listen on port 2237. The packets are received from one program, which I will call P1. There is also another program, P2, that receives commands from P1. Both P1 and P2 use port 2237. My problem is that when I start my Python script, it successfully receives data from P1, but it fails to receive data from P2. The functionality only works again after I stop my program. The Python script for receiving the packets is: def run(udp_port: int): logger.info("Starting listener on port %d", udp_port) client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) client.setsockopt() client.bind(("", udp_port)) while True: data, addr = client.recvfrom(4096) src_ip, src_port = addr logger.debug("Received %d bytes from %s:%d", len(data), src_ip, src_port) hexdump(data, logging.DEBUG) try: payload = parse_message(data) if payload is not None: logger.info("%r", payload) except Exception as e: logger.error("Failed to parse header: %s", e) What could be causing this conflict? Is there a known issue where an active UDP listener process interferes with two other applications (P1 and P2) communicating on the same port? Any ideas or suggested workarounds would be helpful!