Hi there, I'm trying to build a MacOS VPN application from scratch. My VPN application is slightly from normal ones,
It will include an authentication token and underlying process information (pid, application path etc.) in each connection made to the VPN gateway. Consider it a poor man's zerotrust implementation.
NetworkExtension and PacketTunnel is a must, thus to retrieve process information via audit tokens.
However, I'm unable to find any working examples that can be built on MacOS 15.X. I tried to open an TSI case but didn't receive anything useful.
Anyone?
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
Does someone know how to debug ios app on mac designed for iPad?
i can debug on real iOS device but cant attach Tunnel to work for mac.
Hello! My app wants to disable VPN connection. I used the loadFromPreferencesWithCompletionHandler method of NEVPNManager for detection, but regardless of whether the VPN was actually connected or not, it kept returning NEVPNStatusInvalid. How should I handle this issue?
NEVPNManager *vpnManager = [NEVPNManager sharedManager];
[vpnManager loadFromPreferencesWithCompletionHandler:^(NSError * _Nullable error) {
if (error) {
return;
}
NEVPNStatus status = vpnManager.connection.status;
switch (status) {
case NEVPNStatusInvalid:
// kept returning NEVPNStatusInvalid
break;
case NEVPNStatusDisconnected:
break;
case NEVPNStatusConnecting:
break;
case NEVPNStatusConnected:
break;
case NEVPNStatusReasserting:
break;
case NEVPNStatusDisconnecting:
break;
default:
break;
}
}];
We have a setup where the system uses proxy settings configured via a PAC file. We are investigating how NWConnection behaves inside a Network Extension (NETransparentProxyProvider) with a transparent proxy configuration based on this PAC file.
Scenario:
The browser makes a connection which the PAC file resolves as "DIRECT" (bypassing the proxy)
Our Network Extension intercepts this traffic for analysis
The extension creates a new connection using NWConnection to the original remote address.
The issue: despite the PAC file’s "DIRECT" decision, NWConnection still respects the system proxy settings and routes the connection through the proxy.
Our questions:
Is it correct that NWConnection always uses the system proxy if configured ?
Does setting preferNoProxies = true guarantee bypassing the system proxy?
Additionally:
Whitelisting IPs in the Network Extension to avoid interception is not a viable solution because IPs may correspond to multiple services, and the extension only sees IP addresses, not domains (e.g., we want to skip scanning meet.google.com traffic but still scan other Google services on the same IP range).
Are there any recommended approaches or best practices to ensure that connections initiated from a Network Extension can truly bypass the proxy (for example, for specific IP ranges or domains)?
We are developing a desktop app for macOS, built with Electron + Angular + Node.js.
The app has the ability to access devices on the local network.
We are having some trouble with the behavior of the "Local Network" feature added in macOS 15.
Procedure:
MacBook Pro 14inch (M1Pro) 2021, 16GB memory - macOS Sequoia15.4.1
Network Environment: The PC and the access point are connected by wire, and the target device and the access point are also connected by wire.
Not connected to an external network
Install the target app
Start the application and allow the "Local Network" dialog that appears
Open the "Local Network" item in "Privacy and Security" and make sure the target app is allowed.
Confirm that you can access the target device on the local network
Restart the PC
Open the "Local Network" item in "Privacy and Security" and make sure the target app is allowed.
Start the app and access the target device on the local network
Result:
Access to the target device may fail (this does not occur 100% of the time)
If you turn the target app in the "Local Network" section of "Privacy and Security" OFF and then ON, you will be able to connect
However, it seems that the problem may occur again if you restart your PC.
According to our research, the probability of this happening increases if the target app is the only app allowed on the "local network".
This happens not only with our app, but also when you follow the above steps in "Google Chrome".
Based on the above investigation results, I suspect that this is a problem with the OS. What do you think?
I am currently creating a MacOS app that uses NetworkExtension and SystemExtension without going through the Store.
Using entitlements, I manually codesign and create a pkg Installer, but when I run it I get an error message saying "No matching profile found."
Below is the log
/Applications/Runetale.app/Contents/MacOS/Runetale not valid: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=file:///Applications/Runetale.app/, unsatisfiedEntitlements=<CFArray 0x71c040fa0 [0x1f7bec120]>{type = immutable, count = 3, values = (
0 : <CFString 0x71c04f340 [0x1f7bec120]>{contents = "com.apple.developer.system-extension.install"}
1 : <CFString 0x71c1ccaf0 [0x1f7bec120]>{contents = "com.apple.developer.networking.networkextension"}
2 : <CFString 0x71c04fc00 [0x1f7bec120]>{contents = "com.apple.developer.team-identifier"}
)}, NSLocalizedDescription=No matching profile found}
I looked into it myself and found that if you want to install the app without going through the Store, you need to use packet-tunnel-provider-systemextension instead of packet-tunnel-provider. here
However, simply changing to packet-tunnel-provider-systemextension does not allow the build to pass.
I use a build method that changes the value of entitlements only during codesign in order to pass the build.
SYSEXT="$APP_BUNDLE/Contents/Library/SystemExtensions/com.runetale.desktop.PacketTunnel.systemextension"
if [ -d "$SYSEXT" ]; then
echo "Signing PacketTunnel system extension with entitlements..."
cp macos/PacketTunnel/PacketTunnelRelease.entitlements macos/PacketTunnel/PacketTunnelRelease-sign.entitlements
sed -i '' 's/packet-tunnel-provider/packet-tunnel-provider-systemextension/' macos/PacketTunnel/PacketTunnelRelease-sign.entitlements
codesign --force --options runtime --timestamp --entitlements "$ENTITLEMENTS_FILE" --sign "$DEV_ID_APP_CERT" "$SYSEXT"
fi
# 3. Sign the entire .app bundle (deep sign by signing the outer app after inner ones)
echo "Signing Runetale App with entitlements..."
cp macos/Runner/Release.entitlements macos/PacketTunnel/Release-sign.entitlements
sed -i '' 's/packet-tunnel-provider/packet-tunnel-provider-systemextension/' macos/PacketTunnel/Release-sign.entitlementsmacos/PacketTunnel/Release-sign.entitlements
codesign --force --options runtime --timestamp --entitlements "$APP_ENTITLEMENTS_FILE" --sign "$DEV_ID_APP_CERT" "$APP_BUNDLE"
Is this build method wrong?
The next solution I'm thinking of is as follows.
Is there a way to write packet-tunnel-provider-systemextension directly to entitlments and pass the build? (provisioning profile?)
Apply to forum and get permission to use packet-tunnel-provider-systemextension
Thank you.
Topic:
App & System Services
SubTopic:
Networking
Tags:
Entitlements
System Extensions
Network Extension
I was trying to call getsockopt(fd, SOL_LOCAL, LOCAL_PEERCRED, ...), and by mistake passed a wrong value for the second parameter where it should be SOL_LOCAL. But the call still succeeded. Then I did more experiments and passed more random values for the second parameter, all succeeded. It seems there is a lack of parameter check in the implementation of getsockopt() , where it should return errors if people pass invalid parameters instead of succeeding silently. Hope the Apple engineers can help to validate and fix it.
Dear Apple:
In our app, we will call the - (void) applyConfiguration:(NEHotspotConfiguration *) configuration completionHandler:(void (^)(NSError * error)) completionHandler; interface of NEHotspotConfigurationManager on Apple devices. However, we are encountering a problem where the connection to the 2.4G hotspot fails, and the error is nil when it fails. We checked the Wi-Fi air interface and found that the Apple phone does not send a probe request before connecting to the hotspot. However, we are unclear why the Apple device does not send the probe request frame. Could you please help us understand when the probe request frame is not sent during the hotspot connection and how to trigger it to send the probe request frame every time? Thank you.
In my Packet Tunnel Provider, I'm setting the NEDNSSettings to localhost as I have a local DNS server listening on port 53 (this is a dns forwarder which conditionally forwards to different upstreams based on rules).
On iOS it works just fine, I'm able to listen on localhost:53 in the Network Extension, then set NEDNSSettings servers to "127.0.0.1".
However on macOS due to the port being under 1024, I get a Permission denied OS code 13 error. I'm assuming this is due to the Network Extension not running as root. Can this be changed?
This could be rectified if you could customize the port in NEDNSSettings, as the listener could be on port 5353, but it doesn't look like it is possible?
Just wondering if there is some other way to accomplish what I'm trying to do in the macOS Network Extension?
hi everybody,
When I use the following code to connect to WiFi network, an error message of "error=null" or "error='Error Domain=NEHotspotConfigurationErrorDomain Code=11 "" UserInfo={NSLocalizedDescription=}' " will occur. It has been uploaded to Feedback.
Feedback ID:
FB16819345 (WiFi-无法加入网络)
NEHotspotConfiguration *hotspotConfig = [[NEHotspotConfiguration alloc] initWithSSID:ssid passphrase:psk isWEP:NO];
[[NEHotspotConfigurationManager sharedManager] applyConfiguration:hotspotConfig completionHandler:^(NSError * _Nullable error) {
}];
Hello,
We have a SwiftUI-based application that runs as a LaunchAgent and communicates with other internal components using Unix domain sockets (UDS).
On Sequoia (macOS virtualized environment), when installing the app, we encounter the Local Network Privacy Alert, asking:
"Allow [AppName] to find and connect to devices on the local network?"
We are not using any actual network communication — only interprocess communication via UDS.
Is there a way to prevent this system prompt, either through MDM configuration or by adjusting our socket-related implementation?
Here's a brief look at our Swift/NIO usage:
class ClientHandler: ChannelInboundHandler {
...
public func channelRead(context: ChannelHandlerContext, data: NIOAny) {
...
}
...
}
// init bootstrap.
var bootstrap: ClientBootstrap {
return ClientBootstrap(group: group)
// Also tried to remove the .so_reuseaddr, the prompt was still there.
.channelOption(ChannelOptions.socketOption(.so_reuseaddr), value: 1)
.channelInitializer { channel in
// Add ChannelInboundHandler reader.
channel.pipeline.addHandler(ClientHandler())
}
}
// connect to the UDS.
self.bootstrap.connect(unixDomainSocketPath: self.path).whenSuccess { (channel) in
..
self.channel = channel
}
...
...
// Send some data.
self.channel?.writeAndFlush(buffer).wait()
Any guidance would be greatly appreciated.
I am developing an App based on Network Extension that lets all network requests on device access the Internet through a private Relay.
I created an empty iOS App and only the entitlements file and ViewController.swift(Main.storyboard) file have been modified. The code was copied from the official video https://developer.apple.com/videos/play/wwdc2023/10002/
But, running the App on iPhone, the saveToPreferences API reported Error Domain=NERelayErrorDomain Code=3 "(null)" and the App doesn't look like it's changed at all (it doesn't jump to the Settings - VPN&Relay). Does anyone know why?Any reply would be greatly appreciated.
The contents of the entitlements file:
<?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>com.apple.developer.networking.networkextension</key>
<array>
<string>relay</string>
</array>
</dict>
</plist>
ViewController.swift:
import UIKit
import NetworkExtension
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
}
@IBAction func tap(_ sender: Any) {
let newRelay = NERelay()
let relayURL = URL(string: "https://relay.example.com:443/")
newRelay.http3RelayURL = relayURL
newRelay.http2RelayURL = relayURL
newRelay.additionalHTTPHeaderFields = ["Authorization" : "PrivateToken=123"]
let manager = NERelayManager.shared()
manager.relays = [newRelay]
manager.matchDomains = ["internal.example.com"]
manager.isEnabled = false
manager.saveToPreferences { err in
print(err)
}
}
}
I have an iOS app that connects to a server running on macOS by leveraging NWListener & NWBrowser. It also makes use of the peerToPeer functionality / AWDL offered via the Network framework. This works great in the iOS app. Now I would like to add support for Shortcuts / App Intents in general.
The NWConnection on its own is also working great in the App Intent, but only if I provide the host/port manually, which means I can't use the peer to peer functionality. If I try to run my NWBrowser in the AppIntent it immediately changes its state to failed with a NoAuth (-65555) error:
nw_browser_cancel [B1517] The browser has already been cancelled, ignoring nw_browser_cancel().
nw_browser_fail_on_dns_error_locked [B1518] DNSServiceBrowse failed: NoAuth(-65555)
NWClientManager: Browser failed: -65555: NoAuth
I haven't found documentation/information on whether NWBrowser should work in an AppIntent extension or not.
Firstly, I'm completely new to native Swift/iOS Development so apologies if this is a simple question that I'm seemingly misunderstanding.
I have an app which has the Multicast Networking entitlement and works fine on my own iPhone, however it only has one interface when I list them (en0)
The multicast networking, however, fails entirely on another test iPhone but this also appears to have one or more 'ipsecX' interfaces both with the IP 192.0.0.6 - I'm guessing but I wonder if this is related to a connection to Apple Watch as I've noticed two devices that have these additional interfaces, and both of them are connected to Apple Watch (with no VPNs configured) and that's the only thing that differentiates them from my own iPhone.
I can reproduce the symptoms on my own iPhone by connecting to a VPN which creates a utunX interface (but in my case disconnecting from the VPN removes this interface and it works as expected)
I expect a solution would be to bind my Multicast Group to the WiFi IP but I've tried a few things without success;
Setting params.requiredInterfaceType = .wifi
Looping through each interface to try and 'find' en0 and bind this way;
let queue = DispatchQueue(label: "En0MonitorQueue")
monitor.pathUpdateHandler = { [weak self] path in
// Find the en0 interface
if let en0 = path.availableInterfaces.first(where: { $0.name == "en0" }) {
monitor.cancel() // Stop monitoring once found
let params = NWParameters.udp
params.allowLocalEndpointReuse = true
params.requiredInterface = en0
guard let multicast = try? NWMulticastGroup(for: [
.hostPort(
host: NWEndpoint.Host(self?.settings.multicastIP ?? "224.224.0.77"),
port: NWEndpoint.Port(rawValue: UInt16(self?.settings.multicastPort ?? 23019))
)
]) else {
print("Failed to Start Multicast Group")
return
}
let group = NWConnectionGroup(with: multicast, using: params)
// previous multicast stuff is here
} else {
print("en0 interface not found, waiting...")
}
}
monitor.start(queue: queue)
Neither seems to work.
I feel I must be missing something simple, because it should not be the case that simply enabling a VPN (or having another interface created by something else) breaks Multicast on en0/WiFi.
That said, I also don't want to limit the user to en0 as they may wish to use Ethernet interfaces, but for now it would be good to make it work to confirm this is the problem.
Topic:
App & System Services
SubTopic:
Networking
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.
My personal project is a bit further along however after not being able to get this to work in my app I fell back to a much simpler/proven implementation out there. There is this project on GitHub with a guide that implements a barebones app extension with packet tunneling. I figure this can give us common ground.
After changing the bundle and group identifiers to all end with -Caleb and or match up I tried running the app. The app extension does not work whatsoever and seemingly for reasons that are similar to my personal project.
If I pull up the console and filter for the subsystem (com.github.kean.vpn-client-caleb.vpn-tunnel) I see the following.
First you see installd installing it
0x16ba5f000 -[MIUninstaller _uninstallBundleWithIdentity:linkedToChildren:waitForDeletion:uninstallReason:temporaryReference:deleteDataContainers:wasLastReference:error:]: Destroying container com.github.kean.vpn-client-caleb.vpn-tunnel with persona 54D15361-A614-4E0D-931A-0953CDB50CE8 at /private/var/mobile/Containers/Data/PluginKitPlugin/2D0AE485-BB56-4E3E-B59E-48424CD4FD65
And then installd says this (No idea what it means)
0x16b9d3000 -[MIInstallationJournalEntry _refreshUUIDForContainer:withError:]: Data container for com.github.kean.vpn-client-caleb.vpn-tunnel is now at /private/var/mobile/Containers/Data/PluginKitPlugin/2D0AE485-BB56-4E3E-B59E-48424CD4FD65
Concerningly runningboardd seems to immediately try and stop it?
Executing termination request for: <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {(
"com.github.kean.vpn-client-caleb",
"com.github.kean.vpn-client-caleb.vpn-tunnel"
)}>>
[app<com.github.kean.vpn-client-caleb(54D15361-A614-4E0D-931A-0953CDB50CE8)>:1054] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.github.kean.vpn-client-caleb/54D15361-A614-4E0D-931A-0953CDB50CE8] uuid:963149FA-F712-460B-9B5C-5CE1C309B2FC isPlaceholder:Y reportType:None maxTerminationResistance:Absolute attrs:[
<RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {(
"com.github.kean.vpn-client-caleb",
"com.github.kean.vpn-client-caleb.vpn-tunnel"
)}>> allow:(null)>
]>
Then runningboardd leaves a cryptic message
Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd>:244] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.github.kean.vpn-client-caleb/54D15361-A614-4E0D-931A-0953CDB50CE8] uuid:963149FA-F712-460B-9B5C-5CE1C309B2FC isPlaceholder:Y" ID:33-244-5222 target:system attributes:[
<RBSPreventLaunchLimitation| <RBSProcessPredicate <RBSProcessBundleIdentifiersPredicate| {(
"com.github.kean.vpn-client-caleb",
"com.github.kean.vpn-client-caleb.vpn-tunnel"
)}>> allow:(null)>
]>
And that seems to be all I have to go off of.... If I widen my search a bit I can see backboardd saying things like
Connection removed: IOHIDEventSystemConnection uuid:57E97E5D-8CDE-467B-81CA-36A93C7684AD pid:1054 process:vpn-client type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{
HighFrequency = 1;
bundleID = "com.github.kean.vpn-client-caleb";
pid = 1054;
} state:0x1 events:119 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE
Or
Removing client connection <BKHIDClientConnection: 0xbf9828cd0; IOHIDEventSystemConnectionRef: 0xbf96d9600; vpid: 1054(vAF7); taskPort: 0x5D777; bundleID: com.github.kean.vpn-client-caleb> for client: IOHIDEventSystemConnection uuid:57E97E5D-8CDE-467B-81CA-36A93C7684AD pid:1054 process:vpn-client type:Passive entitlements:0x0 caller:BackBoardServices: <redacted> + 280 attributes:{
HighFrequency = 1;
bundleID = "com.github.kean.vpn-client-caleb";
pid = 1054;
} state:0x1 events:119 mask:0x800 dropped:0 dropStatus:0 droppedMask:0x0 lastDroppedTime:NONE source:HID
There's really nothing in the sysdiagnose either. No crash no nothing.
I am stumped. Any idea what might be going wrong for me here? Has something about the way app extensions or sandbox rules work changed in later OSes?
Hi,
DNS resolution using libresolv (res_nquery) fails in 15.4 when connected to VPN. The same is working fine for 15.3 and lower and this happens for all the domains. The method returns -1 and res->res_h_errno is set to 2.
In wireshark we can see that the DNS request is sent and server also returns the response successfully.
The same works fine if we use TCP instead of UDP by setting the following option
res->options |= RES_USEVC;
When the machine connects to the network cable through the Thunderbolt interface using the docking station, if the Network Extension shown in the following code is running at this time, after unplugging and reinserting the docking station, the machine will not be able to obtain a valid IP address through DHCP until the system is restarted.
@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
{
return NO;
}
@end
This problem will not occur if the IP of the DNS server or all UDP ports 53 are excluded in the Network Extension.
@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];
// excluded rules
NENetworkRule *objExcludedNetworkRule = [[NENetworkRule alloc] initWithRemoteNetwork:[NWHostEndpoint endpointWithHostname:@"" port:@(53).stringValue]
remotePrefix:0
localNetwork:nil
localPrefix:0
protocol:NENetworkRuleProtocolUDP
direction:NETrafficDirectionOutbound];
NSMutableArray<NENetworkRule *> *arrExcludedNetworkRules = [NSMutableArray array];
[arrExcludedNetworkRules addObject:objExcludedNetworkRule];
objSettings.includedNetworkRules = arrIncludedNetworkRules;
objSettings.excludedNetworkRules = arrExcludedNetworkRules;
// apply
[self setTunnelNetworkSettings:objSettings completionHandler:
^(NSError * _Nullable error)
{
// TODO
}
];
if (completionHandler != nil)
completionHandler(nil);
}
- (BOOL)handleNewFlow:(NEAppProxyFlow *)flow
{
return NO;
}
@end
Is MyTransparentProxyProvider in what place do wrong? To handle the connection on port 53, it is necessary to add the implementation of NEDNSProxyProvider?
In -[MyTransparentProxyProvider handleNewFlow:] how to reverse DNS? getnameinfo() doesn't work, it returns EAI_NONAME.
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.
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.