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 ran a test code with ThreadSanitizer, it throws a race condition in the block of xpcconnectionseteventhandler even I set a sync queue to the connection. xpc_connection_set_event_handler(conn, ^(xpc_object_t event) { xpc_type_t type = xpc_get_type(event); if (xpc_get_type(event) == XPC_TYPE_DICTIONARY) { 		// race condition here 		// WARNING: ThreadSanitizer: data race // ... } else { if (event == XPCERRORCONNECTIONINVALID) { // Error indicates the peer has closed the connection. // Tear down any associated data structures. } else { // Error indicates that service will terminate soon. // Flush all buffers, finish all work, etc. } xpcrelease(peer); } }); https://developer.apple.com/documentation/xpc/1448786-xpc_connection_set_target_queue?language=objc: "the XPC runtime guarantees that, when the target queue is a serial queue, the event handler block will execute synchronously with respect to other blocks submitted to that same queue. When the target queue is a concurrent queue, the event handler block may run concurrently with other blocks submitted to that queue, but it will never run concurrently with other invocations of itself for the same connection" looks like there should have no race condition according to the above description, but why I encounter the race condition issue reported by ThreadSanitizer? Does the block of xpcconnectionseteventhandler need sync to avoid race condition?

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?