I've implemented a custom system extension VPN for macOS using Packet Tunnel Provider. The VPN is configured with on-demand, and a rule to always connect whenever there's traffic:
onDemandRules = [NEOnDemandRuleConnect()]
As expected, if the VPN isn't active, all traffic gets blocked until it is ready.
Not expected: In the following scenario, there is some 'traffic leak':
Use only WiFi (not wired cable)
Connect the VPN
Disable the WiFi and wait for the VPN to disconnect
Enable the WiFi
Some packets are routed outside the VPN, and aren't being blocked
Some moments after, all traffic will be blocked, and the VPN will start the 'connecting' process.
Is the above scenario a 'known' issue? Can it be a race condition in the OS, where some packets can be sent after the network is brought back before the VPN process starts? Is there any way to fix this problem?
P.S:
I'm not using flags such as 'capture all network'
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
In our App, we have a network extension with a NEAppPushProvider subclass running. We run the following steps
Setup a dual-band wireless router per the following:
Broadcasting 2.4 GHz and 5 GHz channels
Same SSID names for both channels
Connected to the production network to the router
DHCP assigning addresses in the 10.1.x.x network
Connect the mobile device to the 5 GHz network (if needed, turn off the 2.4 GHz network temporarily; once the device connects to the 5 GHz network, the 2.4 GHz network can be turned back on).
Create a NEAppPushManager in the App, using the SSID from the above mentioned network and set it to the matchSSIDs property. Call saveToPreferences() on the push manager to save.
A. We have UI that shows the extension has been started and it has connected to the server successfully.
Walk out of the range of the 5 GHz channel of the router, but stay within range of the 2.4ghz channel.
Wait for the mobile device to connect to the 2.4 GHz channel.
Expected:
The extension would reconnect to the 2.4ghz network.
Observed:
The extension does not reconnect. Checking the logs for the extension we see that the following was called in the push provider subclass.
stop(with:completionHandler:) > PID: 808 | 🗒️🛑 Stopped with reason 3: "noNetworkAvailable"
The expectation is that start() on the NEAppPushProvider subclass would be called. Is this an incorrect expectation?
How does the NEAppPushProvider handle same network SSID roaming among various band frequencies? I looked at the documentation and did not find any settings targeting 2.4 or 5 ghz networks. Please advise on what to do.
When i try to set the value ‘false’ for ‘usesClassicLoadingMode’ it is getting crashed.
The crash logs has been shared below
Ex:
let config = URLSessionConfiguration.default
if #available(iOS 18.4, *) {
config.usesClassicLoadingMode = false
}
Error log :
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFBoolean objectForKeyedSubscript:]: unrecognized selector sent to instance 0x1f655c390'
*** First throw call stack:
(0x188ae52ec 0x185f69a7c 0x188b4f67c 0x1889fcb84 0x1889fc4f0 0x191393bc8 0x1889ec8a0 0x1889ec6e4 0x191393ad0 0x191344dac 0x191344b58 0x107cfa064 0x107ce36d0 0x191343fcc 0x1891b3b18 0x1892dae58 0x189235c60 0x18921e270 0x18921d77c 0x18921a8ac 0x107ce0584 0x107cfa064 0x107ce891c 0x107ce95d8 0x107ceabcc 0x107cf5894 0x107cf4eb0 0x212f51660 0x212f4e9f8)
terminating due to uncaught exception of type NSException
Can you please provider the resolution steps
System Information in macOS from 26.0 to 26.2 RC no longer provides Wi-Fi SSIDs; instead, it displays "< redacted> " for every SSID on my two MacBooks.
This issue has been fixed in macOS 26.1 beta and macOS 26.2 beta, but it returns in the RC and the Final Release versions. Is it an expected behaviour or a bug in the Release Candidate?
MacBook Air 2025:
MacBook Pro 2021:
Hi all,
We've been exploring the capabilities of the Network.framework for peer-to-peer communication and have run into some behavior that we haven't been able to fully explain with the existing documentation.
In our tests, we’re working with 12 iOS devices, all disconnected from Wi-Fi to force communication over Apple Wireless Direct Link (AWDL). While using the Network.framework to create peer-to-peer connections, we observed that the number of connected peers never exceeded 8, despite all 12 devices being active and configured identically.
Some questions we’re hoping to get clarification or discussion on:
Is there a known upper limit to the number of peer-to-peer connections supported via AWDL?
Are there conditions under which the framework or system limits or throttles visible peers?
Does AWDL behavior vary by hardware model, iOS version, or backgrounding state of the app?
Is there any official documentation or guidance around peer discovery or connection limits when using NWBrowser and NWConnection in a peer-to-peer context?
We’d appreciate any insights from the Apple engineering team or other developers who have worked with larger peer groups using Network.framework in peer-to-peer mode.
Description:
We are investigating an issue where running a specific e-commerce iOS app inside the Xcode Simulator intermittently disrupts the Mac’s network connectivity.
When the app is launched in the Simulator, our NETransparentProxyProvider and NEFilterDataProvider extensions occasionally stop receiving traffic correctly, and shortly afterward the entire macOS DNS resolution fails. Once this happens, all apps on the Mac lose internet access until mac is restarted. Disabling extensions also fixing the issue.
This issue only appears when the app runs in the Xcode Simulator.
I would like to confirm:
Is it possible for traffic patterns or network behavior inside the Simulator to interfere with system-level Network Extension providers on macOS?
Are there known limitations or conflicts between the Simulator’s virtual networking interfaces and Network Extensions?
Any recommended debugging steps or best practices to isolate this behavior?
Any guidance, known issues, or suggestions would be appreciated.
I'm trying to implement support for grpc http/2 streams using NSURLSession. Almost everything works fine, data streaming is flowing from the server and from the client and responses are coming through my NSURLSessionTaskDelegate. I'm getting the responses and streamed data through the appropriate handlers (didReceiveData, didReceiveResponse).
However, I cannot seem to find an API to access the trailers expected by grpc. Specifically, the expected trailer "grpc-status: 0" is in the response, but after the data. Is there no way to gain access to trailers in the NSURLSession Framework?
In our system, when a user enables a mobile hotspot and the system connects to it, the system attempts to verify WIFI availability by sending an HTTP GET request to http://captive.apple.com.
Normally, the server returns:
HTTP Status: 200 (OK)
Content-Type: text/html
This has always been used as a sign of normal connectivity.
Issue:
Since last Friday, the server sometimes responds with:
Content-Type: application/octet-stream
When this occurs, our system determines that the network is unavailable and displays a connection warning (a “!” icon).
Question:
Has Apple recently made any backend or CDN configuration changes to captive.apple.com that could affect the response type?
Any advice how can we solve this problem?
Thanks!
Topic:
App & System Services
SubTopic:
Networking
I have been playing around with the new URL Filtering API. I have successfully installed and configured the sample code, Installed the example app to my iPhone, and am also running the PIR server locally on my Mac.
In my input.txtpb file, I simply have 2 endpoints:
rows: [{
keyword: "instagram.com",
value: "1"
},
{
keyword: "youtube.com/shorts",
value: "1"
}]
Neither of these are blocked when I attempt to load them from either a browser, or their dedicated apps.
Are there any debugging tips I should know about?
Additionally, I have also noticed a few times I have left the filter running on my phone, after leaving my LAN (where the PIR server is running), suddenly throughout the day I'm having random, completely unrelated endpoints blocked on my phone. I thought this API was never supposed to produce false positives (without calling back to the PIR server for confirmation).
We’re implementing VPN application using the WireGuard protocol and aiming to support both split-tunnel and per-app VPN configurations. Each mode works correctly on its own: per-app VPN functions well when configured with a full tunnel and split-tunnel works as expected when per-app is disabled.
However, combining both configurations leads to issues. Specifically, the routing table is not set up properly, resulting in traffic that should not be routed through the tunnel is routed through the tunnel.
Detailed description:
Through our backend, we are pushing these two plist files to the iPad one after the other:
VPN config with allowed IPs 1.1.1.1/32
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Inc//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
<dict>
<key>PayloadUUID</key>
<string>3fd861df-c917-4716-97e5-f5e96452436a</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadOrganization</key>
<string>someorganization</string>
<key>PayloadIdentifier</key>
<string>config.11ff5059-369f-4a71-afea-d5fdbfa99c91</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadDisplayName</key>
<string> test</string>
<key>PayloadDescription</key>
<string>(Version 13) </string>
<key>PayloadRemovalDisallowed</key>
<true />
<key>PayloadContent</key>
<array>
<dict>
<key>VPN</key>
<dict>
<key>AuthenticationMethod</key>
<string>Password</string>
<key>ProviderType</key>
<string>packet-tunnel</string>
<key>OnDemandUserOverrideDisabled</key>
<integer>1</integer>
<key>RemoteAddress</key>
<string>172.17.28.1:51820</string>
<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
<dict>
<key>Action</key>
<string>Connect</string>
</dict>
</array>
<key>ProviderBundleIdentifier</key>
<string>some.bundle.id.network-extension</string>
</dict>
<key>VPNSubType</key>
<string>some.bundle.id</string>
<key>VPNType</key>
<string>VPN</string>
<key>VPNUUID</key>
<string>d2773557-b535-414f-968a-5447d9c02d52</string>
<key>OnDemandMatchAppEnabled</key>
<true />
<key>VendorConfig</key>
<dict>
<key>VPNConfig</key>
<string>
Some custom configuration here
</string>
</dict>
<key>UserDefinedName</key>
<string>TestVPNServerrra</string>
<key>PayloadType</key>
<string>com.apple.vpn.managed.applayer</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadIdentifier</key>
<string>vpn.5e6b56be-a4bb-41a5-949e-4e8195a83f0f</string>
<key>PayloadUUID</key>
<string>9bebe6e2-dbef-4849-a1fb-3cca37221116</string>
<key>PayloadDisplayName</key>
<string>Vpn</string>
<key>PayloadDescription</key>
<string>Configures VPN settings</string>
<key>PayloadOrganization</key>
<string>someorganization</string>
</dict>
</array>
</dict>
</plist>
Command to set up per-app with Chrome browser
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Inc//DTD PLIST 1.0//EN" http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
<dict>
<key>Command</key>
<dict>
<key>Settings</key>
<array>
<dict>
<key>Identifier</key>
<string>com.google.chrome.ios</string>
<key>Attributes</key>
<dict>
<key>VPNUUID</key>
<string>d2773557-b535-414f-968a-5447d9c02d52</string>
<key>TapToPayScreenLock</key>
<false />
<key>Removable</key>
<true />
</dict>
<key>Item</key>
<string>ApplicationAttributes</string>
</dict>
</array>
<key>RequestType</key>
<string>Settings</string>
</dict>
<key>CommandUUID</key>
<string>17ce3e19-35ef-4dbc-83d9-4ca2735ac430</string>
</dict>
</plist>
From the log we see that our VPN application set up allowed IP 1.1.1.1 via NEIPv4Settings.includedRoutes but system routing all of the Chrome browser traffic through our application.
Is this expected Apple iOS behavior, or are we misconfiguring the profiles?
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
We found there is a significant crash reports (most of them are from iOS 17, the rest are iOS 16 and 15) comes from network loader from CFNetwork. Apparently it seems there are two types of crashes if we checked from the stack trace, the one we found from both Xcode organizer and 3rd party crash reporter is referring to URLConnectionLoader::loadWithWhatToDo and the other one from our 3rd party crash reporter (didn’t found the report from Xcode organizer) referring to
_CFURLResponseCreateFromArchiveList (this one only happened on iOS 17.5 and later devices). It seems that they are both kinda similar which might point to the same root cause.
From what I’ve seen, we never touch the lower level API directly, we usually use the URLSession to manage our API request. The crashed stack trace also didn’t give any indication about which of our app code that triggered the crash, it only shows calls to Apple’s internal SDKs so we are unsure how to approach this issue meanwhile the crash event already reached 800+ in the last 30 days. Unfortunately, we cannot reproduce the issue as the stack trace itself seems unclear to us.
I have submitted a report through feedback assistant with number: FB14679252.
Would appreciate if anyone can give any advice on what we can do to avoid this in the future and probably any hint on why it could happened.
Hereby I attached the crash reports that we found each from Xcode crash report and our 3rd party crash reporter (the report said it crashed on com.apple.CFNetwork.LoaderQ) so you could get a glimpse of the similarity.
Xcode crash report
xcode crash report.crash
3rd party crash report
3rd party crash report.txt
I'm struggling to understand why the async-await version of URLSession download task APIs do not call the delegate functions, whereas the old non-async version that returns a reference to the download task works just fine.
Here is my sample code:
class DownloadDelegate: NSObject, URLSessionDownloadDelegate {
func urlSession(_ session: URLSession,
downloadTask: URLSessionDownloadTask,
didWriteData bytesWritten: Int64,
totalBytesWritten: Int64,
totalBytesExpectedToWrite: Int64) {
// This only prints the percentage of the download progress.
let calculatedProgress = Float(totalBytesWritten) / Float(totalBytesExpectedToWrite)
let formatter = NumberFormatter()
formatter.numberStyle = .percent
print(formatter.string(from: NSNumber(value: calculatedProgress))!)
}
}
// Here's the VC.
final class DownloadsViewController: UIViewController {
private let url = URL(string: "https://pixabay.com/get/g0b9fa2936ff6a5078ea607398665e8151fc0c10df7db5c093e543314b883755ecd43eda2b7b5178a7e613a35541be6486885fb4a55d0777ba949aedccc807d8c_1280.jpg")!
private let delegate = DownloadDelegate()
private lazy var session = URLSession(configuration: .default, delegate: delegate, delegateQueue: nil)
// for the async-await version
private var task: Task<Void, Never>?
// for the old version
private var downloadTask: URLSessionDownloadTask?
override func viewWillAppear(_ animated: Bool) {
super.viewWillAppear(animated)
task?.cancel()
task = nil
task = Task {
let (_, _) = try! await session.download(for: URLRequest(url: url))
self.task = nil
}
// If I uncomment this, the progress listener delegate function above is called.
// downloadTask?.cancel()
// downloadTask = nil
// downloadTask = session.downloadTask(with: URLRequest(url: url))
// downloadTask?.resume()
}
}
What am I missing here?
1) Blocked page UX
When a URL is blocked, the browser typically shows a generic error like “"Safari cannot open the page because it couldn’t load any data,” with no indication that the page was blocked by a policy.
Is there any plan to add an API that allows developers to present a custom “blocked” page or remediation action, similar to NEFilterControlProvider’s remediationMap?
Even a minimal hook (custom HTML, deep link, or support URL) would make the experience clearer for users.
2) Cross‑app link‑opening behavior
With a block rule in place, direct navigation in Safari is blocked as expected. However, tapping the same URL in a messaging app (e.g., WhatsApp) opens Safari - and the page loads, not blocked.
Repro steps:
Configure a URL Filter extension that blocks https://example.com.
Case A: Open a browser and type the URL in the address bar → blocked (expected).
Case B: Tap the same URL in WhatsApp (or another messenger) → a browser opens and the page loads (unexpected).
iOS version - 26.0
Hello Apple Support Team,
We are seeing a production crash on iOS 26 devices that appears to originate from Apple system frameworks rather than application code.
1. Crash Details
OS Version: iOS 26.x
App built with: Xcode 16
Devices: Multiple models (not device-specific)
Exception Type: SIGSEGV SEGV_ACCERR
Fault Address: 0x0000000000000100
Crashed Thread: 4 (network background queue)
Crash trace summary:
Last Exception :
0 libobjc.A.dylib _objc_release_x8 + 8
1 libboringssl.dylib _nw_protocol_boringssl_deallocate_options + 92
2 Network 0x000000019695207c 0x00000001968dc000 + 483452
3 libswiftCore.dylib __swift_release_dealloc + 56
4 libswiftCore.dylib bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 152
5 Network 0x0000000196951f6c 0x00000001968dc000 + 483180
6 Network 0x0000000196952000 0x00000001968dc000 + 483328
7 libswiftCore.dylib __swift_release_dealloc + 56
8 libswiftCore.dylib bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 152
9 libswiftCore.dylib void multiPayloadEnumFN<&handleRefCountsDestroy>(swift::TargetMetadata<swift::InProcess> const*, swift::LayoutStringReader1&, unsigned long&, unsigned char*) + 248
10 libswiftCore.dylib swift::swift_cvw_arrayDestroy(swift::OpaqueValue*, unsigned long, unsigned long, swift::TargetMetadata<swift::InProcess> const*) + 1172
11 libswiftCore.dylib _$sSp12deinitialize5countSvSi_tF + 40
12 CollectionsInternal ___swift_instantiateGenericMetadata + 1236
13 CollectionsInternal ___swift_instantiateGenericMetadata + 388
14 CollectionsInternal ___swift_instantiateGenericMetadata + 1044
15 libswiftCore.dylib __swift_release_dealloc + 56
16 libswiftCore.dylib bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 152
17 Network 0x000000019695f9fc 0x00000001968dc000 + 539132
18 Network 0x000000019695f9bc 0x00000001968dc000 + 539068
19 libswiftCore.dylib __swift_release_dealloc + 56
20 libswiftCore.dylib bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 152
21 libswiftCore.dylib swift_cvw_destroyImpl(swift::OpaqueValue*, swift::TargetMetadata<swift::InProcess> const*) + 212
22 Network 0x0000000196def5d8 0x00000001968dc000 + 5322200
23 Network 0x0000000196ded130 0x00000001968dc000 + 5312816
24 libswiftCore.dylib __swift_release_dealloc + 56
25 libswiftCore.dylib bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 152
26 Network 0x000000019695fde0 0x00000001968dc000 + 540128
27 libobjc.A.dylib object_cxxDestructFromClass(objc_object*, objc_class*) + 116
28 libobjc.A.dylib objc_destructInstance_nonnull_realized(objc_object*) + 76
29 libobjc.A.dylib __objc_rootDealloc + 72
30 Network 0x000000019695f99c 0x00000001968dc000 + 539036
31 Network 0x000000019695fae4 0x00000001968dc000 + 539364
32 Network 0x0000000196b078b8 0x00000001968dc000 + 2275512
33 libobjc.A.dylib object_cxxDestructFromClass(objc_object*, objc_class*) + 116
34 libobjc.A.dylib objc_destructInstance_nonnull_realized(objc_object*) + 76
35 libobjc.A.dylib __objc_rootDealloc + 72
36 Network 0x0000000196b07658 0x00000001968dc000 + 2274904
37 Network 0x00000001968e51d4 nw_queue_context_async_if_needed + 92
38 Network 0x0000000197686ea0 0x00000001968dc000 + 14331552
39 libswiftCore.dylib swift::swift_cvw_arrayDestroy(swift::OpaqueValue*, unsigned long, unsigned long, swift::TargetMetadata<swift::InProcess> const*) + 436
40 libswiftCore.dylib _$sSp12deinitialize5countSvSi_tF + 40
41 CollectionsInternal ___swift_instantiateGenericMetadata + 1236
42 CollectionsInternal ___swift_instantiateGenericMetadata + 388
43 CollectionsInternal ___swift_instantiateGenericMetadata + 1044
44 libswiftCore.dylib __swift_release_dealloc + 56
45 libswiftCore.dylib bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 152
46 Network 0x000000019694a010 0x00000001968dc000 + 450576
47 libobjc.A.dylib object_cxxDestructFromClass(objc_object*, objc_class*) + 116
48 libobjc.A.dylib objc_destructInstance_nonnull_realized(objc_object*) + 76
49 libobjc.A.dylib __objc_rootDealloc + 72
50 Network 0x0000000196a330e0 0x00000001968dc000 + 1405152
51 Network 0x00000001974378e0 0x00000001968dc000 + 11909344
52 Network 0x0000000196a17178 0x00000001968dc000 + 1290616
53 libdispatch.dylib __dispatch_call_block_and_release + 32
54 libdispatch.dylib __dispatch_client_callout + 16
55 libdispatch.dylib _dispatch_workloop_invoke.cold.4 + 32
56 libdispatch.dylib __dispatch_workloop_invoke + 1980
57 libdispatch.dylib __dispatch_root_queue_drain_deferred_wlh + 292
58 libdispatch.dylib __dispatch_workloop_worker_thread + 692
59 libsystem_pthread.dylib __pthread_wqthread + 292
------
Exception Type: SIGSEGV SEGV_ACCERR
Exception Codes: fault addr: 0x0000000000000100
Crashed Thread: 4
2. Behavior & Context
The crash occurs during normal HTTPS networking using standard URLSession (no direct usage of Network.framework nor boringssl APIs).
It appears to be triggered during QUIC connection establishment or TLS fallback.
The stack trace contains no application code frames — all symbols are from system libraries.
The crash strongly indicates double-free, over-release, or dangling pointer inside nw_protocol_boringssl_options deallocation.
3. Questions for Apple
Is this a known issue in iOS 26 within Network.framework / boringssl related to nw_protocol_boringssl_deallocate_options?
What is the root cause of the over‑release / invalid objc_release in this path?
Is there a workaround we can implement from the app side (e.g., disabling QUIC, adjusting TLS settings, or queue configuration)?
Do you have a target iOS version or patch where this issue will be fixed?
We can provide full crash logs and additional metrics upon request.
4. Additional Information
Developed using Swift 5, with a deployment target of iOS 12+.
Thank you for your support.
Topic:
App & System Services
SubTopic:
Networking
Since updating to macOS 26.4 developerbeta 2 I've been getting full loss of dns resolution. I am not running a VPN or any network extensions that I am aware of.
I'm not sure how to report this in the feedback utility as I cannot find an appropriate category for it. Happy to file it if someone can give an appropriate suggestion - the closest I could see was Wi-Fi but that wanted Wi-Fi logs for the issue, which I do not believe to be needed as this is not a Wi-Fi connectivity issue.
Running
dig example.com +short
nslookup example.com
ping example.com
Gives the following output
104.18.27.120
104.18.26.120
Server: 10.0.1.1
Address: 10.0.1.1#53 \
Non-authoritative answer:
Name: example.com
Address: 104.18.26.120
Name: example.com
Address: 104.18.27.120 \
ping: cannot resolve example.com: Unknown host
This shows it's not an issue with my local network and that core networking is working, but something in the mDNSResponder/dns stack of macOS is failing. This causes all apps/browsers that do not implement their own DNS lookups to fail (Chrome still works).
Sometimes the issue clears after running the following commands (for a period), sometimes it does not. A restart always resolves the issue temporarily.
sudo killall -9 mDNSResponder
sudo killall -9 mDNSResponderHelper
sudo dscacheutil -flushcache
sudo ifconfig en0 down
sudo ifconfig en0 up
Topic:
App & System Services
SubTopic:
Networking
Hi,
On macOS 26.4 Beta (25E5218f) (macOS Tahoe 26 Developer Beta ), the network filter causes network failures or slowdowns. This manifests as Chrome failing to access websites, while Safari can access the same websites without issue. The affected websites can be pinged locally.
My situation is similar to this situation.The same question link is: https://github.com/objective-see/LuLu/issues/836
Have you been paying attention to this issue? Hopefully, it can be fixed in the official release.
Thank you.
TL;DR: How does one use DNSServiceReconfirmRecord() to invalidate mDNS state of a device that's gone offline?
I'm using the DNSServiceDiscovery API (dns_sd.h) for a local P2P service. The problem I'm trying to solve is how to deal with a peer that abruptly loses connectivity, i.e. by turning off WiFi or simply by moving out of range or otherwise losing connectivity. In this situation there is of course no notification that the peer device has gone offline; it simply stops sending any packets.
After my own timeout mechanism determines the peer is not responding, I mark it as offline in my own data structures. The problem is how to discover when/if it comes back online later. My DNSServiceBrowse callback won't be invoked because mDNS doesn't know the device went offline in the first place.
I am trying to use DNSServiceReconfirmRecord, which appears to be for exactly this use case -- "Instruct the daemon to verify the validity of a resource record that appears to be out of date (e.g. because TCP connection to a service's target failed.)" However my attempts always return a BadReference error (-65541). The function requires me to pass a DNS record, and the only one I know is the TXT record; perhaps it needs a different one? Which, and how would I get it?
Thanks!
I want to know the right way/API/usage to use NWConnectionGroup to send both datagram and non-datagram stream.
I am currently working on an P2P video streaming app. I want to leverage NWConnectionGroup over QUIC to handle both message channel (traditionally handled by a TCP connection) and media channel (traditionally handled by sth. over UDP) to transmit SRT packets back and forth.
I created a NWConnectionGroup and it worked fine on non-datagram parts. The problems are with datagram part. I tried
extracting a connection with datagram = true either from the group or from message, doesn't and in some cases it breaks other non-datagram connections.
I currently send datagram directly using the NWConnectionGroup.send(content:completion). It kinda works but I keep seeing it canceled a lot of messages, which breaks SRT shortly after start. The warnings belong flooded my console. (Seems like want me to create a connection to transmit datagram, how?)
nw_connection_create_with_connection [C1600] Original connection not yet connected
nw_connection_group_create_connection_for_endpoint_and_parameters [G1] failed to create connection with parameters quic, local: fe80::439:68b4:6ec2:694%en0.60517, definite, attribution: developer, server
I must use it in wrong way. What should I do to fix it?
Hello,
is there a way to get MCC/MNC carrier codes on iOS? I'm also wondering if there's a private API.
I want to obtain network information while I am abroad to determine the country of residence.