The man page for getifaddrs states: The ifa_data field references address family specific data. For AF_LINK addresses it contains a pointer to the struct if_data (as defined in include file <net/if.h>) which contains various interface attributes and statistics. For all other address families, it contains a pointer to the struct ifa_data (as defined in include file <net/if.h>) which contains per-address interface statistics. I assume that "AF_LINK address" is the one that has AF_LINK in the p.ifa_addr.sa_family field. However I do not see "struct ifa_data" anywehere. Is this a documentation bug and if so how do I read this documentation right?

Hello! I'm playing around with QUIC and Swift and using the Network framework. So far, the process has been really straightforward, but I noticed that I can't seem to get a handle on the stream with identifier 0. If I use NWConnection directly, I only have access to the first stream, which has the stream ID 0. This not what I want since I wanna use multiple streams. Following the documentation, I started using NWMultiplexGroup and starting a NWConnectionGroup with it. Everything works fine and I can get all streams that my backend service opens using NWMultiplexGroup's newConnectionHandler property. However, whenever backend sends a message on stream_id 0, none of my connections receive it. Looking around with connection.metadata(definition: NWProtocolQUIC.definition) as? NWProtocolQUIC.Metadata for each connection, I see that all streams are accounted for except stream 0. Then, using the NWConnectionGroup variant of the above connectionGroup.metadata(definition: NWProtocolQUIC.definition) as? NWProtocolQUIC.Metadata I see that the connection group itself has Stream ID 0. However, calling setReceiveHandler does nothing (it's never called, even when backend is sending messages) and when I attempt to send a message using NWConnectionGroup's -send method, a new stream is opened (instead of it being sent on stream ID 0). How can one get a handle on NWConnection for stream ID 0?

We are using and iOS version 17.4.1 and 17.5(beta) , and when are we facing the issue for local network permission in our app. Success scenario steps: Don't allow the local network permission in our App Allow it manually in app setting for local network permission(works only in first install of the App) We are able to call the API successfully Error scenario steps: Allow the local network permission popup to app when asked for permission Call the API successfully Uninstall the app and install the same app again and don't allow the local network permission API call fail's Manually change the local network permission to allow in app settings Still the API call fails even if we allow the local network permission Conclusion : We are getting API error when re-install the app and if it is not allowed local network permission as well as when we allow the local network permission. Looks like caching issue. Note: Even if uninstall and install multiple time and allow the local network permission from 2nd time onward API keeps on failing , but these scenario work perfectly fine on iOS 16 version and below. Even the existing app stopped working after updating iOS version to 17 and above. Also we found alternatively when we uninstall the app and restart the device and install it back again it works fine for the first time as a fresh install. Additionally : We are not calling local network permission explicitly, when the API call is happening this is native popup coming on iOS

Most apps perform ordinary network operations, like fetching an HTTP resource with URLSession and opening a TCP connection to a mail server with Network framework. These operations are not without their challenges, but they’re the well-trodden path. Note If your app performs ordinary networking, see TN3151 Choosing the right networking API for recommendations as to where to start. Some apps have extra-ordinary networking requirements. For example, apps that: Help the user configure a Wi-Fi accessory Require a connection to run over a specific interface Listen for incoming connections Building such an app is tricky because: Networking is hard in general. Apple devices support very dynamic networking, and your app has to work well in whatever environment it’s running in. Documentation for the APIs you need is tucked away in man pages and doc comments. In many cases you have to assemble these APIs in creative ways. If you’re developing an app with extra-ordinary networking requirements, this post is for you. Note If you have questions or comments about any of the topics discussed here, put them in a new thread here on DevForums. Make sure I see it by tagging it with… well… tags appropriate to the specific technology you’re using, like Foundation, CFNetwork, Network, or Network Extension. Links, Links, and More Links Each topic is covered in a separate post: The iOS Wi-Fi Lifecycle describes how iOS joins and leaves Wi-Fi networks. Understanding this is especially important if you’re building an app that works with a Wi-Fi accessory. Network Interface Concepts explains how Apple platforms manage network interfaces. If you’ve got this far, you definitely want to read this. Network Interface Techniques offers a high-level overview of some of the more common techniques you need when working with network interfaces. Network Interface APIs describes APIs and core techniques for working with network interfaces. It’s referenced by many other posts. Running an HTTP Request over WWAN explains why most apps should not force an HTTP request to run over WWAN, what they should do instead, and what to do if you really need that behaviour. If you’re building an iOS app with an embedded network server, see Showing Connection Information in an iOS Server for details on how to get the information to show to your user so they can connect to your server. Many folks run into trouble when they try to find the device’s IP address, or other seemingly simple things, like the name of the Wi-Fi interface. Don’t Try to Get the Device’s IP Address explains why these problems are hard, and offers alternative approaches that function correctly in all network environments. If you’re building an app that works with a Wi-Fi accessory, see Working with a Wi-Fi Accessory. If you’re trying to gather network interface statistics, see Network Interface Statistics. There are also some posts that are not part of this series but likely to be of interest if you’re working in this space: Local Network Privacy FAQ discusses iOS’s local network privacy feature. Calling BSD Sockets from Swift does what it says on the tin, that is, explain how to call BSD Sockets from Swift. When doing weird things with the network, you often find yourself having to use BSD Sockets, and that API is not easy to call from Swift. The code therein is primarily for the benefit of test projects, oh, and DevForums posts like this one. TN3111 iOS Wi-Fi API overview is a critical resource if you’re doing Wi-Fi specific stuff on iOS. TLS For Accessory Developers tackles the tricky topic of how to communicate securely with a network-based accessory. Networking Resources has links to many other useful resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2024-04-30 Added a link to Network Interface Statistics. 2023-09-14 Added a link to TLS For Accessory Developers. 2023-07-23 First posted.

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" Network Interface Statistics One FAQ when it comes to network interfaces is “How do I get network interface statistics?” There are numerous variants of this: Some folks ask about specific network interfaces: “How do I get cellular data usage?” Some folks are interested in per-app statistics: “How do I get cellular data usage statistics for each app?” or “How do I get cellular data usage statistics for my app?” Some folks only care about recent statistics: “How can I tell how much network data this operation generated?” Some folks care about usage across restarts: “How do I get the cellular data usage shown in the Settings app on iOS?” Most of these questions have no supported answers. However, there are a some supported techniques available. This post explains those techniques, and their limitations. MetricKit To get network usage for your app, use MetricKit. Specifically, look at the MXNetworkTransferMetric payload. MetricKit has a number of design points: You only get metrics for your app. You get metrics periodically; you can’t monitor these statistics in real time. Legacy Techniques The getifaddrs routine returns rudimentary network interface statistics. See the getifaddrs man page and the struct if_data definition in <net/if_var.h>. Here’s an example of how you might use this: func legacyNetworkInterfaceStatisticsForInterfaceNamed(_ name: String) -> LegacyNetworkInterfaceStatistics? { var addrList: UnsafeMutablePointer<ifaddrs>? = nil let err = getifaddrs(&addrList) // In theory we could check `errno` here but, honestly, what are gonna // do with that info? guard err >= 0, let first = addrList else { return nil } defer { freeifaddrs(addrList) } return sequence(first: first, next: { $0.pointee.ifa_next }) .compactMap { addr in guard let nameC = addr.pointee.ifa_name, name == String(cString: nameC), let sa = addr.pointee.ifa_addr, sa.pointee.sa_family == AF_LINK, let data = addr.pointee.ifa_data else { return nil } return LegacyNetworkInterfaceStatistics(if_data: data.assumingMemoryBound(to: if_data.self).pointee) } .first } struct LegacyNetworkInterfaceStatistics { var packetsIn: UInt32 // ifi_ipackets var packetsOut: UInt32 // ifi_opackets var bytesIn: UInt32 // ifi_ibytes var bytesOut: UInt32 // ifi_obytes } extension LegacyNetworkInterfaceStatistics { init(if_data ifData: if_data) { self.packetsIn = ifData.ifi_ipackets self.packetsOut = ifData.ifi_opackets self.bytesIn = ifData.ifi_ibytes self.bytesOut = ifData.ifi_obytes } } This is a legacy interface. macOS inherited this API from its ancestor platforms, and iOS inherited it from macOS. That history means that the API has significant limitations: The counters reset each time the device restarts. The counters are represented as a UInt32, and so wrap at 4 GiB [1]. Due to its legacy nature, there’s little point filing an enhancement request against this API. [1] The <net/if_var.h> header defines an if_data64 structure, but there’s no supported way to get that value on Apple platforms. Limitations When it comes to network interface statistics, certain tasks have no supported solutions: Getting per-app statistics Getting whole device statistics that persist across a restart Getting real-time statistics for your app that persist across a restart If you need one of these features, feel free to file an enhancement request for it. In your ER: Be specific about the platforms you need this on [1]. Make sure that your request is aligned with that platforms privacy constraints. For example, iOS isolates your app from other apps, so you’re unlikely to get an API that returns per-app statistics for all apps on the system. Supply a clear justification for why this is important to your product. [1] If it’s macOS, be clear about: Whether your app is sandboxed or not. Whether it’s a Mac Catalyst. Or running via iOS Apps on Mac.

Are there any IOS apps that allow you to connect to multiple proxies at once like Nekobox for Android that allow you to create a proxy chain? Thanks

Is it possible to programmatically force iphone to use cellular internet during WIFI connection? I am connected via WIFI to a device with no internet connection. But I need to use MapKit

Hi, We recently released a version of our app where we use 'NWParameters.PrivacyContext'. On iOS 17.4 and iOS 17.4.1 the app crashes with a following crash: Distributor ID: com.apple.AppStore Hardware Model: iPhone12,1 Process: <app> Path: <path to app> Identifier: <bundle id> Version: <version> AppStoreTools: 15E204 AppVariant: 1:iPhone12,1:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: <our bundle id> [4899] Date/Time: 2024-04-29 01:50:13.4113 +0300 Launch Time: 2024-04-29 01:13:47.6252 +0300 OS Version: iPhone OS 17.4.1 (21E236) Release Type: User Baseband Version: 5.00.00 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000054 Exception Codes: 0x0000000000000001, 0x0000000000000054 VM Region Info: 0x54 is not in any region. Bytes before following region: 4334124972 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 102558000-1063e4000 [ 62.5M] r-x/r-x SM=COW <path to app> Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [24308] Triggered by Thread: 18 Kernel Triage: VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter Thread 18 name: Thread 18 Crashed: 0 libdispatch.dylib 0x00000001a573b7d8 dispatch_async + 192 (queue.c:940) 1 Network 0x000000019ddbdb38 nw_queue_context_async + 76 (queue.m:87) 2 Network 0x000000019e512748 invocation function for block in nw_socket_init_socket_event_source(nw_socket*, unsigned int) + 1488 (protocol_socket.cpp:4351) 3 libdispatch.dylib 0x00000001a5736dd4 _dispatch_client_callout + 20 (object.m:576) 4 libdispatch.dylib 0x00000001a573a2d8 _dispatch_continuation_pop + 600 (queue.c:321) 5 libdispatch.dylib 0x00000001a574e1c8 _dispatch_source_latch_and_call + 420 (source.c:596) 6 libdispatch.dylib 0x00000001a574cd8c _dispatch_source_invoke + 832 (source.c:961) 7 libdispatch.dylib 0x00000001a5740284 _dispatch_workloop_invoke + 1756 (queue.c:4570) 8 libdispatch.dylib 0x00000001a5749cb4 _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:6998) 9 libdispatch.dylib 0x00000001a5749528 _dispatch_workloop_worker_thread + 404 (queue.c:6592) 10 libsystem_pthread.dylib 0x00000001f981cf20 _pthread_wqthread + 288 (pthread.c:2665) 11 libsystem_pthread.dylib 0x00000001f981cfc0 start_wqthread + 8 (:-1) Thread 18 crashed with ARM Thread State (64-bit): x0: 0x0000000301a922e0 x1: 0x000000032471a720 x2: 0x0000000000000000 x3: 0x00000003015e2300 x4: 0x0000000000000003 x5: 0x00000000000022e0 x6: 0x0000000172462ef0 x7: 0x000000000000008b x8: 0x00000000000008ff x9: 0x0000000000000000 x10: 0x0000000000010000 x11: 0x0000000000000020 x12: 0x00000003016f3854 x13: 0x00000000001ff800 x14: 0x00000000000007fb x15: 0x0000000089800118 x16: 0x00000001a573511c x17: 0x000000019e514740 x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x0000000308eae8c0 x21: 0x000000032471a730 x22: 0x000000032471b0e0 x23: 0x000000000000e023 x24: 0x0000000172463085 x25: 0x000000002b1d034c x26: 0x0000000000000800 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000032471a6b0 lr: 0xad5ba301a573b750 sp: 0x000000032471a690 pc: 0x00000001a573b7d8 cpsr: 0x80000000 esr: 0x92000006 (Data Abort) byte read Translation fault What could be the reason for it?

Hi, wondering if IOS supports WebTransport (HTTP/3) yet? If so, where can I find information on implementing it in my app?

Hello, I'm looking for a way to detect using NWPathMonitor when the iOS device is connected to a router but not to the internet. As an example a mobile router WiFi without SIM. In settings I'm able to switch the connection to its WiFi, once connected a label below the SSID shows Not connected to the internet. I would like to show the same thing to the user inside my app, but unfortunately I always get the satisfied answer. Am I missing something in configuring NWPathMonitor or reading the answer? final class InternetConnectionMonitor { lazy var internetConnectionStatusPublisher: AnyPublisher&lt;InternetConnectionStatus, Never&gt; = { _internetConnectionStatusSubject .compactMap{ $0 } .eraseToAnyPublisher() }() var lastInternetConnectionStatus: InternetConnectionStatus? { _internetConnectionStatusSubject.value } private let _internetConnectionStatusSubject = CurrentValueSubject&lt;InternetConnectionStatus?, Never&gt;(nil) private let pathMonitor = NWPathMonitor() private let pathMonitorQueue = DispatchQueue(label: "com.xxxxx-network-monitor", qos: .default) init() { startPathMonitoring() } private func startPathMonitoring() { pathMonitor.pathUpdateHandler = { [weak self] path in guard let self else { return } let networkStatus = InternetConnectionStatus(from: path) self._internetConnectionStatusSubject.send(networkStatus) } pathMonitor.start(queue: pathMonitorQueue) } }

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.

We've been using network framework for peer to peer connectivity since iOS 15. Since the introduction of iOS 17 we've been getting the following for our NWListener when attempting to establish a connection with any multipathServiceType enabled. We're not doing anything special here. On iOS 17.x devices (we've tested 17.1, 17.2, 17.4) we simply enable multipath services by adding the multipath capability and then setting multipathServiceType to .handover or .interactive on our NWParameters. The devices never connect when we try establish an NWConnection. This works on all non-iOS 17.x devices. This is reproducible using the Apple Peer-to-Peer NWConnection TicTacToe sample code.

I'm noticing a trend in 'foreign' home security products that they want to combination of QR code scanning, and home router connections for 'Easy Setups'. The iOS apps that have to be used with these products require the user to enter their home WiFi password directly into the app. Such apps also commonly request location data. If unencrypted router passwords, and the Location data of the router are being captured and sent back to the manufacturer, this would be very very bad. Of the few things I've put on the App Store, Apple went through my code with a fine tooth comb looking for things that went against their protocols and had to do multiple revisions to bring them in line. Although frustrating at the time, I was pleased to know this kind of screening happened. I've heard Apple won't allow apps to do key logging/capture. Fantastic. Is the the handling of our home network credentials also heavily scrutinised before thing are allowed on the Apple Store?

I spent 3 days sorting out an app that worked with net7.0 and Xcode 14.x. Namely my Httpsclient requests to the API crashed the iOS after 6-9 cycles. Ater re-coding with no luck, tracking the Crash codes and recoding with no luck, I finally found a forum that articulates 15.3 and net8.0 is a no go. Downgrade to 15.2. I did the downgrade and my original code worked just fine. I read most of the posts on 15.3 and did not see this issue noted. Has anyone seen the same issue and if so found a work around? Others have seen an HttpsClient issue with authentication with 2 suggestions but no workable solution in 15.3. They downgraded.

Like the post at https://forums.developer.apple.com/forums/thread/118035, I'm hitting an issue where I'm receiving: boringssl_session_set_peer_verification_state_from_session(448) [C1.1.1.1:2][0x12b667210] Unable to extract cached certificates from the SSL_SESSION object In my app logs. I tried to pin the SSL version to TLS 1.2 per Quinn's advice in that post, and then started digging further enabling CFNETWORK_DIAGNOSTICS=3 to see what was exposed on the Console.log (since it didn't show up in the Xcode console) The related log lines: 0 debug boringssl 15:43:04.978874-0700 MeetingNotes boringssl_context_log_message(2206) [C5:2][0x11080a760] Reading SSL3_RT_HANDSHAKE 16 bytes 0 debug boringssl 15:43:04.979007-0700 MeetingNotes boringssl_context_log_message(2206) [C5:2][0x11080a760] Writing SSL3_RT_CHANGE_CIPHER_SPEC 1 bytes 0 debug boringssl 15:43:04.979141-0700 MeetingNotes boringssl_context_log_message(2206) [C5:2][0x11080a760] Writing SSL3_RT_HANDSHAKE 16 bytes 0 debug boringssl 15:43:04.979260-0700 MeetingNotes nw_protocol_boringssl_write_bytes(87) [C5:2][0x11080a760] write request: 51 0 debug boringssl 15:43:04.979387-0700 MeetingNotes nw_protocol_boringssl_write_bytes(158) [C5:2][0x11080a760] total bytes written: 51 921460 debug boringssl 15:43:09.937961-0700 MeetingNotes boringssl_context_log_message(2206) [C5:2][0x11080a760] Writing SSL3_RT_ALERT 2 bytes 0 error boringssl 15:43:04.979630-0700 MeetingNotes boringssl_session_set_peer_verification_state_from_session(448) [C5:2][0x11080a760] Unable to extract cached certificates from the SSL_SESSION object Have a number of references to SSL3_RT in the messages, and I was curious if that indicated that I was using TLS1.3, which apparently doesn't support private shared keys. The constraints that I used riffs on the sample code from the tic-tac-toe example project: private static func tlsOptions(passcode: String) -> NWProtocolTLS.Options { let tlsOptions = NWProtocolTLS.Options() let authenticationKey = SymmetricKey(data: passcode.data(using: .utf8)!) let authenticationCode = HMAC<SHA256>.authenticationCode( for: "MeetingNotes".data(using: .utf8)!, using: authenticationKey ) let authenticationDispatchData = authenticationCode.withUnsafeBytes { DispatchData(bytes: $0) } // Private Shared Key (https://datatracker.ietf.org/doc/html/rfc4279) is *not* supported in // TLS 1.3 [https://tools.ietf.org/html/rfc8446], so this pins the TLS options to use version 1.2: // @constant tls_protocol_version_TLSv12 TLS 1.2 [https://tools.ietf.org/html/rfc5246] sec_protocol_options_set_max_tls_protocol_version(tlsOptions.securityProtocolOptions, .TLSv12) sec_protocol_options_set_min_tls_protocol_version(tlsOptions.securityProtocolOptions, .TLSv12) sec_protocol_options_add_pre_shared_key( tlsOptions.securityProtocolOptions, authenticationDispatchData as __DispatchData, stringToDispatchData("MeetingNotes")! as __DispatchData ) /* RFC 5487 - PSK with SHA-256/384 and AES GCM */ // Forcing non-standard cipher suite value to UInt16 because for // whatever reason, it can get returned as UInt32 - such as in // GitHub actions CI. let ciphersuiteValue = UInt16(TLS_PSK_WITH_AES_128_GCM_SHA256) sec_protocol_options_append_tls_ciphersuite( tlsOptions.securityProtocolOptions, tls_ciphersuite_t(rawValue: ciphersuiteValue)! ) return tlsOptions } Is there something I'm missing in setting up the proper constraints to request TLS version 1.2 with a private shared key to be used? And beyond that, any suggestions for debugging or narrowing down what might be failing?

Whenever I open a .unix socket (i.e.: /var/run/usbmuxd) I get the following errors in Xcode console: nw_socket_set_common_sockopts [C13:1] setsockopt SO_NECP_CLIENTUUID failed [22: Invalid argument] Type: Error | Timestamp: 2024-04-18 15:48:44.813556-04:00 | Process: TH Dev | Library: Network | Subsystem: com.apple.network | Category: connection | TID: 0x425e2 nw_socket_set_common_sockopts setsockopt SO_NECP_CLIENTUUID failed [22: Invalid argument] Type: Error | Timestamp: 2024-04-18 15:48:44.813682-04:00 | Process: TH Dev | Library: Network | Subsystem: com.apple.network | Category: | TID: 0x425e2 nw_socket_copy_info [C13:1] getsockopt TCP_INFO failed [102: Operation not supported on socket] Type: Error | Timestamp: 2024-04-18 15:48:44.814484-04:00 | Process: TH Dev | Library: Network | Subsystem: com.apple.network | Category: connection | TID: 0x425e2 nw_socket_copy_info getsockopt TCP_INFO failed [102: Operation not supported on socket] Type: Error | Timestamp: 2024-04-18 15:48:44.814523-04:00 | Process: TH Dev | Library: Network | Subsystem: com.apple.network | Category: | TID: 0x425e2 While communication to/from the socket seems to work, the operations leading to these errors shouldn't be attempted if the socket doesn't support them.

Hello, I was referring to the post - https://developer.apple.com/forums/thread/663769 to determine if my app has been granted access to Local Network or not. I am starting an NWConnection for a local network address and checking if the currentPath?.unsatisfiedReason == .localNetworkDenied. This is not working as expected. Even when I accept the local network permission prompt, I still get the unsatisfied reason as .localNetworkDenied. I have also tried turning off/on the permission toggle from the settings app. I have also checked this with the 2nd method in the above post about using pathUpdateHandler and getting the same results. I am using an iOS 17.4.1 device. Is this method reliable? Is there some other method/api that I can use to check for local network access in my app?

Hello, Our app has an internal job processing queue. All jobs are built as a NSOperation and involve a network request, and they are added to NSOperationQueue. When the app is closed while a request is being sent, the app sometimes crashes, but it also keeps crashing whenever we build the operation again and retry it. This happens rarely, but we can systematically reproduce it after a few tries with many jobs. This issue blocks the queue in our app. I understand if this is an issue deep within the framework, but it would be very useful to at least find a way to work around this issue so the queue can continue processing other jobs. The full crash report is attached. I also submitted a bug report: FB13734737 There seems to be an internal assertion fired in CFNetwork: Assertion failed: (CFReadStreamGetStatus(_stream.get()) == kCFStreamStatusNotOpen) function _onqueue_setupStream_block_invoke file HTTPRequestBody.cpp line 878. Crashed: com.apple.NSURLConnectionLoader 0 libsystem_kernel.dylib 0xa974 __pthread_kill + 8 1 libsystem_pthread.dylib 0x60ec pthread_kill + 268 2 libsystem_c.dylib 0x75b80 abort + 180 3 libsystem_c.dylib 0x74e70 err + 282 4 CFNetwork 0x1f73b8 CFHTTPCookieStorageUnscheduleFromRunLoop + 278252 5 libdispatch.dylib 0x3dd4 _dispatch_client_callout + 20 6 libdispatch.dylib 0x786c _dispatch_block_invoke_direct + 288 7 CFNetwork 0x259ab0 estimatedPropertyListSize + 33724 8 CoreFoundation 0x24b34 CFArrayApplyFunction + 72 9 CFNetwork 0x2599a0 estimatedPropertyListSize + 33452 10 CFNetwork 0x25c084 estimatedPropertyListSize + 43408 11 CoreFoundation 0x3762c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 12 CoreFoundation 0x368a8 __CFRunLoopDoSource0 + 176 13 CoreFoundation 0x35058 __CFRunLoopDoSources0 + 244 14 CoreFoundation 0x33d88 __CFRunLoopRun + 828 15 CoreFoundation 0x33968 CFRunLoopRunSpecific + 608 16 CFNetwork 0x25ac48 estimatedPropertyListSize + 38228 17 Foundation 0x9ca9c __NSThread__start__ + 732 18 libsystem_pthread.dylib 0x2a90 _pthread_start + 136 19 libsystem_pthread.dylib 0x1fcc thread_start + 8 This is how we build the operation: -(NSOperation*)operationForRequest:(Job*)job { NSURL *url = [NSURL URLWithString:job.url]; NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url]; [request setValue:@"application/json, application/xml, text/plain" forHTTPHeaderField:@"Accept"]; [request setValue:@"application/json" forHTTPHeaderField:@"Content-Type"]; [request setValue:@"no-cache" forHTTPHeaderField:@"Cache-Control"]; [request setValue:[NSString stringWithFormat:@"Bearer %@", [self getToken]] forHTTPHeaderField:@"Authorization"]; [request setHTTPMethod:job.method]; NSData *bodyData = [job.payload dataUsingEncoding:NSUTF8StringEncoding]; [request setHTTPBody:bodyData]; return [[NetworkOperation alloc] initWithRequest:request uuid:job.jobId completionHandler:^(NSString* jobId, NSData *data, NSURLResponse *response, NSError *error) { dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{ @autoreleasepool { RLMRealm *realm = [RLMRealm defaultRealm]; Job *opJob = [Job objectInRealm:realm forPrimaryKey:jobId]; [self processJobResponse:opJob response:response data:data error:error realm:realm]; } }); }]; } This is how the NetworkOperation executes the request: - (void)main { NSURLSession *session = [NSURLSession sharedSession]; NSURLSessionTask *task = [session dataTaskWithRequest:self.request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) { if (self.networkOperationCompletionBlock) { self.networkOperationCompletionBlock(self.uuid, data, response, error); self.networkOperationCompletionBlock = nil; } [self completeOperation]; }]; [task resume]; self.task = task; } crashlog3.crash

I want to get the network-name (domain-name) on my Mac-Machine. Where iin the Settings does this domain name gets configured. I refer to this page which talks about computer name and host name, I could find where my hostname is present (Settings-&amp;gt;General-&amp;gt;Sharing-&amp;gt;local host name) but not anything related to the network-name (local -domain) . Even try to fetch this info using the linux api to getdomainname, api call succeeded but it returns Nothing. #include &amp;lt;iostream&amp;gt; #include &amp;lt;unistd.h&amp;gt; #include &amp;lt;limits.h&amp;gt; #include &amp;lt;cstring&amp;gt; int main() { char domainname[255]; // Get the domain name if (getdomainname(domainname, 255) != 0) { std::cout &amp;lt;&amp;lt; "Error getting domain name" &amp;lt;&amp;lt; std::endl; return 1; } std::cout &amp;lt;&amp;lt; "Domain name: " &amp;lt;&amp;lt; domainname &amp;lt;&amp;lt; std::endl; return 0; } Output Domain name: I even came across Search-Domains, Does it have anything to do with the network-name (domain name of the machine)?