I implemented a Network Extension in the macOS, use NETransparentProxyProvider. After installing and enabling it, I implemented a UDP client to test its. I found that the UDP client failed to send the data successfully (via sendto, and it returned a success), and when using Wireshark to capture the network data packet, I still couldn't see this UDP data packet.
The code for Network Extension is like this:
@interface MyTransparentProxyProvider : NETransparentProxyProvider
@end
@implementation MyTransparentProxyProvider
- (void)startProxyWithOptions:(NSDictionary *)options completionHandler:(void (^)(NSError *))completionHandler
{
NETransparentProxyNetworkSettings *objSettings = [[NETransparentProxyNetworkSettings alloc] initWithTunnelRemoteAddress:@"127.0.0.1"];
// included rules
NENetworkRule *objIncludedNetworkRule = [[NENetworkRule alloc] initWithRemoteNetwork:nil
remotePrefix:0
localNetwork:nil
localPrefix:0
protocol:NENetworkRuleProtocolAny
direction:NETrafficDirectionOutbound];
NSMutableArray<NENetworkRule *> *arrIncludedNetworkRules = [NSMutableArray array];
[arrIncludedNetworkRules addObject:objIncludedNetworkRule];
objSettings.includedNetworkRules = arrIncludedNetworkRules;
// apply
[self setTunnelNetworkSettings:objSettings completionHandler:
^(NSError * _Nullable error)
{
// TODO
}
];
if (completionHandler != nil)
completionHandler(nil);
}
- (BOOL)handleNewFlow:(NEAppProxyFlow *)flow
{
if (flow == nil)
return NO;
char szProcPath[PROC_PIDPATHINFO_MAXSIZE] = {0};
audit_token_t *lpAuditToken = (audit_token_t*)flow.metaData.sourceAppAuditToken.bytes;
if (lpAuditToken != NULL)
{
proc_pidpath_audittoken(lpAuditToken, szProcPath, sizeof(szProcPath));
}
if ([flow isKindOfClass:[NEAppProxyTCPFlow class]])
{
NWHostEndpoint *objRemoteEndpoint = (NWHostEndpoint *)((NEAppProxyTCPFlow *)flow).remoteEndpoint;
LOG("-MyTransparentProxyProvider handleNewFlow:] TCP flow! Process: (%d)%s, %s Remote: %s:%s, %s",
lpAuditToken != NULL ? audit_token_to_pid(*lpAuditToken) : -1,
flow.metaData.sourceAppSigningIdentifier != nil ? [flow.metaData.sourceAppSigningIdentifier UTF8String] : "",
szProcPath,
objRemoteEndpoint != nil ? (objRemoteEndpoint.hostname != nil ? [objRemoteEndpoint.hostname UTF8String] : "") : "",
objRemoteEndpoint != nil ? (objRemoteEndpoint.port != nil ? [objRemoteEndpoint.port UTF8String] : "") : "",
((NEAppProxyTCPFlow *)flow).remoteHostname != nil ? [((NEAppProxyTCPFlow *)flow).remoteHostname UTF8String] : ""
);
}
else if ([flow isKindOfClass:[NEAppProxyUDPFlow class]])
{
NSString *strLocalEndpoint = [NSString stringWithFormat:@"%@", ((NEAppProxyUDPFlow *)flow).localEndpoint];
LOG("-[MyTransparentProxyProvider handleNewFlow:] UDP flow! Process: (%d)%s, %s LocalEndpoint: %s",
lpAuditToken != NULL ? audit_token_to_pid(*lpAuditToken) : -1,
flow.metaData.sourceAppSigningIdentifier != nil ? [flow.metaData.sourceAppSigningIdentifier UTF8String] : "",
szProcPath,
strLocalEndpoint != nil ? [strLocalEndpoint UTF8String] : ""
);
}
else
{
LOG("-[MyTransparentProxyProvider handleNewFlow:] Unknown flow! Process: (%d)%s, %s",
lpAuditToken != NULL ? audit_token_to_pid(*lpAuditToken) : -1,
flow.metaData.sourceAppSigningIdentifier != nil ? [flow.metaData.sourceAppSigningIdentifier UTF8String] : "",
szProcPath
);
}
return NO;
}
@end
The following methods can all enable UDP data packets to be successfully sent to the UDP server:
1.In -[MyTransparentProxyProvider startProxyWithOptions:completionHandler:], add the exclusion rule "The IP and port of the UDP server, the protocol is UDP";
2.In -[MyTransparentProxyProvider startProxyWithOptions:completionHandler:], add the exclusion rule "All IPs and ports, protocol is UDP";
3.In -[MyTransparentProxyProvider handleNewFlow:] or -[MyTransparentProxyProvider handleNewUDPFlow:initialRemoteEndpoint:], process the UDP Flow and return YES.
Did I do anything wrong?
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
We have a customer reporting a bunch of problems with our (Transparent Proxy Provider-based) suite. Looking at a sysdiagnose, I see that our GUI applet was killed:
Termination Reason: Namespace PORT_SPACE, Code 14123288431434181290 (Limit 305834 ports) Exceeded system-wide per-process Port Limit
Looking at the top.txt file from it, I see that it has 193,086 ports -- compared to about ~250 on one of my test systems.
Has anyone run into this? Any idea what might be causing it? (I'm still poring over the sysdiagnose, but I don't see any kernel logs around that time -- except that our process does close a dozen or so ports because of cancellation.)
Problem :
Connection error occurs in iOS26 beta while connecting to the device's softap via commercial app (Socket exception errSSLfeerBadCert CFSreamErrorDomainSSL code -9825).
iOS 18 release version does not occur.
Why does it cause problems? Does the iOS 26 version not cause problems? Is there a way to set it up in the app so that the iOS 26 beta doesn't cause problems?
error :
"alias":"SOCKET_LOG",
"additional":{"currentNetworkStatus":"socket e=errSSLPeerBadCert ns WifiStatus: Connected Error Domain kCFStreamErrorDomainSSL Code-9825 "(null)"
UserInfo={NSLocalizedRecoverySuggestion=Error code definition can be found in Apple's SecureTransport.h}
Description :
It's an issue that happens when you connect our already mass-produced apps to our home appliances (using SoftAP), and it's currently only happening in iOS 26 beta. This particular issue didn't appear until iOS 18 version.
Let me know to make sure that this issue will persist with the official release of iOS 26?
If the issue continues to occur with the official version, would you share any suggestions on how to mitigate or avoid it.
Also, it would be helpful to find out if there are known solutions or processes such as exemptions to fix this issue.
Hi folks, I'm building an iOS companion app to a local hosted server app (hosted on 0.0.0.0). The MacOS app locally connects to this server hosted, and I took the approach of advertising the server using a Daemon and BonjourwithTXT(for port) and then net service to resolve a local name. Unfortunately if there's not enough time given after the iPhone/iPad is plugged in (usb or ethernet), the app will cycle through attempts and disconnects many times before connecting and I'm trying to find a way to only connect when a viable en interface is available.
I've run into a weird thing in which the en interface only becomes seen on the NWMonitor after multiple connection attempts have been made and failed. If I screen for en before connecting it simply never appears. Is there any way to handle this such that my app can intelligently wait for an en connection before trying to connect? Attaching my code although I have tried a few other setups but none has been perfect.
func startMonitoringAndBrowse() {
DebugLogger.shared.append("Starting Bonjour + Ethernet monitoring")
if !browserStarted {
let params = NWParameters.tcp
params.includePeerToPeer = false
params.requiredInterfaceType = .wiredEthernet
browser = NWBrowser(for: .bonjourWithTXTRecord(type: "_mytcpapp._tcp", domain: nil), using: params)
browser?.stateUpdateHandler = { state in
if case .ready = state {
DebugLogger.shared.append("Bonjour browser ready.")
}
}
browser?.browseResultsChangedHandler = { results, _ in
self.handleBrowseResults(results)
}
browser?.start(queue: .main)
browserStarted = true
}
// Start monitoring for wired ethernet
monitor = NWPathMonitor()
monitor?.pathUpdateHandler = { path in
let hasEthernet = path.availableInterfaces.contains { $0.type == .wiredEthernet }
let ethernetInUse = path.usesInterfaceType(.wiredEthernet)
DebugLogger.shared.append("""
NWPathMonitor:
- Status: \(path.status)
- Interfaces: \(path.availableInterfaces.map { "\($0.name)[\($0.type)]" }.joined(separator: ", "))
- Wired Ethernet: \(hasEthernet), In Use: \(ethernetInUse)
""")
self.tryToConnectIfReady()
self.stopMonitoring()
}
monitor?.start(queue: monitorQueue)
}
// MARK: - Internal Logic
private func handleBrowseResults(_ results: Set<NWBrowser.Result>) {
guard !self.isResolving, !self.hasResolvedService else { return }
for result in results {
guard case let .bonjour(txtRecord) = result.metadata,
let portString = txtRecord["actual_port"],
let actualPort = Int(portString),
case let .service(name, type, domain, _) = result.endpoint else {
continue
}
DebugLogger.shared.append("Bonjour result — port: \(actualPort)")
self.resolvedPort = actualPort
self.isResolving = true
self.resolveWithNetService(name: name, type: type, domain: domain)
break
}
}
private func resolveWithNetService(name: String, type: String, domain: String) {
let netService = NetService(domain: domain, type: type, name: name)
netService.delegate = self
netService.includesPeerToPeer = false
netService.resolve(withTimeout: 5.0)
resolvingNetService = netService
DebugLogger.shared.append("Resolving NetService: \(name).\(type)\(domain)")
}
private func tryToConnectIfReady() {
guard hasResolvedService,
let host = resolvedHost, let port = resolvedPort else { return }
DebugLogger.shared.append("Attempting to connect: \(host):\(port)")
discoveredIP = host
discoveredPort = port
connectionPublisher.send(.connecting(ip: host, port: port))
stopBrowsing()
socketManager.connectToServer(ip: host, port: port)
hasResolvedService = false
}
}
// MARK: - NetServiceDelegate
extension BonjourManager: NetServiceDelegate {
func netServiceDidResolveAddress(_ sender: NetService) {
guard let hostname = sender.hostName else {
DebugLogger.shared.append("Resolved service with no hostname")
return
}
DebugLogger.shared.append("Resolved NetService hostname: \(hostname)")
resolvedHost = hostname
isResolving = false
hasResolvedService = true
tryToConnectIfReady()
}
func netService(_ sender: NetService, didNotResolve errorDict: [String : NSNumber]) {
DebugLogger.shared.append("NetService failed to resolve: \(errorDict)")
}
}
I am trying to setup a system-wide DNS-over-TLS for iOS that can be turned off and on from within the app, and I'm struggling with the implementation details. I've searched online, searched forums here, used ChatGPT, and I'm getting conflicting information or code that is simply wrong. I can't find example code that is valid and gets me moving forward.
I think I need to use NEDNSProxyProvider via the NetworkExtension. Does that sound correct? I have NetworkExtension -> DNS Proxy Capability set in both the main app and the DNSProxy extension.
Also, I want to make sure this is even possible without an MDM. I see conflicting information, some saying this is opened up, but things like https://developer.apple.com/documentation/Technotes/tn3134-network-extension-provider-deployment saying a device needs to be managed. How do private DNS apps do this without MDM?
From some responses in the forums it sounds like we need to parse the DNS requests that come in to the handleNewFlow function. Is there good sample code for this parsing?
I saw some helpful information from Eskimo (for instance https://developer.apple.com/forums/thread/723831 ) and Matt Eaton ( https://developer.apple.com/forums/thread/665480 )but I'm still confused.
So, if I have a DoT URL, is there good sample code somewhere for what startProxy, stopProxy, and handleNewFlow might look like? And valid code to call it from the main app?
iPhone 12 pro with iOS 26.0 (23A5276f)
App: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps
We aim to use Wi-Fi Aware to establish file transfer between Android and Apple devices.
Apple will act as the Publisher, and Android will act as the Subscriber.
According to the pairing process outlined in the Wi-Fi Aware protocol (Figure 49 in the Wi-Fi Aware 4.0 specification), the three PASN Authentication frames have been successfully exchanged. Subsequently, Android sends the encrypted Follow-up PMF to Apple, but the Apple log shows: Failed to parse event. Please refer to the attached complete log.
We request Apple to provide a solution.
apple Log-20250808a.txt
I have an issue that causes multiple instances of the push provider to be initialized. And I'd like to ask you what could trigger the instantiation NEAppPushProvider subclass. It seems like it's being triggered excessively. If there's documentation that I have overlooked then just show it to me and I'll be on my way.
Here's the details. But really all I want to know is why is my subclass for NEAppPushProvider keeps getting initialized. If you can answer me that than maybe all these details don't really matter but here they are.
Here's why I believe there's multiple push provider. I see logs for my push provider initializing but I don't see it de-initializing. I also see redundant logs showing multiple instances trying to log into my server. Each time it initializes, an additional log is added for trying to log into my server.
In the app, the system saves it's configuration shortly after initialization, after saving and loading the push configuration, the app doesn't touch config.
Meanwhile in the extension, after 8 or so hours, the extension starts creating a new instance of the push provider. Then a few hours later it does it again. And again. Until the watch dog kills us for wasting too much CPU.
Normally on a fresh install, I'll observe turning off the wifi to call stop on the push provider and later have the push provider de-initialize.
The extension maintains a socket connection to the server, the server can send it messages to display push notifications. The software runs on hospital networks, which will not have access to the internet. It seems like the connection to the server is stable from the logs. I don't detect any disconnections. I'll check with the server to confirm.
In the app I call removeFromPreferences to clear out any extensions before logging in/saving push configurations. And I call saveToPreferences on the NEAppPushManager. I do this to make sure I don't have more than one push configuration saved at one time. I also have many logs looking out for this. I used the sample code from apple as the basis of the my own Push Manager. I can post code if you deem it necessary.
Hope to here from you soon. Thank you.
Our app is developed for iOS, but some users also run it on macOS (as an iOS app via Apple Silicon). The app requires local network permission, which works perfectly on iOS. Previously, the connection also worked fine on macOS, but since the recent macOS update, the app can no longer connect to our device.
Additionally, our app on macOS doesn't prompt for local network permission at all, whereas it does on iOS. Is this a known issue with iOS apps running on macOS? Has anyone else experienced this problem, or is there a workaround?
Any help would be appreciated!
Topic:
App & System Services
SubTopic:
Networking
After pairing and having subscribed to a service, and even after having exchanged messages, the service fails after a period of time and both devices need to pair again.
Topic:
App & System Services
SubTopic:
Networking
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
Hi,
We have an issue (https://github.com/actions/runner-images/issues/10924) raised by a user requesting to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners. Apple introduced a new LNP policy with macOS Sequoia that is not controlled by TCC or MDM. Could you please guide us on how to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners?
Thanks.
I have written the Transparent App Proxy and can capture the network flow and send it to my local server. I want to avoid any processing on the traffic outgoing from my server and establish a connection with a remote server, but instead of connecting to the remote server, it again gets captured and sent back to my local server.
I am not getting any clue on how to ignore these flows originating from my server.
Any pointers, API, or mechanisms that will help me?
Topic:
App & System Services
SubTopic:
Networking
Tags:
Network Extension
System Extensions
Endpoint Security
I have been using the SCNetworkReachabilityGetFlags for 10+ years to inform users that their request won't work. In my experience this works pretty well although i am aware of the limitations.
Now, i am looking into the NWPathMonitor, and i have one situation that i'm trying to. get my head around - it's asynchronous.
Specifically, i am wondering what to do when my geofences trigger and i want to check network connectivity - i want to tell the user why the operation i'll perform because of the trigger couldn't be done.
SO. say i start a NWPathMonitor in didFinishLaunchingWithOptions. When the app is booted up because of a geofence trigger, might i not end up in a case where my didEnterRegion / didExitRegion gets called before the NWPathMonitor has gotten its first status?
The advantage here with SCNetworkReachabilityGetFlags, as i understand it, would be that it's synchronous?
If i want to upgrade to nwpathmonitor, i guess i have to do a method that creates a nwpathmonitor, uses a semaphore to wait for the first callback, then contunues?
Thoughts appreciated
I've recently updated one of our CI mac mini's to Sequoia in preparation for the transition to Tahoe later this year. Most things seemed to work just fine, however I see this dialog whenever the UI Tests try to run.
This application BoostBrowerUITest-Runner is auto-generated by Xcode to launch your application and then run your UI Tests. We do not have any control over it, which is why this is most surprising.
I've checked the codesigning identity with codesign -d -vvvv
as well as looked at it's Info.plist and indeed the usage descriptions for everything are present (again, this is autogenerated, so I'm not surprised, but just wanted to confirm the string from the dialog was coming from this app)
<?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>BuildMachineOSBuild</key>
<string>22A380021</string>
<key>CFBundleAllowMixedLocalizations</key>
<true/>
<key>CFBundleDevelopmentRegion</key>
<string>en</string>
<key>CFBundleExecutable</key>
<string>BoostBrowserUITests-Runner</string>
<key>CFBundleIdentifier</key>
<string>company.thebrowser.Browser2UITests.xctrunner</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>BoostBrowserUITests-Runner</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>1.0</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleSupportedPlatforms</key>
<array>
<string>MacOSX</string>
</array>
<key>CFBundleVersion</key>
<string>1</string>
<key>DTCompiler</key>
<string>com.apple.compilers.llvm.clang.1_0</string>
<key>DTPlatformBuild</key>
<string>24A324</string>
<key>DTPlatformName</key>
<string>macosx</string>
<key>DTPlatformVersion</key>
<string>15.0</string>
<key>DTSDKBuild</key>
<string>24A324</string>
<key>DTSDKName</key>
<string>macosx15.0.internal</string>
<key>DTXcode</key>
<string>1620</string>
<key>DTXcodeBuild</key>
<string>16C5031c</string>
<key>LSBackgroundOnly</key>
<true/>
<key>LSMinimumSystemVersion</key>
<string>13.0</string>
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
<key>NSAppleEventsUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSBluetoothAlwaysUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSCalendarsUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSCameraUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSContactsUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSDesktopFolderUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSDocumentsFolderUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSDownloadsFolderUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSFileProviderDomainUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSFileProviderPresenceUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSLocalNetworkUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSLocationUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSMicrophoneUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSMotionUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSNetworkVolumesUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSRemindersUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSRemovableVolumesUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSSpeechRecognitionUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSSystemAdministrationUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>NSSystemExtensionUsageDescription</key>
<string>Access is necessary for automated testing.</string>
<key>OSBundleUsageDescription</key>
<string>Access is necessary for automated testing.</string>
</dict>
</plist>
Additionally, spctl --assess --type execute BoostBrowserUITests-Runner.app return an exit code of 0 so I assume that means it can launch just fine, and applications are allowed to be run from "anywhere" in System Settings.
I've found the XCUIProtectedResource.localNetwork value, but it seems to only be accessible on iOS for some reason (FB17829325).
I'm trying to figure out why this is happening on this machine so I can either fix our code or fix the machine. I have an Apple script that will allow it, but it's fiddly and I'd prefer to fix this the correct way either with the machine or with fixing our testing code.
We are experiencing a large number of crashes in our production environment, mainly occurring on iOS 16 systems and iPhone 8 and iPhone X devices. The crash log and stack trace are as follows:
Error:
Assertion failed: (false) function _onqueue_rdar53306264_addWaiter file TubeManager.cpp line 1042
Crashed: com.apple.CFNetwork.LoaderQ
0 libsystem_kernel.dylib 0x7198 __pthread_kill + 8
1 libsystem_pthread.dylib 0xd5f8 pthread_kill + 208
2 libsystem_c.dylib 0x1c4b8 abort + 124
3 libsystem_c.dylib 0x70d8c err + 266
4 CFNetwork 0x1eb80 CFURLRequestSetMainDocumentURL + 6288
5 CFNetwork 0x44fd8 CFURLCacheRemoveAllCachedResponses + 22624
6 CFNetwork 0x39460 _CFHostIsDomainTopLevel + 968
7 CFNetwork 0x1f754 CFURLRequestSetMainDocumentURL + 9316
8 CFNetwork 0x233e0 CFURLRequestSetRequestPriority + 8792
9 CFNetwork 0x20d38 CFURLRequestCopyHTTPRequestBodyStream + 1612
10 CFNetwork 0x4f950 CFHTTPCookieStorageCopyCookies + 16276
11 CFNetwork 0x15878 CFURLRequestSetURL + 7600
12 libdispatch.dylib 0x637a8 _dispatch_call_block_and_release + 24
13 libdispatch.dylib 0x64780 _dispatch_client_callout + 16
14 libdispatch.dylib 0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600
15 libdispatch.dylib 0x401e4 _dispatch_lane_invoke$VARIANT$armv81 + 432
16 libdispatch.dylib 0x41304 _dispatch_workloop_invoke$VARIANT$armv81 + 1620
17 libdispatch.dylib 0x49f14 _dispatch_workloop_worker_thread + 608
18 libsystem_pthread.dylib 0x1bd0 _pthread_wqthread + 284
19 libsystem_pthread.dylib 0x1720 start_wqthread + 8
Have you encountered a similar issue before?
I was excited to find out about Wi-Fi Aware in i[Pad]OS 26 and was eager to experiment with it. But after wiping and updating two devices (an iPhone 11 Pro and a 2018 11" iPad Pro) to Beta 1 I found out that neither of them support Wi-Fi Aware 🙁.
What current and past iPhone and iPad models support Wi-Fi Aware?
And is there a new UIRequiredDeviceCapabilities key for it, to indicate that an app requires a Wi-Fi Aware capable device?
Continuing with my investigations of several issues that we have been noticing in our testing of the JDK with macosx 15.x, I have now narrowed down at least 2 separate problems for which I need help. For a quick background, starting with macosx 15.x several networking related tests within the JDK have started failing in very odd and hard to debug ways in our internal lab. Reading through the macos docs and with help from others in these forums, I have come to understand that a lot of these failures are to do with the new restrictions that have been placed for "Local Network" operations. I have read through https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy and I think I understand the necessary background about these restrictions.
There's more than one issue in this area that I will need help with, so I'll split them out into separate topics in this forum. That above doc states:
macOS 15.1 fixed a number of local network privacy bugs. If you encounter local network privacy problems on macOS 15.0, retest on macOS 15.1 or later.
We did have (and continue to have) 15.0 and 15.1 macos instances within our lab which are impacted by these changes. They too show several networking related failures. However, I have decided not to look into those systems and instead focus only on 15.3.1.
People might see unexpected behavior in System Settings > Privacy & Security if they have multiple versions of the same app installed (FB15568200).
This feedback assistant issue and several others linked in these documentations are inaccessible (even when I login with my existing account). I think it would be good to have some facility in the feedback assistant tool/site to make such issues visible (even if read-only) to be able to watch for updates to those issues.
So now coming to the issue. Several of the networking tests in the JDK do mulicasting testing (through BSD sockets API) in order to test the Java SE multicasting socket API implementations. One repeated failure we have been seeing in our labs is an exception with the message "No route to host". It shows up as:
Process id: 58700
...
java.net.NoRouteToHostException: No route to host
at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method)
at java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:914)
at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:871)
at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:798)
at java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:857)
at java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:178)
at java.base/java.net.DatagramSocket.send(DatagramSocket.java:593)
(this is just one example stacktrace from java program)
That "send0" is implemented by the JDK by invoking the sendto() system call. In this case, the sendto() is returning a EHOSTUNREACH error which is what is then propagated to the application.
The forum text editor doesn't allow me to post long text, so I'm going to post the rest of this investigation and logs as a reply.
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?
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
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?