Hi Experts, When experimenting with NEFilterDataProvider, I observed that whole ICMP data flows are visible on the local machine when pinging a remote machine from it. However, no ICMP data flows are observed on the local machine when the remote machine pings it. Below is the rule for filtering any protocol with any direction. NEFilterRule(networkRule: .init( remoteNetwork: nil, remotePrefix: 0, localNetwork: nil, localPrefix: 0, protocol: .any, direction: .any), action: .filterData) There is no issue for TCP/UDP. May I know it's a bug or by design?

Hi guys, I observed the infinite connection callback(inSelector) for some Bluetooth devices (such as an iPhone SE or Mac Mini) even when I powered off them. However, the issue is not reproducible easily. (IOBluetoothUserNotification *)registerForConnectNotifications:(id)observer selector:(SEL)inSelector ble.txt Looks like there are many -[CBManager xpcConnectionDidReceiveMsg:args:] calls when the issue occurs based on the sample, so it might be caused by the XPC connection with bluetoothd? Has anyone else experienced this issue, or any workaround for it? such as should I restart the bluetoothd?

I observed the following crash: Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2025-10-07 13:48:29.082 OS Version: macOS 15.6 (24G84) Report Version: 12 Anonymous UUID: 8B651788-4B2E-7869-516B-1DA0D60F3744 Crashed Thread: 3 Dispatch queue: NEFlow queue Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000054 ... Thread 3 Crashed: Dispatch queue: NEFlow queue 0 libdispatch.dylib 0x000000019af6da34 dispatch_async + 192 1 libnetworkextension.dylib 0x00000001b0cf8580 __flow_startup_block_invoke.216 + 124 2 com.apple.NetworkExtension 0x00000001adf97da8 __88-[NEExtensionAppProxyProviderContext setInitialFlowDivertControlSocket:extraValidation:]_block_invoke.90 + 860 3 libnetworkextension.dylib 0x00000001b0cf8140 __flow_startup_block_invoke.214 + 172 4 libdispatch.dylib 0x000000019af67b2c _dispatch_call_block_and_release + 32 5 libdispatch.dylib 0x000000019af8185c _dispatch_client_callout + 16 6 libdispatch.dylib 0x000000019af70350 _dispatch_lane_serial_drain + 740 7 libdispatch.dylib 0x000000019af70e2c _dispatch_lane_invoke + 388 8 libdispatch.dylib 0x000000019af7b264 _dispatch_root_queue_drain_deferred_wlh + 292 9 libdispatch.dylib 0x000000019af7aae8 _dispatch_workloop_worker_thread + 540 10 libsystem_pthread.dylib 0x000000019b11be64 _pthread_wqthread + 292 11 libsystem_pthread.dylib 0x000000019b11ab74 start_wqthread + 8 ... It appears that the crash is caused by the flow director queue becoming NULL when dispatch_async is called (accessing address 0x0000000000000054). Meanwhile, my transparent proxy was still running. I'm wondering if this is a known issue or if anyone else has encountered the same problem. @eskimo