General: TN3151 Choosing the right networking API Networking Overview document — Despite the fact that this is in the archive, this is still really useful. TLS for App Developers DevForums post Choosing a Network Debugging Tool documentation WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi? TN3135 Low-level networking on watchOS Adapt to changing network conditions tech talk Foundation networking: DevForums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Network framework: DevForums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Network Extension (including Wi-Fi on iOS): See Network Extension Resources Wi-Fi Fundamentals Wi-Fi on macOS: DevForums tag: Core WLAN Core WLAN framework documentation Wi-Fi Fundamentals Secure networking: DevForums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). Available trusted root certificates for Apple operating systems support article Requirements for trusted certificates in iOS 13 and macOS 10.15 support article About upcoming limits on trusted certificates support article Apple’s Certificate Transparency policy support article Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related DevForums tags: 5G, QUIC, Bonjour On FTP DevForums post Using the Multicast Networking Additional Capability DevForums post Investigating Network Latency Problems DevForums post Local Network Privacy FAQ DevForums post Extra-ordinary Networking DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

We have an implementation in which we use QUIC via a connection group, server are client are on Swift using the Network framework. Our use case is, the server should send data buffers to the client as fast and as much as possible, now the pace to call the send method from the server should be carefully done, because if we send too much data of course the client is not gonna be able to receive it. The question would be, is there a way to query the congestion window so we know on the server side, how much data we should be able to send at some point? Asking because we are not getting all the data we are sending from the server on our client side... We are using these settings: let options = NWProtocolQUIC.Options(alpn: ["h3"]) options.direction = .bidirectional // options.idleTimeout = 86_400_000 options.maxUDPPayloadSize = Int.max options.initialMaxData = Int.max options.initialMaxStreamDataBidirectionalLocal = Int.max options.initialMaxStreamDataBidirectionalRemote = Int.max options.initialMaxStreamDataUnidirectional = Int.max options.initialMaxStreamsBidirectional = 400 options.initialMaxStreamsUnidirectional = 400 Questions: 1.- Can we get a little more detail in above options, specifically on their impact to the actual connection? 2.- IsinitialMaxData the actual congestion window value 3.- Are we missing something or making incorrect assumptions? Thanks in advance.

REF: TN3135 Context: Stand alone watch app Target platform is cellular watch Phone likely (90%) out of range in a different location (although this applies equally to watch+phone too) User story: As a water & wind sports enthusiast who is either in-shore, near-shore or off-shore I want to receive near-real-time wind reports on my wrist so that I can determine ...(many varieties of facts) My Case for lifting restrictions on NWPathMonitor, NWPath, NWPath.Status What this is about: Proactive UX (enlightening) vs. Reactive UX (disappointing) Reducing unnecessary code execution proactively Exactly the same purpose the tiny red x at the top center of the Watch screen serves (notifies me that the watch is offline -- probably using NWPath.Status of .unsatisfied) What this is NOT about Preflighting requests UI design (although there is a UI component associated with UX - like the tiny red x ...) Establishing low level connections Watch App End User Scenario Water & Wind sports enthusiasts are frequently in and out of cellular range. As a kiteboarding enthusiast I am relating my personal experience. The phone is in the vehicle in the parking lot > 100 yards away while I'm standing on the beach (before I get into the water). On shore or just off shore my watch likely has a solid connection. When 100 yards off shore watch has a decently but tenuous connection. While at 200 yards off shore watch has no connection at all. Developer's Case Current REACTIVE solution My current watch app is forced to be reactive by attempting a URLSession request and capturing one of the plethora of URLError error conditions. This action, of course, is activated through a user interaction workflow: User interaction --> create URL --> use URLSession --> capture URLError --> determine failure cause --> notify user network data cannot be retrieved Optimal PROACTIVE solution Provide a simple indicator to the end user that the data cannot be retrieved. The reason is not relevant to the end user, but they know their interaction with the app is unnecessary. The app's UX has been improved by proactively precluding an unnecessary interaction and precluding unecessary code execution behind the scenes. NWPath.Status = .unsatisfied --> UI shows "no network" type indicator --> (no user interaction - no backend requests - no code execution) --> NWPath.Status = .satisfied --> UI shows nominal status --> end user interacts normally Rationale Using NWPath.Status allows us as developers to fulfill some basic tenets of the Human Interface Guidelines associated with Providing Feedback Specifically, the overview states we should communicate: The current status of something A warning about an action that can have negative consequences And quoting about my specific use case, the guidelines continue: ... it often works well to display status information in a passive way so that people can view it when they need it. Consider integrating status feedback into your interface. Show people when a command can’t be carried out and help them understand why. And finally, the guideline specifically calls out the WatchOS experience I am attempting to avoid. By proactively providing feedback we can prevent the reactive "touch --> wait & see --> then disappoint with no connection" approach. Final Thoughts I realize I am naive about the behind the scenes with this API. I realize that this is likely not the intended use of this API. But as a developer, I also realize users of our stuff often use it in ways we never intended. Please allow these API features on WatchOS

I have a Push Notification Service Extension, which is processing notification payload to attach image, if imageUrl is key is present. I use this simple code to perform the download: let downloadTask = URLSession.shared.downloadTask(with: urlRequest) { [weak self] tempURL, response, error in /// parse results... } Notification payload contains "mutable-content" : 1 inside aps. It's entirely randomly will it work or not. When it doesn't work, I get this error: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" UserInfo={NSErrorFailingURLStringKey=https://w7.pngwing.com/pngs/1005/607/png-transparent-african-elephant-animal-elephant-thumbnail.png, NSErrorFailingURLKey=https://w7.pngwing.com/pngs/1005/607/png-transparent-african-elephant-animal-elephant-thumbnail.png, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDownloadTask <4A847242-2314-4125-99E4-A424CF4B4B7C>.<7>" ), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDownloadTask <4A847242-2314-4125-99E4-A424CF4B4B7C>.<7>} I have no idea what Apple's internal code throws this error, what could possibly go wrong here. This is happening for a while now, I just re-tested on iOS 17.5.1 on 14 Pro. App is compiled using Xcode 15.4 and Swift 5.10, latest SDK. Not sure is it relevant but main iOS app has DataProtection capability set to Complete.

Hello, For several versions, we have had a NetworkExtension registered to "FilterDataProvider" for content filtering reasons, with no issues about performance in 10Gigabit networks. In our latest version, we added registration to "FilterPacketProvider" for packet filtering purposes, and from that moment, we have observed that outgoing bandwidth dramatically decreases by 90% (from 883 MB/s to 140MB/s), simply due to being registered to "FilterPacketProvider," without any processing by us, just only registering and returning ALLOW: class FilterPacketProvider: { override func startFilter(completionHandler: @escaping (Error?) -> Void) { self.packetHandler = {(_pContext: NEFilterPacketContext, _pIface: OS_nw_interface, _pDirection: NETrafficDirection, _pRawData: UnsafeRawPointer, _pRawDataLength: Int) -> NEFilterPacketProvider.Verdict in return self.handleNewPacket(context: _pContext, interface: _pIface, direction: _pDirection, rawData: _pRawData, rawDataLength: _pRawDataLength) } }} func handleNewPacket(context: NEFilterPacketContext, interface: OS_nw_interface, direction: NETrafficDirection, rawData: UnsafeRawPointer, rawDataLength: Int) -> NEFilterPacketProvider.Verdict { return .allow } The most curious thing is that this behaviour only happens with outgoing traffic, while incoming traffic does not experience any performance penalty. Reviewing similar cases, we found a similar post here: https://developer.apple.com/forums/thread/741965 So, our questions are: 1. Could we be doing something wrong when registering to NEFilterPacketProvider? 2. Is there still any known performance bug with outgoing traffic in NEFilterPacketProvider as I read in the post I found and attached? 3. If this bug is confirmed, is there any estimated date for its correction? Best regards, Asier Gil.

Good afternoon! Dear developers, I ask you for help, we do not understand how to deal with this error: Error start method: Optional(WireGuardKit.WireGuardAdapterError.cannotLocateTunnelFileDescriptor) We use the Wire guard library to open a VPN tunnel. But we do not understand where to get the TunnelFileDescriptor , we ask you to help

Hello, I'm working on adding a URLSessionWebSocketTask based web socket connection to have live data in a single view. When the user navigates to it, the connection is established and live data is received. The task is being cancelled when this view disappears: task.cancel(with: .goingAway, reason: nil) After calling resume() on the task, I ping the server to see if the connection works before sending any messages. I opt to use async API instead of closure based wherever possible. Foundation provides both APIs for most URLSessionWebSocketTask's methods, but for some reason it misses async version of sendPing. Such method, however, is available in swift-corelibs-foundation project here. So I've added a similar code locally: extension URLSessionWebSocketTask { func sendPing() async throws { let _: Void = try await withCheckedThrowingContinuation { continuation in sendPing { error in if let error { continuation.resume(throwing: error) } else { continuation.resume() } } } } } The issue that I have is that if the user navigates from the view after sendPing was called, but before pong is received, pongReceiveHandler is called twice with error: Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={NSDescription=Software caused connection abort} This results in an exception: Fatal error: SWIFT TASK CONTINUATION MISUSE: sendPing() tried to resume its continuation more than once, throwing Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={NSDescription=Software caused connection abort}! There are no issues when the task is cancelled after successful ping. The documentation does not state that pongReceiveHandler is always called only once, but by looking at the code in swift-corelibs-foundation I think that it should be the case. Am I misusing sendPing, or is it a bug in the Foundation? Perhaps there is no func sendPing() async throws for some reason? I use Xcode 15.3 with Swift 5.10. Great thanks for any help. Best Regards, Michal Pastwa

Dear Apple Developers, I am working on a macOS project where the container app acts as a server and communicates with a command-line program developed by my colleagues via a Unix domain socket. The macOS part was written using the new Network Framework. Here is a snippet of the code: let params = NWParameters() let socketFile = URL(fileURLWithPath: socketPath) params.defaultProtocolStack.transportProtocol = NWProtocolTCP.Options() params.requiredLocalEndpoint = NWEndpoint.unix(path: socketFile.path) params.allowLocalEndpointReuse = true self.listener = try! NWListener(using: params) listener?.newConnectionHandler = ... listener?.start() When my colleague's program needs to send data, it connects to the socket created by the macOS app, and the data is received perfectly—unless the macOS app is sandboxed. I have added outgoing and incoming connections entitlements to the macOS app. I tested my colleague's program both embedded in the macOS app and separately, ensuring to add the com.apple.security.inherit entitlement as well. However, it still doesn't work when the macOS app is sandboxed. The socket file's permission is srwxr-xr-x@ and is located in the containers folder when sandboxed, and srwxr-xr-x and HOME/Library/Application Support/MyApp when not sandboxed. What could be going wrong? Does the Network Framework support this use case, or do I need to revert to using AF_UNIX? Thank you for your assistance. Best regards. ps. My colleagues' program was written in go, using a standard function conn, err := net.Dial("unix", "socket_path_in_container"). It outputs invalid argument error when the macOS App is sandboxed.

Hello, We are facing what we believe is a compatibility issue with two networking APIs. If the Network extension VPN configuration has includeAllNetworks flag enabled and the NEHotspotHelper is registered. The user has internet connection but it is blocked, and there user will get internet back only after restarting the device. VPN Configuration is as below while connecting to VPN, { localizedDescription = WLVPN WireGuard Configuration enabled = YES protocolConfiguration = { serverAddress = <18-char-str> passwordReference = {length = 20, bytes = 0x67656e70ed0d05c06b1b4896bf4fef2031e1a92d} disconnectOnSleep = NO includeAllNetworks = YES excludeLocalNetworks = YES excludeCellularServices = YES excludeAPNs = YES excludeDeviceCommunication = YES enforceRoutes = NO providerBundleIdentifier = com.wlvpn.ios.consumervpn.network-extension } onDemandEnabled = NO onDemandRules = () } After running the code shown below. Regardless if the VPN is connected or not, the user needs to restart his device to regain internet access. private let neHelperQueue = DispatchQueue(label: "com.wlvpn.ios.consumervpn.hotspot", attributes: DispatchQueue.Attributes.concurrent) let options: [String: NSObject] = [kNEHotspotHelperOptionDisplayName : "" as NSObject] let status = NEHotspotHelper.register(options: nil, queue: neHelperQueue) { cmd in NSLog("Received command: \(cmd.commandType.rawValue)") } We need to use the includeAllNetworks flag to prevent the novel "Tunnel vision" vulnerability. Can we please have some help getting confirmation if both functionalities are compatible or if there's a way to enable them at the same time?

Greetings to everyone, An application we developed with our team could not get approval from Apple review. The application is restricted to local network only. So App Review Team couldn't login in the app and review it. And they says, "Please note that we cannot use a demo video showing your app in use to continue the review." How did you apply for an IP-restricted application? Then they says, "include a demonstration mode that shows all of the features and functionality available in your app" too. If you choose to include a demo mode, what features had you built-in demo mode?

Hello. Wanted to ask about the right way, or the intended way to leverage NWConnectionGroup for a QUIC based streaming solution. The use case is, we are making a request from the client in order to play a movie, and we want to send as much video frames as possible (and as fast as possible) from the streaming server, which also uses the Network framework. Our understanding is, NWConnectionGroup will open a QUIC tunnel between both parties so we can multiplex different streams to the client and we are already doing that. We see a throughput of approx. 20-35MB/s (client device is an iPad and server is an M2 macbook pro running a server app) and we would like to understand if we can improve these results way more. For example: 1.- Is it a good practice to create a second tunnel (NWConnectionGroup), or is not needed here?. We tried that, but the second one is also coming with id 0 on the metadata object, just as the first group we instantiated, not sure why this is the case. 2.- We are using a pool of several NWConnection (initialized with the group object) already instantiated, that way we send a video buffer in chunks as a stream on each connection. We use one connection for a buffer and when we need to send another buffer we use a different NWConnection pulled from the pool. We maybe just want a confirmation/validation of what we are doing, or to see if we are missing something on our implementation... Thanks in advance.

Hello I am developing a react native VPN app. Also I'm new to Native Modules and Swift. Depending on the related documents, I've tried to create IPSEC VPN and connect automatically from my application. I've used the code below to create and connect IPSEC VPN but it is returning "No VPN Shared Secret was provided" error. If I try to add VPN configuration from my Iphone with same parameters it's connecting successfully.

Hi, My application ships a copy of following cryptographic libraries: libp11-kit.0.dylib libnettle.8.dylib libgnutls.30.dylib It's purpose is to connect by secured HTTP to an optional server, that might be turned on to allow to receive HTTP requests. I think this is standard encryption, but do I need to mention this explicitely with App Uses Non-Exempt Encryption? The application doesn't encrypt content it is just for secured HTTP connections. regards, Joël

I'm working on an app that does peer-to-peer communication between Apple devices. As far as I understand, the Network framework is a good choice for this. I have something that works, but I'm curious about the details of how this works and if I might somehow optimize this. My current understanding is that the best connection I can get between two devices is over AWDL. Is this true? If so, does Network use this? Can I ask it to use it preferentially? What kind of bandwidth and latency should I expect out of this, and are there any drawbacks to using it like power usage or transport limitations? If both devices are on the same LAN, I assume they can also talk to each other over Wi-Fi (or a wired connection if both are plugged in, I guess). If I use Bonjour service discovery, is this what I will be getting? What does Network do if the LAN network does not perform well? Will it swap the underlying connection if it figures out there is something better? I am not tied to any particular API or transport protocol, so any input on tradeoffs between ease of implementation/performance/reliability/whatever would be welcome :)

I want to allow network access in my app but I have an error nw_proxy_resolver_create_parsed_array [C1.1.1 proxy pac] Evaluation error: NSURLErrorDomain: -1003 which crashes my app although the seek command works and I get a correct value back from the internet server. I understood I could fix this as foilows? There is a section Info. Within Xcode 15 where you can find Custom macOS Application Target Properties. I selected App Transport Security Settings and the after pressing the drop down menu selected Allow Arbitrary Loads. Then to the left of that I press the menu and it shows YES and NO but if I try to select either of them neither appears in the key value box? Also I thought this would create a new Info.plist which I could then add my key values- but nothing happens.. I am very new to the so any help is much apprecated

This was mentioned in another thread 4 years ago: This whole discussion assumes that every network connection requires a socket. This isn’t the case on most Apple platforms, which have a user-space networking stack that you can access via the Network framework [1]. [1] The one exception here is macOS, where Network framework has to run through the kernel in order to support NKEs. This is one of the reasons we’re in the process of phasing out NKE support, starting with their deprecation in the macOS 10.15 SDK. Is macOS still an unfortunate exception that requires a socket per Network framework's connection?

Hello 👋 I need to implement a logic for searching for devices with our own service type using Bonjour. Using the NWBrowser, I can receive a list of all devices and connect to them. I need to utilize a WebSocket connection. By the property endpoint of NWBrowser.Result objects I can create NWConnection. Below is my implementation which works fine on iOS 17: let params = NWParameters.tcp let webSocketOptions = NWProtocolWebSocket.Options() params.defaultProtocolStack.applicationProtocols.insert(webSocketOptions, at: 0) // The `endpoint` is from `browseResultsChangedHandler` of NWBrowser let connection = NWConnection(to: endpoint, using: params) However, it doesn't work on iOS 15 and 16 because of the crash: 2024-06-01 16:07:18.136068+0300 MyApp[591:16845549] [] nw_endpoint_get_url called with null endpoint 2024-06-01 16:07:18.136932+0300 MyApp[591:16845549] [] nw_endpoint_get_url called with null endpoint, dumping backtrace: [arm64] libnetcore-3100.102.1 0 Network 0x000000018530e174 __nw_create_backtrace_string + 188 1 Network 0x000000018538ba20 nw_endpoint_get_url + 852 2 Network 0x0000000185310020 nw_ws_create_client_request + 84 3 Network 0x0000000184f4b3cc __nw_ws_create_state_block_invoke + 416 4 Network 0x000000018504bc68 nw_protocol_options_access_handle + 92 5 Network 0x0000000184f41e98 nw_ws_create_state + 204 6 Network 0x0000000184f41aec __nw_protocol_copy_ws_definition_block_invoke_2 + 176 7 Network 0x0000000184f69188 nw_framer_protocol_connected + 348 8 Network 0x00000001854a6638 _ZL29nw_socket_handle_socket_eventP9nw_socket + 1560 9 libdispatch.dylib 0x0000000126b89d50 _dispatch_client_callout + 16 10 libdispatch.dylib 0x0000000126b8d208 _dispatch_continuation_pop + 756 11 libdispatch.dylib 0x0000000126ba48d4 _dispatch_source_invoke + 1676 12 libdispatch.dylib 0x0000000126b94398 _dispatch_workloop_invoke + 2428 13 libdispatch.dylib 0x0000000126ba0b74 _dispatch_workloop_worker_thread + 1716 14 libsystem_pthread.dylib 0x000000012371f814 _pthread_wqthread + 284 15 libsystem_pthread.dylib 0x000000012371e5d4 start_wqthread + 8 Also, there is the stack trace of bt-command in the debug console: * thread #20, queue = 'com.apple.network.connections', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0000000123078c24 libsystem_platform.dylib`_platform_strlen + 4 frame #1: 0x00000001803c538c CoreFoundation`CFStringCreateWithCString + 40 frame #2: 0x0000000185310030 Network`nw_ws_create_client_request + 100 frame #3: 0x0000000184f4b3cc Network`__nw_ws_create_state_block_invoke + 416 frame #4: 0x000000018504bc68 Network`nw_protocol_options_access_handle + 92 frame #5: 0x0000000184f41e98 Network`nw_ws_create_state + 204 frame #6: 0x0000000184f41aec Network`__nw_protocol_copy_ws_definition_block_invoke_2 + 176 frame #7: 0x0000000184f69188 Network`nw_framer_protocol_connected + 348 frame #8: 0x00000001854a6638 Network`nw_socket_handle_socket_event(nw_socket*) + 1560 frame #9: 0x0000000126b89d50 libdispatch.dylib`_dispatch_client_callout + 16 frame #10: 0x0000000126b8d208 libdispatch.dylib`_dispatch_continuation_pop + 756 frame #11: 0x0000000126ba48d4 libdispatch.dylib`_dispatch_source_invoke + 1676 frame #12: 0x0000000126b94398 libdispatch.dylib`_dispatch_workloop_invoke + 2428 frame #13: 0x0000000126ba0b74 libdispatch.dylib`_dispatch_workloop_worker_thread + 1716 frame #14: 0x000000012371f814 libsystem_pthread.dylib`_pthread_wqthread + 284 I have found out a couple things: There are no crashes if I initialize the NWConnection object with using, for instance, the NWEndpoint.url(_:). initializer: let urlHost = URL(string: "ws://10.20.30.40:5060")! let endpoint = NWEndpoint.url(urlHost) let params = NWParameters.tcp let webSocketOptions = NWProtocolWebSocket.Options() params.defaultProtocolStack.applicationProtocols.insert(webSocketOptions, at: 0) let connection = NWConnection(to: endpoint, using: params) self.connection = connection But, in this case, I must extract IP-addresses 🙇‍♂️ Meanwhile, there is a topic such as Don’t Try to Get the Device’s IP Address.. I have tried to find anything that could help me move forward in this problem and run into some odd behaviour. There is a property skipHandshake of NWProtocolWebSocket.Options object. If I set the property value to true, there are no crashes as well as no connection to a device.

Experiencing an internet connectivity issue on iPhone device with one of iOS VPN configuration in PacketTunnelProvider. We have set up a full tunnel route configuration as follows: _pcktTunProvider.protocolConfiguration.includeAllNetworks = YES; _pcktTunProvider.protocolConfiguration.excludeLocalNetworks = NO; _pcktTunProvider.protocolConfiguration.enforceRoutes = NO; With these settings, the VPN successfully establishes a connection, and all traffic is routed through the tunnel as expected. Issue we are facing: However, we encounter a problem when we attempt to disconnect the VPN. When we call the following method from PacketTunnel network extension: (void)cancelTunnelWithError:(nullable NSError *)error The VPN disconnects, but the device loses all internet connectivity and is unable to access any resources. What we have tried: We have also tried using the following method with the same result:       - (void)stopTunnelWithReason:(NEProviderStopReason)reason completionHandler:(void (^)(void))completionHandler Interestingly, when we call the following method from the app side. The VPN disconnects and the device retains its internet connectivity. [enabledConfig.connection stopVPNTunnel]; But for our use case we cant call stopVPNtunnel from App if App is not running so looking for a solution that could clear the tunnel from NE as cancelTunnelWithError Api causes internet blocker issue. One more similar ticket here: https://forums.developer.apple.com/forums/thread/730689

This is the bug: https://forums.developer.apple.com/forums/thread/729348?answerId=780151022#780151022 [quote='780151022, LostButFound, /thread/729348?answerId=780151022#780151022, /profile/LostButFound'] This issue still happens for me. With and without VPN, with both OpenVPN and Wireguard. With and without filtering (mostly with filters though, both LuLu and Little Snitch). On two different machines, M1 and M3. It's random. If I have to bet, there's a deadlock caused by running x86 code on Arm hardware. As a software engineer I saw cases where Intel tolerates bad multI-threading more than Arm. Are the Apple devs working on this? This is a very serious issue that makes these very expensive laptop unusable! At least provide a way to reset the network stack! 0  comments [/quote] It seems that the Network Extension Framework has a bug where combining VPN and Network filters causes deadlocks and timeouts in networking on irregular basis, regardless of the network interface used. This issue happens at a lower level than network interfaces. It can be either a Network Extension Framework bug or a kernel module bug. Given that the network extension frame isn't open source, I can't even debug it, which I would've happily done. Yes, even though I'm not an apple developer, but this bug is so bad that I'm happy to build MacOS components in debug mode and attach a debugger on them when the issue happens... but it's not open source. So, we have a bug, and we need help from apple devs to fix it... what am I supposed to do? Is there a chance I can get a dev to contact me to debug this together? What are my options?

We have a relatively simple app that using Network.Framework, NWConnection, NWEndpoint to setup TCP connections with nearby devices also using the app. It's actually been working great for a while now but we've recently noticed with iOS 17.4/17.4.1 that we're spontaneously getting: nw_proto_tcp_route_init [C6:3] no mtu received sometimes the [C6:3] will be [C7:3] or another similar code. We may also occasionally see No route to Host appear in our console logs though this isn't definite. After this point the connection is effectively lost but we don't actually receive any updates on our NWConnection stateUpdateHandler to action on. It's sort of dead in the water so to speak. We've reproduced this issue with multiple devices on iOS 17.4.x and in multiple network settings (in office, cafe, home networks...etc). Nothing seems to make a difference. Any ideas on how to fix or workaround this? I saw a similar issue here: https://developer.apple.com/forums/thread/669519 but the original author never followed up and it's around 3 years old. I've captured a sysdiagnose log and can submit an issue if it warrants filing a bug report.

I've been investigating an issue with the SO_OOBINLINE socket option. When that option is disabled, the expectation is that out-of-band data that is sent on the socket will not be available through the use of read() or recv() calls on that socket. What we have been noticing is that when the socket is bound to a non-loopback address (and the communication is happening over that non-loopback address), then even when SO_OOBINLINE is disabled for the socket, the read()/recv() calls both return the out-of-band data. The issue however isn't reproducible with loopback address, and read()/recv() both correctly exclude the out-of-band data. This issue is only noticed on macos. I have been able to reproduce on macos M1, following version, but the original report which prompted me to look into this was reported on macos x64. My M1 OS version is: sw_vers ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60 Attached is a reproducer (main.c.txt - rename it to main.c after downloading) that I have been able to develop which reproduces this issue on macos. When you compile and run that: ./a.out it binds to a non-loopback address by default and you should see the failure log, resembling: ... ERROR: expected: 1234512345 but received: 12345U12345 To run the same reproducer against loopback address, run it as: ./a.out loopback and that should succeed (i.e. no out-of-band data) with logs resembling: ... SUCCESS: completed successfully, expected: 1234512345, received: 1234512345 Is this a bug in the OS? I would have reported this directly through feedback assistant, but my past few open issues (since more than a year) have not even seen an acknowledgement or a reply, so I decided to check here first. main.c.txt