For important background information, read Extra-ordinary Networking before reading this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Broadcasts and Multicasts, Hints and Tips I regularly see folks struggle with broadcasts and multicasts on Apple platforms. This post is my attempt to clear up some of the confusion. This post covers both IPv4 and IPv6. There is, however, a key difference. In IPv4, broadcasts and multicasts are distinct concepts. In contrast, IPv6 doesn’t support broadcast as such; rather, it treats broadcasts as a special case of multicasts. IPv6 does have an all nodes multicast address, but it’s rarely used. Before reading this post, I suggest you familiarise yourself with IP addresses in general. A good place to start is The Fount of All Knowledge™. Service Discovery A lot of broadcast and multicast questions come from folks implementing their own service discovery protocol. I generally recommend against doing that, for the reasons outlined in the Service Discovery section of Don’t Try to Get the Device’s IP Address. There are, however, some good reasons to implement a custom service discovery protocol. For example, you might be working with an accessory that only supports this custom protocol [1]. If you must implement your own service discovery protocol, read this post and also read the advice in Don’t Try to Get the Device’s IP Address. IMPORTANT Sometimes I see folks implementing their own version of mDNS. This is almost always a mistake: If you’re using third-party tooling that includes its own mDNS implementation, it’s likely that this tooling allows you to disable that implementation and instead rely on the Bonjour support that’s built-in to all Apple platforms. If you’re doing some weird low-level thing with mDNS or DNS-SD, it’s likely that you can do that with the low-level DNS-SD API. [1] And whose firmware you can’t change! I talk more about this in Working with a Wi-Fi Accessory. API Choice Broadcasts and multicasts typically use UDP [1]. TN3151 Choosing the right networking API describes two recommended UDP APIs: Network framework BSD Sockets Our general advice is to prefer Network framework over BSD Sockets, but UDP broadcasts and multicasts are an exception to that rule. Network framework has very limited UDP broadcast support. And while it’s support for UDP multicasts is less limited, it’s still not sufficient for all UDP applications. In cases where Network framework is not sufficient, BSD Sockets is your only option. [1] It is possible to broadcast and multicast at the Ethernet level, but I almost never see questions about that. UDP Broadcasts in Network Framework Historically I’ve claimed that Network framework was useful for UDP broadcasts is very limited circumstances (for example, in the footnote on this post). I’ve since learnt that this isn’t the case. Or, more accurately, this support is so limited (r. 122924701) as to be useless in practice. For the moment, if you want to work with UDP broadcasts, your only option is BSD Sockets. UDP Multicasts in Network Framework Network framework supports UDP multicast using the NWConnectionGroup class with the NWMulticastGroup group descriptor. This support has limits. The most significant limit is that it doesn’t support broadcasts; it’s for multicasts only. Note This only relevant to IPv4. Remember that IPv6 doesn’t support broadcasts as a separate concept. There are other limitations, but I don’t have a good feel for them. I’ll update this post as I encounter issues. Local Network Privacy Some Apple platforms support local network privacy. This impacts broadcasts and multicasts in two ways: Broadcasts and multicasts require local network access, something that’s typically granted by the user. Broadcasts and multicasts are limited by a managed entitlement (except on macOS). TN3179 Understanding local network privacy has lots of additional info on this topic, including the list of platforms to which it applies. Send, Receive, and Interfaces When you broadcast or multicast, there’s a fundamental asymmetry between send and receive: You can reasonable receive datagrams on all broadcast-capable interfaces. But when you send a datagram, it has to target a specific interface. The sending behaviour is the source of many weird problems. Consider the IPv4 case. If you send a directed broadcast, you can reasonably assume it’ll be routed to the correct interface based on the network prefix. But folks commonly send an all-hosts broadcast (255.255.255.255), and it’s not obvious what happens in that case. Note If you’re unfamiliar with the terms directed broadcast and all-hosts broadcast, see IP address. The exact rules for this are complex, vary by platform, and can change over time. For that reason, it’s best to write your broadcast code to be interface specific. That is: Identify the interfaces on which you want to work. Create a socket per interface. Bind that socket to that interface. Note Use the IP_BOUND_IF (IPv4) or IPV6_BOUND_IF (IPv6) socket options rather than binding to the interface address, because the interface address can change over time. Extra-ordinary Networking has links to other posts which discuss these concepts and the specific APIs in more detail. Miscellaneous Gotchas A common cause of mysterious broadcast and multicast problems is folks who hard code BSD interface names, like en0. Doing that might work for the vast majority of users but then fail in some obscure scenarios. BSD interface names are not considered API and you must not hard code them. Extra-ordinary Networking has links to posts that describe how to enumerate the interface list and identify interfaces of a specific type. Don’t assume that there’ll be only one interface of a given type. This might seem obviously true, but it’s not. For example, our platforms support peer-to-peer Wi-Fi, so each device has multiple Wi-Fi interfaces. When sending a broadcast, don’t forget to enable the SO_BROADCAST socket option. If you’re building a sandboxed app on the Mac, working with UDP requires both the com.apple.security.network.client and com.apple.security.network.server entitlements. Some folks reach for broadcasts or multicasts because they’re sending the same content to multiple devices and they believe that it’ll be faster than unicasts. That’s not true in many cases, especially on Wi-Fi. For more on this, see the Broadcasts section of Wi-Fi Fundamentals. Snippets To send a UDP broadcast: func broadcast(message: Data, to interfaceName: String) throws { let fd = try FileDescriptor.socket(AF_INET, SOCK_DGRAM, 0) defer { try! fd.close() } try fd.setSocketOption(SOL_SOCKET, SO_BROADCAST, 1 as CInt) let interfaceIndex = if_nametoindex(interfaceName) guard interfaceIndex > 0 else { throw … } try fd.setSocketOption(IPPROTO_IP, IP_BOUND_IF, interfaceIndex) try fd.send(data: message, to: ("255.255.255.255", 2222)) } Note These snippet uses the helpers from Calling BSD Sockets from Swift. To receive UDP broadcasts: func receiveBroadcasts(from interfaceName: String) throws { let fd = try FileDescriptor.socket(AF_INET, SOCK_DGRAM, 0) defer { try! fd.close() } let interfaceIndex = if_nametoindex(interfaceName) guard interfaceIndex > 0 else { fatalError() } try fd.setSocketOption(IPPROTO_IP, IP_BOUND_IF, interfaceIndex) try fd.setSocketOption(SOL_SOCKET, SO_REUSEADDR, 1 as CInt) try fd.setSocketOption(SOL_SOCKET, SO_REUSEPORT, 1 as CInt) try fd.bind("0.0.0.0", 2222) while true { let (data, (sender, port)) = try fd.receiveFrom() … } } IMPORTANT This code runs synchronously, which is less than ideal. In a real app you’d run the receive asynchronously, for example, using a Dispatch read source. For an example of how to do that, see this post. If you need similar snippets for multicast, lemme know. I’ve got them lurking on my hard disk somewhere (-: Other Resources Apple’s official documentation for BSD Sockets is in the man pages. See Reading UNIX Manual Pages. Of particular interest are: setsockopt man page ip man page ip6 man page If you’re not familiar with BSD Sockets, I strongly recommend that you consult third-party documentation for it. BSD Sockets is one of those APIs that looks simple but, in reality, is ridiculously complicated. That’s especially true if you’re trying to write code that works on BSD-based platforms, like all of Apple’s platforms, and non-BSD-based platforms, like Linux. I specifically recommend UNIX Network Programming, by Stevens et al, but there are lots of good alternatives. https://unpbook.com Revision History 2025-09-01 Fixed a broken link. 2025-01-16 First posted.

Hi, I've encountered a strange behavior in the DNS Proxy Provider extension. Our app implements both DNS Proxy Provider and Content Filter Providers extensions, configured via MDM. When the app is uninstalled, the behavior of the providers differs: For Content Filter Providers (both Filter Control and Filter Data Providers), the providers stop as expected with the stop reason: /** @const NEProviderStopReasonProviderDisabled The provider was disabled. */ case providerDisabled = 5 However, for the DNS Proxy Provider, the provider remains in the "Running" state, even though there is no app available to match the provider's bundle ID in the uploaded configuration profile. When the app is reinstalled: The Content Filter Providers start as expected. The DNS Proxy Provider stops with the stop reason: /** @const NEProviderStopReasonAppUpdate The NEProvider is being updated */ @available(iOS 13.0, *) case appUpdate = 16 At this point, the DNS Proxy Provider remains in an 'Invalid' state. Reinstalling the app a second time seems to resolve the issue, with both the DNS Proxy Provider and Content Filter Providers starting as expected. This issue seems to occur only if some time has passed after the DNS Proxy Provider entered the 'Running' state. It appears as though the system retains a stale configuration for the DNS Proxy Provider, even after the app has been removed. Steps to reproduce: Install the app and configure both DNS Proxy Provider and Content Filter Providers using MDM. Uninstall the app. Content Filter Providers are stopped as expected (NEProviderStopReason.providerDisabled = 5). DNS Proxy Provider remains in the 'Running' state. Reinstall the app. Content Filter Providers start as expected. DNS Proxy Provider stops with NEProviderStopReason.appUpdate (16) and remains 'Invalid'. Reinstall the app again. DNS Proxy Provider now starts as expected. This behavior raises concerns about how the system manages the lifecycle of DNS Proxy Provider, because DNS Proxy Provider is matched with provider bundle id in .mobileconfig file. Has anyone else experienced this issue? Any suggestions on how to address or debug this behavior would be highly appreciated. Thank you!

hi all. I’m working on a content filter system extension on MacOS. I try to disable the filtering in system settings, and it will cause smb shared folder connection interrupted. what I do in stopFilterWithReason:completionHandler: is waiting for the connection that is being filtered be allowed, then invoked the completionHandler. did I do something wrong here? is there a way to avoid the connection interruption?

Hi, I have couple of inquiries regarding the vmnet framework: Incorporating Global Variables: How should we integrate the new global variables in macOS 15.0+ vmnet_read_max_packets_key and vmnet_write_max_packets_key into our configuration to optimize packet transmission? Are those values populated dynamically or manually if so any recommended value ranges ? Buffer Allocation Issue: What strategies can we employ to mitigate this buffer allocation error and ensure more reliable packet transmission? We occasionally encounter the following error during packet writes: Error Domain=NSCocoaErrorDomain Code=512 "The file couldn’t be saved." Error Domain=NSPOSIXErrorDomain Code=55 "No buffer space available" Your insights on these matters would be greatly appreciated.

Hello, We are currently working on a zero-configuration networking compliant device thru avahi-daemon (for mDNS/DNS-SD handling) and avahi-autoipd (for link-local address configuration). Our test environment setup is: Device Under Test (DUT): Debian 9 Linux avahi-daemon: v0.6.32 avahi-autoipd: v0.6.32 Test Bed: Macmini with macOS Sequoia 15.0 Bonjour Conformance Test v1.5.4 Router: NEC Aterm WR8370N Devices are connected via LAN SRV PROBING/ANNOUNCEMENTS BASIC test failure was encountered in BCT during Multicast-DNS test suite execution. Please see the logs below: ERROR 2025-01-15 19:36:35.792930+0900: Cache flush bit is set in the SRV probes NOTICE 2025-01-15 19:36:35.792946+0900: DEVICE-sERvICE-32\._uSCaNs\._tcp\.lOcaL\.._uscAnS._tCP.loCAL., SEND_CONFLICT_WIN -> SEND_CONFLICT_WIN FAILED (SRV PROBING/ANNOUNCEMENTS BASIC) START (SRV PROBING/ANNOUNCEMENTS) DEBUG_2 2025-01-15 19:36:35.792979+0900: received packet (1137 bytes) DEBUG_2 2025-01-15 19:36:35.792999+0900: srv_cf_probe WARNING 2025-01-15 19:36:35.793022+0900: SRV Probing/Announcements Failed: See runtime output for PROBING and WINNING SIMULTANEOUS PROBE for details. FAILED (SRV PROBING/ANNOUNCEMENTS) We would like to know what causes the above test to fail, is it related to avahi or a an inccorect mDNS service handling wherein the cache flush bit was incorrectly set? Thank you.

Dear Apple Developer Support Team, I hope this email finds you well. I am writing to inquire about the status of my application for the Hotspot Helper Request entitlement. I submitted the request on January 16, 2025, but I have not received any updates regarding its review status.

I have been using networking multicast permissions in my Xamarin application for UDP device discovery, and it has been working reliably for years. However, I am now encountering an issue specific to iPadOS 18.1 (potentially also iPadOS 18, though I haven’t tested this). The issue is that my app no longer requests the required network permission on devices running iPadOS 18.1. On the other hand, the app works perfectly on iPhone and iPadOS 17.7 without any problems. Has there been any change in the networking or permissions framework in iPadOS 18.1 that could cause this behavior? I would appreciate any guidance or insights to resolve this issue. Thank you for your assistance!

Hi, I’m urgently seeking assistance with an issue in my app development. The app allows users to control which domains are routed through my relay servers (six server URLs). However, I’ve encountered a problem: When a single relay configuration (for a single server URL) contains more than 70 domains, only one configuration can be active at a time. If I manually activate another relay configuration (for another server URL), the previously activated one automatically deactivates. Is there a way to overcome this limitation? Also, is there a maximum amount of domains that can exist across the per-app relays? I’m referencing the Apple documentation here: https://developer.apple.com/documentation/networkextension/relays Any guidance or insights into resolving this issue would be greatly appreciated! Thank you in advance :)

During development, before things eventually go live, if the associated server for a message filter extension has a self signed SSL then if/how can test iPhones be configured such that the OS will connect to the server when they are performing a message filter query request?

I’m working with the NEHotspotHelper API in my iOS app, and I noticed the following log message in Console: "(BUNDLE ID ) is using NEHotspotHelper API and it's unresponsive to API's evaluate command. The API gives 45 seconds to 3rd party apps to respond, and then it launches WebSheet to allow user to interact with the portal." I have two different apps that both register a NEHotspotHelper handler: App A checks for .evaluate and calls createResponse(.unsupportedNetwork) if we don’t manage that particular network. App B registers for hotspot events but does not handle .evaluate at all. In App A, whenever I see that “unresponsive” or “45 seconds” log, the system eventually launches the standard captive portal WebSheet. In App B, I never see those logs. I have a few questions: Are these “unresponsive” logs indeed triggered by the .evaluate command specifically? In other words, do we only see that 45-second timeout and the subsequent WebSheet message if our app is registered to handle Evaluate but doesn’t respond quickly (or responds with .unsupportedNetwork)? Is it best practice (or required) to always respond to .evaluate—for example, sending .unsupportedNetwork if we don’t plan on managing the user’s login or captive portal? Does ignoring .evaluate lead to other unexpected behavior or logs? Should we still explicitly respond to Evaluate with .unsupportedNetwork? Or is it okay to skip Evaluate handling entirely on every app or invocation? I’d love to confirm whether .evaluate handling is the direct cause of these logs, and how best to avoid the “unresponsive”/“45 seconds” fallback if our app isn’t intended to manage the portal. Thanks in advance for any insights!

We’ve been dealing with local network permission issues on macOS 15. Although 15.1 brought some improvement, users are now reporting similar problems again on 15.2. Our setup: A “launcher” app (installed from a web package, not sandboxed) uses NSTask to launch our main macOS app. This macOS app connects to an iOS app via the local network. We expect a local network permission prompt to appear when the new app launches, but for many users, it never does. In cases where it worked on an earlier macOS version, there’s no entry in System Settings > Privacy & Security > Local Network, so they can’t toggle anything. Oddly, if we run the macOS app directly in 15.2, local network access works, yet the privacy entry is still sometimes missing. We haven’t found a clear way to troubleshoot this within the current API. Has anyone experienced a similar issue, or have suggestions on how to debug and resolve this? Thanks in advance!

We recently notified from Apple that our Hotspot helper is delaying device to switch Wifi Networks. To handle this issue better, we need to refactor our code a bit handle the scenario gracefully and while reading this documentation https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/Hotspot_Network_Subsystem_Guide/Contents/AuthStateMachine.html#//apple_ref/doc/uid/TP40016639-CH2-SW1 Some questions came up while responding back to evaluate and filterscanlist command. Here are our questions What is the lifecycle of exclude_list? Does it get cleared every time Authentication State Machine goes into Inactive State? What happens if we send commandNotRecognized/unsupportedNetwork/temporaryFailure after evaluate command? Does our app get an evaluate command next time when device joins the same network? What is the actual time for the app to respond to network change evaluate command? Is 45 seconds the timeout limit for app to evaluate and respond? After responding to the evaluate command, how quickly is it terminated from running in the background?

We are trying to connect an accessory to the home's Wi-Fi network and we want to pass that name from the app to the accessory. Passing via Bluetooth. Is there and API available on iOS to list the networks that the phone can see?

We've been directed here by Quinn in DTS. We use multicast/broadcast messages extensively in our physical products for discovery purposes. If, for whatever reason, our customers cannot get this to work on their home Wi-Fi network, we advise that they connect to an iPhone hotspot to confirm behaviour and perform firmware updates as needed. As of iOS 18, we're seeing odd behaviour when using Personal Hotspot. Interestingly, we're also seeing that client devices connected to the Hotspot network are not showing a Subnet Mask in the Wi-Fi Details screen in the iOS Settings app - I don't know if that's related. We're also seeing that screen show an IP address of 192.0.0.2 for all client iPhones connected to an iPhone Hotspot. Getting more specific, we're seeing that multicast messages are no longer being received by clients when connected to an iPhone Hotspot where the iPhone running the hotspot is running iOS 18.0 or newer. By "multicast", I mean we're using a BSD socket to send data to 255.255.255.255 I've confirmed that our app has the multicast entitlement, the user has granted Local Network permission, and we've created a small sample app that demonstrates this behaviour perfectly - when connected to any other test network, multicast messages are received correctly by clients. We've also confirmed that this behaviour doesn't happen when the iPhone running the hotspot is running older iOS versions. We've tried a number of iOS 17.x releases and a number of iOS 16.x releases specifically with our sample app, but have been using this exact code since our app's original iOS 9 deployment target and have had no issues until now.

We're seeing some new and odd behavior where our NEPacketTunnelProvider instance is receiving a stopTunnelWithReason:completionHandler: call with reason NEProviderStopReasonInternalError. Can anyone shed some light into how to diagnose this situation? Here are some basic details: Our PacketTunnel has been in use for years and we only started seeing this issue recently. We're able to reproduce this behavior with some light browsing. The documentation provides no insight on why/when this might occur. Can anyone shed some light into how to diagnose this situation? Things we’ve tried so far: We grabbed a sysdiagnose and looked through the logs: a. Right before the stopTunnel, we see log items referring to a "nesessionmanager" (PID 2038) getting killed. Presumably, this is due to hitting a highwater threshold. (See sysdiagnose items listing below) b. Thinking these were due to memory pressure, we added logging of available/used memory. c. We confirmed that the PacketTunnel was only using 11,808.73 KB. d. Since, there is plenty of memory available the PacketTunnel was not killed for using too much memeory. We wondered if this could be due to our UI's usage of objects like: NETunnelProviderManager and NETunnelProviderSession a. We ran an experiment where we swiped closed the UI to ensure these manager/session objects are not used. b. Without the UI, we still saw the random stopTunnel with NEProviderStopReasonInternalError. We wondered if our routes were the problem, but they seem correct. a. See the NEPacketTunnelNetworkSettings listing below LISTING: From the system_logs.logarchive, the nesessionmanager log items: 2025-01-23 15:07:59.176146 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing process 2038 [nesessionmanager] in high band ? (140) - memorystatus_available_pages: 18932 default kernel 2025-01-23 15:07:59.179641 -0800 0x278 memorystatus com.apple.xnu memorystatus: killing_highwater_process pid 2038 [nesessionmanager] (highwater 140) 7056KB - memorystatus_available_pages: 19161 compressor_size:69593 default kernel 2025-01-23 15:07:59.179888 -0800 0x278 memorystatus com.apple.xnu memorystatus: failed to kill a process and no memory was reclaimed default kernel 2025-01-23 15:07:59.185695 -0800 1 0x45e0c user/501/com.apple.nesessionmanager [2038] exited with exit reason (namespace: 1 code: 0x2) - JETSAM_REASON_MEMORY_HIGHWATER, ran for 266329ms default launchd 2025-01-23 15:07:59.231188 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager(2038) exited default UserEventAgent 2025-01-23 15:07:59.253371 -0800 31 0x45bf2 com.apple.networkextension nesessionmanager exited with active sessions, re-launching nesessionmanager to clear agent status default UserEventAgent LISTING: From the system_logs.logarchive, the stopTunnel from PID 2046 2025-01-23 15:07:59.201581 -0800 SamplePacketTunnel [Extension com.REDACTED.PacketTunnel]: Calling stopTunnelWithReason because: None 2025-01-23 15:08:20.783112 -0800 SamplePacketTunnel 2025-01-23 15:08:20,786 2046 ERROR REDACTED (285805) - Exiting after waiting for stopTunnelWithReason LISTING: routes from NEPacketTunnelNetworkSettings { tunnelRemoteAddress = fd12:3456:789a:1::1 DNSSettings = { protocol = cleartext server = ( 2606:4700:4700::1234, 2606:4700:4700::2345, ) matchDomains = ( , ) matchDomainsNoSearch = NO } IPv6Settings = { configMethod = manual addresses = ( fd12:3456:789a:1::1, ) networkPrefixLengths = ( 64, ) includedRoutes = ( { destinationAddress = 2606:4700:4700::2345 destinationNetworkPrefixLength = 128 }, { destinationAddress = 2606:4700:4700::1234 destinationNetworkPrefixLength = 128 }, ) excludedRoutes = ( { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, { destinationAddress = REDACTED destinationNetworkPrefixLength = 128 }, ) } MTU = 3072 } Thanks for taking a look, any help or suggestions would be greatly appreciated

Hi, I would like to confirm whether the matchDomains property in NERelayManager operates strictly at the Application Layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* However, these IPv4 addresses or patterns are not routed through my Relay server. Additionally, I have observed that when using only the excludedDomains property, the desired IPv4 traffic is correctly routed to the relay server as expected. My question is: Can IPv4 addresses or IPv4 CIDR ranges work with matchDomains? If not, is there an alternative approach to enable IPv4 matching while matchDomains is active?

Hi, I would like to confirm if the matchDomains property in NERelayManager operates exclusively at the application layer. Specifically, it seems that adding IPv4 addresses or IPv4 CIDR blocks to the matchDomains list does not work, as the relay manager appears unable to match them. Relay Configuration For example, I tried adding the following IPv4 patterns to the matchDomains list: 11.22.33.44 11.22.. 11.22.* In this configuration, I expected traffic to be routed to the relay server as defined by the matchDomains entries. However, the relay manager did not handle these IPv4 patterns as anticipated. On the other hand, when using only the excludedDomains property, the desired IPv4 traffic is successfully routed to the relay server as expected. Purpose of Forwarding IPv4 to the Relay Server The primary reason for forwarding IPv4 traffic to the relay server is to address cases where certain applications—such as those developed with Flutter or React Native—use their own custom network stack. These custom network stacks often do not respect the relay configuration. As a result, even when these applications use domains that are matched by the relay manager’s matchDomains, their TCP connections to DNS-resolved IPv4 addresses bypass the relay server and connect directly to the IPv4 server. This behavior makes it critical to enable IPv4 matching to ensure all traffic, regardless of the application’s network stack implementation, is routed through the relay server. Questions Can IPv4 addresses or IPv4 CIDR blocks be used with matchDomains? If not, is there an alternative method to enable IPv4 matching while keeping matchDomains enabled? Thank you for your assistance.

I've implemented a custom system extension VPN for macOS using Packet Tunnel Provider. The VPN is configured with on-demand, and a rule to always connect whenever there's traffic: onDemandRules = [NEOnDemandRuleConnect()] As for the tunnel's settings (at the Packet Tunnel Provider), I've configured a split tunnel, so some routes are excluded from the tunnel. Now I have the following scenario: The VPN is connected The Mac enters sleep The sleep() function is called (at my Packet Tunnel Provider) The Mac briefly awakes to check emails/push notifications/etc. This traffic is excluded from the tunnel. What is the expected behavior here? Should the wake function be called because of the on-demand rule? Or should the VPN remain asleep because this traffic is excluded from the tunnel?

Context: We are using NWConnection for UDP and TCP Connections, and wanted to know the best way to keep the number of pending send completions in control to limit resource usage Questions: Is there a way to control the send rate, such that too many 'send pending completion' does not get queued. Say if I do a ‘extremely dense flurry of 10 million NWConnection.send’ will all go asynchronous without any complications? Or I would be informed once it reaches some threshold. Or no? And is it the responsibility of the application using NWConnection.send to limit the outstanding completion , as if they were beyond a certain limit, it would have an impact on outstanding and subsequent requests? If so – how would one know ‘what is supposed to be the limit’ at runtime? Is this a process level or system level limit. Will errors like EAGAIN and ETIMEOUT ever will be reported. In the test I simulated, where the TCP Server was made to not do receive, causing the 'socket send buffer' to become full on the sender side. On the sender side my send stopped getting complete, and became pending. Millions of sends were pending for long duration, hence wanted to know if we will ever get EAGAIN or ETIMEOUT.

Hello, we have noticed a crash in BigSur 11.7.10, 20G1427 libdispatch: Crashed Thread: 1 Dispatch queue: com.apple.network.connections Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [94088] Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: Release of a suspended object Thread 0: 0 libsystem_kernel.dylib 0x00007fff20488aea __sigsuspend_nocancel + 10 1 libdispatch.dylib 0x00007fff2031f4e1 _dispatch_sigsuspend + 36 2 libdispatch.dylib 0x00007fff2031f4bd _dispatch_sig_thread + 53 Thread 1 Crashed:: Dispatch queue: com.apple.network.connections 0 libdispatch.dylib 0x00007fff2033cc35 _dispatch_queue_xref_dispose.cold.1 + 24 1 libdispatch.dylib 0x00007fff20313808 _dispatch_queue_xref_dispose + 50 2 libdispatch.dylib 0x00007fff2030e2eb -[OS_dispatch_source _xref_dispose] + 17 3 libnetwork.dylib 0x00007fff24255999 __nw_queue_context_create_source_block_invoke + 41 4 libdispatch.dylib 0x00007fff2030d623 _dispatch_call_block_and_release + 12 5 libdispatch.dylib 0x00007fff2030e806 _dispatch_client_callout + 8 6 libdispatch.dylib 0x00007fff203111b0 _dispatch_continuation_pop + 423 7 libdispatch.dylib 0x00007fff203211f4 _dispatch_source_invoke + 1181 8 libdispatch.dylib 0x00007fff20316318 _dispatch_workloop_invoke + 1784 9 libdispatch.dylib 0x00007fff2031ec0d _dispatch_workloop_worker_thread + 811 10 libsystem_pthread.dylib 0x00007fff204b545d _pthread_wqthread + 314 11 libsystem_pthread.dylib 0x00007fff204b442f start_wqthread + 15 I have seen similar crashes in the forum, but none from com.apple.network.connections queue. Should we raise a ticket or is this something that was fixed in newer OS versions? Thanks! Jakub