I upgraded my Mac to Sequoia 15.4.1 an i hat to upgrade XCode to Version 16.3.
I access a MQTT Broker by an sending an
mosquitto_sub
request to the Broker.
Now its no longer possible the request fails
i granted Network permission to my App
Networking
RSS for tagExplore the networking protocols and technologies used by the device to connect to Wi-Fi networks, Bluetooth devices, and cellular data services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi! My project has the Local Push Connectivity entitlement for a feature we have requiring us to send low-latency critical notifications over a local, private Wi-Fi network.
We have our NEAppPushProvider creating a SSE connection using the Network framework with our hardware running a server. The server sends a keep-alive message every second. On an iPhone 16 with iOS 18+, the connection is reliable and remains stable for hours, regardless of whether the iOS app is in the foreground, background, or killed.
One of our QA engineers has been testing on an iPhone 13 running iOS 16, and has notice shortly after locking the phone, specifically when not connected to power the device seems to turn off the Wi-Fi radio. So when the server sends a notification, it is not received. About 30s later, it seems to be back on. This happens on regular intervals.
When looking at our log data, the provider does seem to be getting stopped, then restarted shortly after. The reason code is NEProviderStopReasonNoNetworkAvailable, which further validates that the network is getting dropped by the device in regular intervals.
My questions are:
Were there possibly silent changes to the framework between iOS versions that could be the reason we're seeing inconsistent behavior?
Is there a connection type we could use, instead of SSE, that would prevent the device from disconnecting and reconnecting to the Wi-Fi network?
Is there an alternative approach to allow us to maintain a persistent network connection with the extension or app?
Topic:
App & System Services
SubTopic:
Networking
Tags:
Extensions
Network
User Notifications
Network Extension
My App is a rather small menu-bar status-item app with 2 informational windows. It does NOT make use of ANY of the APIs mentioned here: https://developer.apple.com/forums/thread/663874 that are bound to need "Local Network" hence trigger TCC dialog.
Yet - on first run of the app, the dialog pops.
App is Obj-C, and the only APIs used are Notification-Center (for scheduling local notifications to the user), XPC connections and calls to other (our) apps for gathering that information, plus normal AppKit windowing (Controls, Text-fields, etc.) nothing else.
Obviously SOMETHING I do causes the thing - and I know for sure this app DOES NOT NEED access to the local network - only I do not know how to identify the specific API I need to avoid using (or change the way I'm using)
Are there any specific system logs to watch for?
Is there any official set of APIs that will trigger the dialog?
Provided that I cannot avoid this - could this permission be granted via MDM profile payload? Our product comes with
There are multiple report of crashes on URLConnectionLoader::loadWithWhatToDo. The crashed thread in the stack traces pointing to calls inside CFNetwork which seems to be internal library in iOS.
The crash has happened quite a while already (but we cannot detect when the crash started to occur) and impacted multiple iOS versions recorded from iOS 15.4 to 18.4.1 that was recorded in Xcode crash report organizer so far.
Unfortunately, we have no idea on how to reproduce it yet but the crash keeps on increasing and affect more on iOS 18 users (which makes sense because many people updated their iOS to the newer version) and we haven’t found any clue on what actually happened and how to fix it on the crash reports. What we understand is it seems to come from a network request that happened to trigger the crash but we need more information on what (condition) actually cause it and how to solve it.
Hereby, I attach sample crash report for both iOS 15 and 18.
I also have submitted a report (that include more crash reports) with number: FB17775979.
Will appreciate any insight regarding this issue and any resolution that we can do to avoid it.
iOS 15.crash
iOS 18.crash
When I was attempting to establish a TCP connection using NWConnection on a physical iPhone, the connection consistently fails with the error:
connection did change state, new: waiting(POSIXErrorCode(rawValue: 50): Network is down)
connection did change state, new: preparing
connection did change state, new: waiting(POSIXErrorCode(rawValue: 50): Network is down)
However, when running the same code in the iOS Simulator, the connection succeeds without issues.
I have already granted the app permission to access the local network by selecting "Allow [App Name] to find devices on the local network" when prompted.
The issue persists even after restarting the app, device, and server.
Additionally, I have configured the Info.plist file with the following keys:
NSAllowsLocalNetworking
NSLocalNetworkUsageDescription
Here is my code:
func start() -> NWConnection {
let myHost: NWEndpoint.Host = "192.168.1.154" // My MacBook
let myPort: NWEndpoint.Port = 1234
let connection = NWConnection(to: .hostPort(host: myHost, port: myPort), using: .tcp)
connection.stateUpdateHandler = { newState in
print("connection did change state, new: \(newState)")
}
connection.start(queue: .main)
return connection
}
Development environment:
Xcode 15.3
MacOS 14.4.1
Device OS: iOS 18.1
I have a custom VPN app that uses NETunnelProviderManager to install a VPN Profile if one is not already installed. On previous iOS versions this would open the VPN Settings and ask for either the PIN, FaceID or TouchID and install the profile. With iOS 26 beta5 it opens the VPN Settings and stops.
Is this a bug in iOS 26? Have there been changes to NETunnelProviderManager for iOS 26 that I'm not aware of?
FYI we do the samething on macOS 26 beta5 and that works as expected.
In https://developer.apple.com/forums/thread/128705?answerId=405119022#405119022, it is said that
But if it’s holding up connections that match the on demand rules, that’s the correct behaviour.
So if there was an on demand rule to connect for all domains (Connect rule without any matching criteria), all traffic would be held up while in the connecting state. The problem is that a customer can have SSO configured so that auth happens outside of the vpn app.
So sequence would be
Connect for all domains on demand rule triggers vpn connection
VPN, in order to connect, tries auth through a broker app.
VPN is in connecting state and blocks broker app traffic and so auth cannot complete and it cannot connect.
I tried adding an on demand rule for EvaluateConnection and never connect for the auth domains. However, that caused the vpn to never be triggered to connect.
Is it possible to support the scenario of an on demand rule to connect for all domains while having a vpn connection dependent on auth done in a separate app? Do you have any recommendations?
Hello,
Our users are seeing random crashes in our packet filter system extension on macOS. Any help pointing me in the right direction to either avoid the issue or fix it would be greatly appreciated. Attached is the crash log.
Thank you.
packetfilter.crash
Crashed Thread: 2 Dispatch queue: com.apple.network.connections
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000112918700
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Bus error: 10
Termination Reason: Namespace SIGNAL, Code 0xa
Terminating Process: exc handler [40687]
...
Thread 2 Crashed:: Dispatch queue: com.apple.network.connections
0 libsystem_kernel.dylib 0x00007fff2089b46e os_channel_get_next_slot + 230
1 com.apple.NetworkExtension 0x00007fff2e2e2643 __40-[NEFilterPacketInterpose createChannel]_block_invoke + 560
2 libdispatch.dylib 0x00007fff20718806 _dispatch_client_callout + 8
3 libdispatch.dylib 0x00007fff2071b1b0 _dispatch_continuation_pop + 423
4 libdispatch.dylib 0x00007fff2072b564 _dispatch_source_invoke + 2061
5 libdispatch.dylib 0x00007fff20720318 _dispatch_workloop_invoke + 1784
6 libdispatch.dylib 0x00007fff20728c0d _dispatch_workloop_worker_thread + 811
7 libsystem_pthread.dylib 0x00007fff208bf45d _pthread_wqthread + 314
8 libsystem_pthread.dylib 0x00007fff208be42f start_wqthread + 15
I have written an App which extracts data, over WiFi, from an instrument that creates its own WiFi Hotspot.
The instrument provides no internet connection. The iPad version of this App is connects fine and is assigned an IP address by DHCP server running on a MicroChip RN171 wifi module.
iOS assigns an obscure IP address on a completely different subnet. I understand this is iOS' way of "Complaining" that is wasn't assigned an IP address.
Consequently in the case of the iPhone I am forced to manually assign an IP address for the iPhone, the mask and the gateway. Only then is the connection successful.
Anyone know why the iPhone won't talk DHCP to a WiFi module not connected to the internet? Are there perhaps some parameters that I need to adjust on either the iPhone or WiFi module?
Greetings,
I would like to understand this URLCache behavior for two different requests to the same end point but with a different header value. Here is a code with comment explaining the behavior.
// Create a request to for a url.
let url = URL(string: "https://<my url>?f=json")!
var request = URLRequest(url: url)
// Set custom header with a value.
request.setValue("myvalue", forHTTPHeaderField: "CustomField")
// Send request to get the response.
let (data, response) = try await URLSession.shared.data(for: request)
print("data: \(String(describing: String(data: data, encoding: .utf8)))")
print("response: \(response)")
// Create second request to the same url but with different value of custom header field.
var request2 = URLRequest(url: url)
request2.setValue("newvalue", forHTTPHeaderField: "CustomField")
// Check the URL cache for second request and it returns the response
// of the first request even though the second request has different header value.
let cachedResponse = URLCache.shared.cachedResponse(for: request2)
print("cachedResponse: \(cachedResponse?.response)")
Is this a bug in URLCache that request headers are not matched while returning the response?
Is this an expected behavior? If yes, why?
I am developing an App using the Networking framework, which can be either a Socket Server or a Socket Client, such that 2 devices can communicate remotely. For the most part I have it working, except:
I am not sure of the best way to determine the IP Address for the Socket Server in order to allow the Client app to connect. I am currently using either of Cloud Functions, or lookup webpages (such as ipify.org) and even reading the IP addresses locally from within the device (this returns many, but not all of them connect successfully).
These options seem to work if the Socket Server app is connected to the internet with an IPv6 address, but I find that when the Socket Server app is connected with an IPv4 address, the Client app never successfully connects.
How should I:
a) force the Socket Server app to have/use an IPV6 address at all times?
or
b) allow the Client app to connect successfully via an IPv4 address?
And is there a simple way to know what IP Address the Socket Server is listening from?
We have observed an internet access issue after the device enters idle mode on iOS 26 beta 9. Although the Ivanti Secure Access Client appears connected, users are unable to access any resources (internet or intranet) after unlocking the device from idle. When we check the log socket connection looks not disrupted, packets are tunnelled but no resource access. Split tunnel enabled and proxy PAC configured. This was observed on both iOS and iPadOS 26 beta.
Steps to reproduce:
Connecting to the internet, launching the Ivanti client, locking the device, and then unlocking it after a brief period of idle. The issue occurs when the VPN remains connected but no resources are accessible.
I am in the middle of investigating an issue arising in the call to setsockopt syscall where it returns an undocumented and unexpected errno. As part of that, I'm looking for a way to list any socket content filters or any such extensions are in play on the system where this happens.
To do that, I ran:
systemextensionsctl list
That retuns the following output:
0 extension(s)
which seems to indicate there's no filters or extensions in play.
However, when I do:
netstat -s
among other things, it shows:
net_api:
2 interface filters currently attached
2 interface filters currently attached by OS
2 interface filters attached since boot
2 interface filters attached since boot by OS
...
4 socket filters currently attached
4 socket filters currently attached by OS
4 socket filters attached since boot
4 socket filters attached since boot by OS
What would be the right command/tool/options that I could use to list all the socket filters/extensions (and their details) that are in use and applicable when a call to setsockopt is made from an application on that system?
Edit: This is on a macosx-aarch64 with various different OS versions - 13.6.7, 14.3.1 and even 14.4.1.
With the new macOS 15, Apple introduced the new Local Network Privacy feature.
This is causing issues for our customers as - even though they granted the required permission for our software - connections to a server in their local network are being blocked. The situation is not fixed by recent macOS updates.
As far as I know, this issue exists for machines running on Apple Silicon. Systems running macOS versions (e.g. Sonoma) are not affected.
Currently, the workaround is to re-enable the permission under Settings > Privacy & Security > Local Network. The list shows our application with an enabled checkbox. Users now have to de-select the box and then re-select it again for the application to work. They have to do this after each and every reboot of their system, which is slightly annoying (so at the moment we recommend to not upgrade macOS to Sequoia, if possible)
I did some research and saw that other products are also affected by this bug. Is there a solution to this issue or any plans to fix it?
Howdy,
I've been developing a packet tunnel extension meant to run on iOS and MacOS. For development I'm using xcodegen + xcodebuild to assemble a bunch of swift and rust code together.
I'm moving from direct TUN device management on Mac to shipping a Network Extension (appex). With that move I noticed that on some mac laptops NE fails to start completely, whilst on others everything works fine.
I'm using CODE_SIGN_STYLE: Automatic, Apple IDs are within the same team, all devices are registered as dev devices. Signing dev certificates, managed by xcode.
Some suspicious logs:
(NetworkExtension) [com.apple.networkextension:] Signature check failed: code failed to satisfy specified code requirement(s)
...
(NetworkExtension) [com.apple.networkextension:] Provider is not signed with a Developer ID certificate
What could be the issue? Where those inconsistencies across devices might come from?
Hello Everyone,
I am currently using macOS 15.5 and XCode 16.4.
I am using the following code to send/receive multicast packets on multicast group ff02::1 and port 49153 using Apple NF's NWConnectionGroup.
import Network
import Foundation
// Creating a mutlicast group endpoint
let multicastIPv6GroupEndpoint: NWEndpoint = NWEndpoint.hostPort(host: NWEndpoint.Host.ipv6(IPv6Address("ff02::1")!), port: NWEndpoint.Port("49153")!)
do {
let multicastGroupDescriptor: NWMulticastGroup = try NWMulticastGroup (for: [multicastIPv6GroupEndpoint])
let multicastConnectionGroupDescriptor = NWConnectionGroup (with: multicastGroupDescriptor, using: .udp)
multicastConnectionGroupDescriptor.stateUpdateHandler = { state in
print ("🕰️ Connection Group state: \(state)")
if state == .ready {
multicastConnectionGroupDescriptor.send (content: "👋🏻 Hello from the Mac 💻".data (using: .utf8)) { err in
print ("➡️ Now, I am trying to send some messages.")
if let err = err {
print ("💥 Error sending multicast message: \(err)")
} else {
print ("🌚 Initial multicast message sent")
}
}
}
}
multicastConnectionGroupDescriptor.setReceiveHandler { message, content, isComplete in
if let content = content, let messageString = String (data: content, encoding: .utf8) {
print ("⬅️ Received message: \(messageString)")
}
}
multicastConnectionGroupDescriptor.start (queue: .global())
} catch {
print ("💥 Error while creating Multicast Group: \(error)")
}
RunLoop.main.run()
I am able to successfully create a NWConnectionGroup without any warnings/errors.
The issue occurs when the stateUpdateHandler's callback gets invoked.
It first gives me this warning:
nw_listener_socket_inbox_create_socket IPV6_LEAVE_GROUP ff02::1.49153 failed [49: Can't assign requested address
But then it shows me that the state is ready:
🕰️ Connection Group state: ready
After this, when the send is performed, it gives me a bunch of errros:
nw_endpoint_flow_failed_with_error [C1 ff02::1.49153 waiting parent-flow (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, ipv6, uses wifi)] already failing, returning
nw_socket_connect [C1:1] connectx(7, [srcif=0, srcaddr=::.62838, dstaddr=ff02::1.49153], SAE_ASSOCID_ANY, 0, NULL, 0, NULL, SAE_CONNID_ANY) failed: [48: Address already in use]
nw_socket_connect [C1:1] connectx failed (fd 7) [48: Address already in use]
nw_socket_connect connectx failed [48: Address already in use]
nw_endpoint_flow_failed_with_error [C1 ff02::1.49153 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] already failing, returning
There is no other background process running on the same port. I tried using different ports as well as multicast groups but the same error persists.
The same code works fine for an IPv4 multicast group.
I have following questions:
Why am I getting these errors specifically for IPv6 multicast group but not for IPv4 multicast group?
Are there any configurations that needed to be done in order to get this working?
Hi,
I am having a ton of issues with the new multicast/network entitlements requirements on MacOS.
Basically, since my app didn't request these new entitlements until recently, if the app had been installed without these permissions enabled, it will not pick up the new permissions once they are enabled. The only options I had were to create a new user, and install the app under the new user, which works, but is not a real solution for users.
This is really problematic, as there is no way currently to remove or change these network permissions once they are established. Is there a way to fix this? Or some other workarounds I am missing?
Thanks
Also via the documentation: TN3179: Understanding local network privacy | Apple Developer Documentation
"There's no guarantee that it'll actually trigger the alert”
And
"On macOS there’s no way to reset your program’s Local Network privilege to the undetermined state (FB14944392). One alternative is to run your program in a virtual machine (VM). To retest, restore the VM from a snapshot taken before you installed your program.”
Topic:
App & System Services
SubTopic:
Networking
Our application uses NEFilterPacketProvider to filter network traffic and we sometimes get a wired crash when removing/updating the network extension.
It only happens on MacOS 11-12 .
The crashing thread is always this one and it shows up after I call the completionHandler from the stopFilter func
Application Specific Information:
BUG IN CLIENT OF LIBDISPATCH: Release of a suspended object
Thread 6 Crashed:: Dispatch queue: com.apple.network.connections
0 libdispatch.dylib 0x00007fff2039cc35 _dispatch_queue_xref_dispose.cold.1 + 24
1 libdispatch.dylib 0x00007fff20373808 _dispatch_queue_xref_dispose + 50
2 libdispatch.dylib 0x00007fff2036e2eb -[OS_dispatch_source _xref_dispose] + 17
3 libnetwork.dylib 0x00007fff242b5999 __nw_queue_context_create_source_block_invoke + 41
4 libdispatch.dylib 0x00007fff2036d623 _dispatch_call_block_and_release + 12
5 libdispatch.dylib 0x00007fff2036e806 _dispatch_client_callout + 8
6 libdispatch.dylib 0x00007fff203711b0 _dispatch_continuation_pop + 423
7 libdispatch.dylib 0x00007fff203811f4 _dispatch_source_invoke + 1181
8 libdispatch.dylib 0x00007fff20376318 _dispatch_workloop_invoke + 1784
9 libdispatch.dylib 0x00007fff2037ec0d _dispatch_workloop_worker_thread + 811
10 libsystem_pthread.dylib 0x00007fff2051545d _pthread_wqthread + 314
11 libsystem_pthread.dylib 0x00007fff2051442f start_wqthread + 15
I do have a DispatchSourceTimer but I cancel it in the stop func.
Any ideas on how to tackle this?
Our application has initiated an NSURLSession data task, and we have received an initiation ID. However, Application not received callback on the subsequent activity: the task has not been requested, has not timed out, and no error callback has been received.
[06/17 09:29:40:559][ 0x282a7d8c0] Requested TaskIdentifier 120
2025-06-17 09:29:40.623337 +0530 nsurlsessiond SUBMITTING: com.apple.CFNetwork-cc-166-373-Task .<120>:A71666 default
2025-06-17 09:29:40.631280 +0530 dasd Submitted Activity: com.apple.CFNetwork-cc-166-373-Task .<120>:A71666 at priority 10 default
Seen couple of rejection with for CPUUsagePolicy and MemoryPressurePolicy
2025-06-17 09:29:40.989360 +0530 dasd com.apple.CFNetwork-cc-166-373-Task .<120>:A71666:[
{name: CPUUsagePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[Max allowed CPU Usage level]: Required:90.00, Observed:95.00},]}}
{name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}}
], FinalDecision: Must Not Proceed} default
2025-06-17 10:55:22.500277 +0530 dasd com.apple.CFNetwork-cc-166-373-Task .<120>:A71666:[
{name: MemoryPressurePolicy, policyWeight: 5.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[memoryPressure]: Required:1.00, Observed:2.00},]}}
], FinalDecision: Must Not Proceed} default
And more an hour later then it throws with an error BUT NEVER indicated the same to client
2025-06-17 10:55:27.426549 +0530 WAVE PTX Task .<120> is for <>.<>.<120> default
2025-06-17 10:55:27.776951 +0530 nsurlsessiond Task .<120> summary for task failure {transaction_duration_ms=5147145, response_status=-1, connection=0, reused=1, request_start_ms=0, request_duration_ms=0, response_start_ms=0, response_duration_ms=0, request_bytes=0, response_bytes=0, cache_hit=false} default
2025-06-17 10:55:27.777096 +0530 nsurlsessiond NDSession <714296D7-20F9-4A0A-8C31-71FB67F39A56> Task .<120> for client will be retried after error Error Domain=_nsurlsessiondErrorDomain Code=6 UserInfo={NSErrorFailingURLStringKey=, NSErrorFailingURLKey=, _NSURLErrorRelatedURLSessionTaskErrorKey=, _NSURLErrorFailingURLSessionTaskErrorKey=} - code: 6 default
Then It got resumed and says successful but never got any callback on the same to client
2025-06-17 10:55:28.877245 +0530 nsurlsessiond NDSession <714296D7-20F9-4A0A-8C31-71FB67F39A56> Task .<120> resuming default
2025-06-17 10:55:55.225456 +0530 nsurlsessiond Task .<120> received response, status 401 content K default
2025-06-17 10:55:55.250371 +0530 nsurlsessiond Task .<120> finished successfully default
Please refer feedback for diagnose logs:
https://feedbackassistant.apple.com/feedback/18173303
iOS Development environment
Xcode 16.4, macOS 15.6.1 (24G90)
Run-time configuration: iOS 17.2+
Short Description
After having successfully established an NWConnection (either as UDP or TCP), and subsequently receiving the error code:
UDP Connection failed: 57 The operation couldn't be completed. (Network.NWError error 57 - Socket is not connected), available Interfaces: [enO]
via
NWConnection.stateUpdateHandler = { (newState) in ... } while newState == .failed
the data connection does not restart by itself once cellular (RF) telephony coverage is established again.
Detailed Description
Context: my app has a continuous cellular data connection while in use. Either a UDP or a TCP connection is established depending on the user settings.
The setup data connection works fine until the data connection gets disconnected by loss of connection to a available cellular phone base station. This disconnection simply occurs in very poor UMTS or GSM cellular phone coverage. This is totally normal behavior in bad reception areas like in mountains with signal loss.
STEPS TO REPRODUCE
Pre-condition
App is running with active data connection.
Action
iPhone does loss the cellular data connection previously setup. Typically reported as network error code 57.
Observed
The programmed connection.stateUpdateHandler() is called in network connection state '.failed' (OK).
The self-programmed data re-connection includes:
a call to self.connection.cancel()
a call to self.setupUDPConnection() or self.setupConnection() depending on the user settings to re-establish an operative data connection.
However, the iPhone's UMTS/GSM network data (re-)connection state is not properly identified/notified via NWConnection API. There's no further network state notification by means of NWConnection even though the iPhone has recovered a cellular data network.
Expected
The iPhone or any other means automatically reconnects the interrupted data connection on its own. The connection.stateUpdateHandler() is called at time of the device's networking data connection (RF) recovering, subsequently to a connection state failed with error code 57, as the RF module is continuously (independently from the app) for available telephony networks.
QUESTION
How to systematically/properly detect a cellular phone data network reconnection readiness in order to causally reinitialize the NWConnection data connection available used in app.
Relevant code extract
Setup UDP connection (or similarly setup a TCP connection)
func setupUDPConnection() {
let udp = NWProtocolUDP.Options.init()
udp.preferNoChecksum = false
let params = NWParameters.init(dtls: nil, udp: udp)
params.serviceClass = .responsiveData // service type for medium-delay tolerant, elastic and inelastic flow, bursty, and long-lived connections
connection = NWConnection(host: NWEndpoint.Host.name(AppConstant.Web.urlWebSafeSky, nil), port: NWEndpoint.Port(rawValue: AppConstant.Web.urlWebSafeSkyPort)!, using: params)
connection.stateUpdateHandler = { (newState) in
switch (newState) {
case .ready:
//print("UDP Socket State: Ready")
self.receiveUDPConnection(). // data reception works fine until network loss
break
case .setup:
//print("UDP Socket State: Setup")
break
case .cancelled:
//print("UDP Socket State: Cancelled")
break
case .preparing:
//print("UDP Socket State: Preparing")
break
case .waiting(let error):
Logger.logMessage(message: "UDP Connection waiting: "+error.errorCode.description+" \(error.localizedDescription), available Interfaces: \(self.connection.currentPath!.availableInterfaces.description)", LoggerLevels.Error)
break
case .failed(let error):
Logger.logMessage(message: "UDP Connection failed: "+error.errorCode.description+" \(error.localizedDescription), available Interfaces: \(self.connection.currentPath!.availableInterfaces.description)", LoggerLevels.Error)
// data connection retry (expecting network transport layer to be available)
self.reConnectionServer()
break
default:
//print("UDP Socket State: Waiting or Failed")
break
}
self.handleStateChange()
}
connection.start(queue: queue)
}
Handling of network data connection loss
private func reConnectionServer() {
self.connection.cancel()
// Re Init Connection - Give a little time to network recovery
let delayInSec = 30.0. // expecting actually a notification for network data connection availability, instead of a time-triggered retry
self.queue.asyncAfter(deadline: .now() + delayInSec) {
switch NetworkConnectionType {
case 1:
self.setupUDPConnection() // UDP
break
case 2:
self.setupConnection() // TCP
break
default:
break
}
}
}
Does it necessarily require the use of CoreTelephony class CTTelephonyNetworkInfo or class CTCellularData to get notifications of changes to the user’s cellular service provider?