Hello eveybody,Currently I'm working on an app which connects to a device. During testing I encounter an internal error of NEHotspotConfigurationErrorDomain. See the log snippet:Domain=NEHotspotConfigurationErrorDomain Code=8 "internal error." UserInfo={NSLocalizedDescription=internal error.}This error appears randomly. In one day I encountered it three times. The only solution I can think of is catching this error somehow and then telling the user to restart the device.After this error appears, the wifi functionality of iOS in all third party apps seems to be broken. Only restarting helps as far as I know. Also there seems to be nothing we as app developers can do about it. Therefor I wonder if there is some way to prevent this error somehow? The only solution I can think of is catching this error somehow and then telling the user to restart the device.Also since there is not much information about this error on the web, it would be really nice if someone can clarify whats going on with this error.Regards.
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 everyone,
I’m working with the DNSServiceGetAddrInfo API and came across the following statement in the documentation:
If the call succeeds then it initializes the DNSServiceRef, returns kDNSServiceErr_NoError, and the query begins and will last indefinitely until the client terminates the query by passing this DNSServiceRef to DNSServiceRefDeallocate(_)
I’m trying to understand exactly what this means in practice. Specifically, after receiving a response with kDNSServiceFlagsMoreComing, being set to 0 does it imply that the OS itself continues querying the DNS periodically or indefinitely, even after we've already received some results? Or does it only continue fetching additional results related to the initial query until we explicitly terminate it?
Any clarification on the behavior of this query would be greatly appreciated!
Thanks in advance!
Topic:
App & System Services
SubTopic:
Networking
Hi all,
I’m developing a watchOS app that uses a WebSocket API to process voice audio. However, I keep encountering this error when trying to establish the connection:
nw_endpoint_flow_failed_with_error [C1 <server URL>:443 failed parent-flow (unsatisfied (Path was denied by NECP policy), interface: ipsec2, ipv4, ipv6, proxy)] already failing, returning
I’ve read Technical Note TN3135, which outlines an exception for audio streaming apps. My app is an audio streaming app, and I’ve already added background audio mode to the app’s capabilities. However, I’m not sure what else is required to meet the exception described in TN3135.
Questions
How do I meet the exception outlined in TN3135 for WebSocket audio streaming on watchOS?
Does NECP enforce additional restrictions even with background audio enabled, and how can I address this?
Any guidance or examples of implementing WebSocket audio streaming on watchOS would be greatly appreciated.
Thanks!
I am unable to apply for Multicast Entitlement at https://developer.apple.com/contact/request/networking-multicast
The reason for this is unclear. I have paid for a developer account and believe I'm up to date with all agreements.
Topic:
App & System Services
SubTopic:
Networking
Hello, I'm having some problems starting my DNS proxy network extension.
Even after I call NEDNSProxyManager.saveToPreference() successfully I don't see any logs from my dns proxy.
This is the code from the user space app:
import SwiftUI
import NetworkExtension
func configureDNSProxy() {
let dnsProxyManager = NEDNSProxyManager.shared()
dnsProxyManager.loadFromPreferences { error in
if let error = error {
print("Error loading DNS proxy preferences: \(error)")
return
}
dnsProxyManager.localizedDescription = "my DNS proxy"
let proto = NEDNSProxyProviderProtocol()
proto.providerBundleIdentifier = "com.myteam.dns-proxy-tests.ne"
dnsProxyManager.providerProtocol = proto
// Enable the DNS proxy.
dnsProxyManager.isEnabled = true
dnsProxyManager.saveToPreferences { error in
if let error = error {
print("Error saving DNS proxy preferences: \(error)")
} else {
NSLog("DNS Proxy enabled successfully")
}
}
}
}
@main
struct dns_proxy_testsApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
}
init() {
configureDNSProxy()
}
}
This is the code for my network extension(DNSProxyProvider.swift):
import NetworkExtension
class DNSProxyProvider: NEDNSProxyProvider {
override func startProxy(options:[String: Any]? = nil, completionHandler: @escaping (Error?) -> Void) {
NSLog("dns proxy ne started")
completionHandler(nil)
}
override func stopProxy(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) {
NSLog("dns proxy ne stopped")
completionHandler()
}
override func sleep(completionHandler: @escaping () -> Void) {
NSLog("dns proxy ne sleep")
completionHandler()
}
override func wake() {
NSLog("dns proxy ne wake")
}
override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool {
NSLog("dns proxy ne flow")
return true
}
}
The bundle identifier for my network extension is: com.myteam.dns-proxy-tests.ne and both the user space app and the network extension have the DNS Proxy capability. Both have the same app group capability with the same group name group.com.myteam.dns-proxy-test.
The info.plist from the network extension look like this(I didn't really modify it from the default template created by xcode)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NetworkExtension</key>
<dict>
<key>NEMachServiceName</key>
<string>$(TeamIdentifierPrefix)com.example.app-group.MySystemExtension</string>
<key>NEProviderClasses</key>
<dict>
<key>com.apple.networkextension.dns-proxy</key>
<string>$(PRODUCT_MODULE_NAME).DNSProxyProvider</string>
</dict>
</dict>
</dict>
</plist>
In the logs I do see DNS Proxy enabled successfully and also I see:
NESMDNSProxySession[Primary Tunnel:my DNS proxy:<...>:(null)] starting with configuration: {
name = my DNS proxy
identifier = <..>
applicationName = dns-proxy-tests
application = com.myteam.dns-proxy-tests
grade = 1
dnsProxy = {
enabled = YES
protocol = {
type = dnsProxy
identifier = <...>
identityDataImported = NO
disconnectOnSleep = NO
disconnectOnIdle = NO
disconnectOnIdleTimeout = 0
disconnectOnWake = NO
disconnectOnWakeTimeout = 0
disconnectOnUserSwitch = NO
disconnectOnLogout = NO
includeAllNetworks = NO
excludeLocalNetworks = NO
excludeCellularServices = YES
excludeAPNs = YES
excludeDeviceCommunication = YES
enforceRoutes = NO
pluginType = com.myteam.dns-proxy-tests
providerBundleIdentifier = com.myteam.dns-proxy-tests.ne
designatedRequirement = identifier "com.myteam.dns-proxy-tests.ne" <...> /* exists */
}
}
}
But then I see:
Checking for com.myteam.dns-proxy-tests.ne - com.apple.networkextension.dns-proxy
But then finally
Found 0 registrations for com.myteam.dns-proxy-tests.ne (com.apple.networkextension.dns-proxy)
So I think that last log probably indicates the problem.
I'm a bit lost at what I'm doing wrong so I'd be super thankful for any pointer!
I have a question regarding /etc/pf.conf.
If I use this rule,
rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080
all other traffic on bridge100 will not function properly, even the traffic that is not destined for 192.168.2.104.
Additionally, the hotspot generated through bridge100 will also become unavailable.
Even if I comment out this rule and run sudo pfctl -e -f /etc/pf.conf, the problem still persists. The situation will only return to normal when I restart my Mac. my macos:15.3.2
my /etc/pf.conf
#
scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"
rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"
Topic:
App & System Services
SubTopic:
Networking
I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt:
"Would like to filter network content (Allow / Don't Allow)".
However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work.
Is there a special configuration required for TestFlight? Has anyone encountered this issue before?
Thanks!
We're experiencing an issue with Local Network Permission. When trying to connect to a socket, the Local Network Permission alert pops up. To trigger the permission request at the start of the app, we used the following code to ask for permission and receive a callback on whether it's granted. However, this approach doesn't always trigger the permission alert, or it gets automatically dismissed after 30 seconds, only to reappear later. What could be causing this inconsistent behavior?
func checkLocalNetworkPermission(_ completed: Optional<(Bool) -> Void> = .none) {
DispatchQueue.global(qos: .userInitiated).async {
let hostName = ProcessInfo.processInfo.hostName
let isGranted = hostName.contains(".local")
if let completed {
DispatchQueue.main.async {
completed(isGranted)
}
}
}
}
I am working on a macos application that uses NetworkExtension and works fine in the debug environment. However, when I use the Release package, I am always prompted that my description file does not contain NetworkExtension. I am sure that my description file does contain NetworkExtension. How to solve this problem
I have a question regarding /etc/pf.conf.
If I use this rule,
rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080
all other traffic on bridge100 will not function properly, even the traffic that is not destined for 192.168.2.104.
Additionally, the hotspot generated through bridge100 will also become unavailable.
Even if I comment out this rule and run sudo pfctl -e -f /etc/pf.conf, the problem still persists. The situation will only return to normal when I restart my Mac.
my macos:15.3.2
my /etc/pf.conf
#
scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"
rdr pass on bridge100 inet proto tcp from 192.168.2.104 to any port {80, 443, 8883} -> 127.0.0.1 port 8080
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"
Topic:
App & System Services
SubTopic:
Networking
Hi,
I have been reviewing some previous discussions around networking in macOS, and I’d like to clarify my understanding of the differences between the kernel-space network stack and user-space network stack and validate this understanding based on the information shared in earlier threads.
I’m also curious about how these differences impact macOS applications, particularly those requiring maintaining many simultaneous network connections.
Understanding Kernel-Space vs User-Space Network Stack
Kernel-Space Network Stack (BSD Sockets):
The kernel-space networking stack refers to the traditional networking layer that runs in the kernel and handles network communication via BSD sockets. This stack is lower-level and interacts directly with the operating system's networking drivers and hardware. All network connections managed through this stack require a socket (essentially a file descriptor) to be opened, which places limits on the number of file descriptors that can be used (for example, the default 64K limit for sockets). The kernel network stack is traditionally used on macOS (and other UNIX-based systems) for networking tasks, such as when you use system APIs like BSD sockets.
User-Space Network Stack (Network Framework): The user-space network stack in macOS (via the Network framework) allows applications to handle networking tasks without directly using the kernel. This provides more flexibility and performance benefits for certain types of network operations, as the networking stack is managed in user space rather than kernel space. This approach reduces overhead and allows more control over networking configurations. In theory, with user-space networking, the application wouldn't be bound by kernel-level socket limits, and it could handle many more simultaneous connections efficiently.
In previous posts on that thread, Quinn mentioned that the Network framework in macOS can rely on the user-space stack (by default) for network operations, but there are still cases where macOS falls back to using the kernel stack (i.e., BSD sockets) under certain conditions. One key example is when the built-in firewall is enabled. This prevents user-space networking from functioning as expected, and the system defaults to using the kernel's BSD sockets for network communication.
In the same discussion, it was also highlighted that NECP (Network Extension Control Plane) could place further limitations on user-space networking, and eventually, systems may run into issues like ENOSPC errors due to excessive simultaneous network flows. This suggests that while user-space networking can offer more flexibility, it's not immune to limits imposed by other system resources or configurations.
Given the information above, I wanted to confirm:
Is the above understanding correct and does the macOS Network framework still use the user-space networking stack in macOS 14 and beyond?
Under what conditions would the system fall back to using the kernel stack (BSD sockets) instead of the user-space stack? For example, does enabling the firewall still disable user-space networking?
What is the practical impact of this fallback on applications that require many simultaneous network connections? Specifically, are there any limitations like the 64K socket limit that developers should be aware of when the system uses the user space stack, and what are the best practices to manage large numbers of connections?
Our company has a VPN client that uses the Packet Tunnel Provider network extension and when 18 came out we noticed that we were no longer seeing DNS requests get sent to the VPNs TUN interface.
Do a packet trace, once the VPN becomes active we see requests to _dns.resolver.arpa and 12-courier.push.apple.com, which both get resolved as expected. Also our main app that controls the VPN service and does authentication has to resolve a hostname to get to an authentication service and we see those requests just fine as well. However, when we try to resolve by going to a webpage in Safari we see no DNS request corresponding to that.
What are we missing? At first I thought it was the RFC9461 stuff but from the packet traces I don't believe that is the case.
I have also tried other networking tools to send the DNS requests and that failed as well.
The Download is not Working in the background mode even if i entitled all the necessary permission for the application it only works when the app is connected to xcode due to xcode keep the session alive but if try after removing the connection from the xcode the app not able to keep the download after 45 sec what may be the reason
my code
var request = URLRequest(url: url)
request.httpMethod = "GET"
let bearerToken = SyncManager.accessToken
request.setValue("Bearer \(bearerToken)", forHTTPHeaderField: "Authorization")
let uniqueIdentifier = "\(self.vdmsId)_\(UUID().uuidString)"
backgroundTaskID = UIApplication.shared.beginBackgroundTask { [weak self] in
if let taskID = self?.backgroundTaskID {
UIApplication.shared.endBackgroundTask(taskID)
self?.backgroundTaskID = .invalid
}
}
let CursessionConfig = URLSessionConfiguration.background(withIdentifier: uniqueIdentifier)
CursessionConfig.isDiscretionary = false
CursessionConfig.sessionSendsLaunchEvents = true
CursessionConfig.shouldUseExtendedBackgroundIdleMode = true
// Set timeout intervals
CursessionConfig.timeoutIntervalForResource = 24 * 60 * 60 // 24 hours
CursessionConfig.timeoutIntervalForRequest = 60 * 60 // 1 hour
let Cursession = URLSession(configuration: CursessionConfig, delegate: self, delegateQueue: nil)
self.CurInstanceSession = Cursession
self.session = Cursession
if SyncManager.activeSessions == nil {
SyncManager.activeSessions = [URLSession]()
}
SyncManager.activeSessions?.append(Cursession)
self.downloadCompletionHandler = completion
let CurdownloadTask = Cursession.downloadTask(with: request)
CurdownloadTask.resume()
is there any solutions and i have entitled all the neccessary permisssions like background fetch, process and i also tries with the UIApplication.shared.beginBackgroundTask but after 45 sec it gets terminated all of the suden what may be the issue
Topic:
App & System Services
SubTopic:
Networking
I created a self signed CA and use it to generate/sign a client cert using openssl. Then I use the self signed client cert to do TLS client authentication with my server (which also uses the self signed CA). The issue I have is when I validate the self signed CA, by calling SecTrustEvaluateAsyncWithError, it always complains this error “'DigiCert Global Root G3' certificate is not trusted". However that CA (DigiCert Global Root G3) is not my self signed CA (my CA is 'MQTTSampleCA' and I attached a dump of the my CA cert in the PR in the end of this post), so I'm confused why the API keeps complaining that CA. After some researching, I see that is a well known CA so I download its cert from https://www.digicert.com/kb/digicert-root-certificates.htm, install and trust it on my iOS device, but that doesn't help and I still get the same error. I provide all the repro steps in this PR: https://github.com/liumiaojq/EmCuTeeTee/pull/1, including how I generate the certs and the source codes of a test app that I used to do cert validation. I appreciate if anyone can share insights how to resolve this error.
Feedback Ticket: FB13812251
Problem Statement: We are currently facing internet connectivity issue with our VPN application where we try to disconnect the VPN from the Packet Tunnel Network Extension using - (void)cancelTunnelWithError:(nullable NSError *)error. Which API to use to disconnect the VPN from Packet Tunnel as VPN app is not running such that device retains its internet connectivity as soon as VPN disconnects.
Configuration: We have configured PacketTunnelProvider with the following settings:
(NETunnelProviderManager *)tunnelProvider.protocolConfiguration.includeAllNetworks = YES;
(NETunnelProviderManager *)tunnelProvider.protocolConfiguration.excludeLocalNetworks = NO;
(NETunnelProviderManager *)tunnelProvider.protocolConfiguration.enforceRoutes = NO;
These settings are applied from the VPN app and allow us to successfully establish a VPN connection, with all traffic being routed through the tunnel as expected.We are setting above properties to address local net attack.
Issue we are facing:
However, we encounter a problem when we attempt to disconnect the VPN from. When we call the following method from PacketTunnel network extension:
(void)cancelTunnelWithError:(nullable NSError *)error
Upon calling this method, the VPN disconnects as expected, but the device loses all internet connectivity and is unable to access any resources. This is not the desired behavior.
Observation : Interestingly, when we call the following method from the app side. The VPN disconnects and the device retains its internet connectivity.
[enabledConfig.connection stopVPNTunnel];
We would like to achieve the same behavior when disconnecting the VPN from the Network Extension. So we are looking for an API that could be called from NE without causing any internet connectivity issue.
Any guidance on how to resolve this issue would be greatly appreciated.
Hi,
We are working on an app that communicates over a UDP connection on the local network. In our testing, we have a Python UDP client running on the same network, which responds when we send a message to a broadcast IP (255.255.255.255). This setup works as expected on an iOS 15 device.
However, when we test the same scenario on an iOS 18 device, the UDP communication doesn't seem to reach the Python UDP client. We've verified that the UDP client and the iOS device are on the same network, and the Python client is responding correctly.
Has Apple introduced any restrictions or changes regarding UDP broadcast behavior in iOS 18? Is broadcasting to 255.255.255.255 still supported, or has this functionality been limited in recent iOS versions?
I am trying to connect an iPhone 16 (iOS 18.3) to a Wi-Fi device with the SSID "DIRECT-DR_6930_KP201128", but every time, without being able to enter the Wi-Fi password, the message "Unable to join the network 'DIRECT-DR_6930_KP201128'" is displayed. Below are the system logs from the connection failure. Could you please tell me the cause of the connection failure?
By the way, an iPhone SE 2nd (iOS 18.2.1) can connect to the same Wi-Fi device without any issues.
System Logs:
・Jan 31 19:18:14 900-iPhone-16-docomo Preferences(WiFiKit)[351] : {ASSOC-} association finished for DIRECT-DR_6930_KP201128 - success 0
・Jan 31 19:18:14 900-iPhone-16-docomo runningboardd(RunningBoard)[33] : Assertion 33-351-4412 (target:[app<com.apple.Preferences(DE1AB487-615D-473C-A8D6-EAEF07337B18)>:351]) will be created as inactive as start-time-defining assertions exist
・Jan 31 19:18:14 900-iPhone-16-docomo Preferences(WiFiKit)[351] : association failure: (error Error Domain=com.apple.wifikit.error Code=12 "Unknown Error" UserInfo={NSDebugDescription=Unknown Error, NSUnderlyingError=0x303307660 {Error Domain=com.apple.corewifi.error.wifid Code=-3938 "(null)"}})
・Jan 31 19:18:14 900-iPhone-16-docomo Preferences(WiFiKit)[351] : dismissing credentials view controller for DIRECT-DR_6930_KP201128
I am writing to seek clarification on two technical issues related to iOS frameworks (CoreBluetooth and NetworkExtension). These observations are critical for optimizing our app's performance, and I would appreciate any official guidance or documentation references.
CoreBluetooth Scanning Frequency and Cycle
Issue:
We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval).
Questions:
Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)?
Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals?
Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner?
Test Context:
Device: iPhone 13 mini (iOS 17.6.1)
Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])
NEHotspotConfigurationManager Workflow and Latency
Issue:
Using NEHotspotConfigurationManager.shared.apply(_:) to connect to Wi-Fi occasionally takes up to 8 seconds to complete.
Questions:
What is the internal workflow of the apply method? Does it include user permission checks, SSID scanning, authentication, or IP assignment steps?
Are there known scenarios where this method would block for extended periods (e.g., waiting for user interaction, network timeouts)?
Is the latency related to system-level retries or radio coexistence with other wireless activities (e.g., Bluetooth)?
Test Context:
Configuration: NEHotspotConfiguration(ssid: "TestSSID")
Behavior: Delay occurs even when the Wi-Fi network is in range and credentials are correct.
Hi,
I am working on a use case where I want to read the wifi signal strength data in the terms of RSSI (Received Signal Strength Indicator) values (or) any other way of representation. when my iPhone is connected to the wifi and Move around the house.
Is this use case possible ? If yes, what are all the entitlements that I have to obtain?
I have some concerns related to shortening the lifetime of certificates, as per
https://support.apple.com/en-gb/102028
Does this apply to Private CA root certificates?
And if yes:
does it apply if I use ATS and higher level API like URLSession
does it apply it I carry my root CA cert in my app payload and use low level libraries without ATS support?