连续互通

Universal Control drops MacBook Air every few minutes: sharingd marks peer "NearbyInfo lost" while its BLE advertisements are still being received continuously.

Type of issue

Incorrect / Unexpected Behavior — reproducible, occurs multiple times per hour

Devices

Role Model OS

Host Mac mini, Mac16,10 macOS 27.0 (26A428)

Peer MacBook Air, Mac16,13 macOS 27.0 (26A428)

Same Apple ID, same Wi-Fi network (5 GHz, ch 149, non-DFS), Bluetooth and Handoff enabled on both. Devices are about 1 m apart.

Description

Universal Control between the Mac mini and the MacBook Air disconnects every few minutes. The MacBook Air shows a disconnect banner, and the cursor/keyboard stops crossing over for a few seconds until the link is re-established.

Logs from both machines show that the disconnect is initiated by the Mac mini and always follows the same timer-driven chain:

1. The Mac mini's sharingd reports BLE NearbyInfo lost for the MacBook Air. This happens on a periodic sweep, always at hh:mm:27.8 or hh:mm:57.8. At that moment UniversalControl logs IDS 091CC54E: Device Lost.
2. Exactly 45 s later, UniversalControl logs SYNC: Device Unavailable, removes the peer from the circle (Devices no longer in circle), and releases its last connection assertion. At the same time wifip2pd clears the AWDL ensemble traffic registration (Realtime mode updated false).
3. Exactly 60 s later, the Mac mini logs P2P ...: Deactivating due to idle timeout → P2PDirectLink Canceled: NSOSStatusErrorDomain (-6723). The MacBook Air receives TCP stream error -6723 on awdl0 and shows the disconnect banner.

Key evidence: the peer's advertisements are NOT actually lost

While sharingd declared the MacBook Air lost, I ran a minimal CoreBluetooth scanner on the Mac mini (CBCentralManagerScanOptionAllowDuplicatesKey = true, filtering Apple manufacturer data type 0x10 / Nearby Info, RSSI > −70). The source is attached as blescan.swift.

• Between 22:17:20 and 22:19:10 the scanner received the MacBook Air's Nearby Info advertisements every 2.7–3.9 s with no gaps, at RSSI about −50 dBm.
• In that same window, sharingd logged BLE NearbyInfo lost ... RSSI -49 ... Paired yes at 22:17:57.785. UniversalControl then logged Device Lost at 22:17:57.793.

So the radio is receiving the peer the whole time, but sharingd stops getting updates for it and expires it. In another window (22:22:09 → 22:23:38), sharingd logged no changed/found events for the peer for about 90 s before declaring it lost.

sharingd's scan runs with Dupfilter:Enabled, 30/300 ms passive. I suspect that duplicate-filtered advertisements are not re-delivered to sharingd, possibly because the duplicate-filter cache flush is not working. This is a hypothesis; I have not verified it.

Ruled out

• Distance / signal: RSSI at "lost" is −42 to −55 dBm; devices are about 1 m apart.
• 2.4 GHz interference (USB3 SSD, Thunderbolt dock, 2.4 GHz receivers): moving or removing them made no difference, and the raw scanner shows no packet loss.
• Wi-Fi/BT coexistence: airportd coex stats show tx_deny_cnt=0 rx_deny_cnt=0, and bluetoothd shows Denied by [Coex 0 BT 0 Others 0]. Wi-Fi throughput on the mini is only about 10–20 KB/s.
• BLE congestion: only about 3 BLE devices are nearby.
• Peer side: MacBook Air logs show continuous advertising, stable Wi-Fi (−43 dBm, no roaming), and its own idle timeout skipped because of connection assertions.
• Wired + Wi-Fi conflict: the Ethernet service is disabled; the mini uses Wi-Fi only.
• Restarting bluetoothd (pkill bluetoothd): no effect. The next disconnect occurred about 2 minutes later.

Steps to reproduce

1. Mac mini on macOS 27.0 (26A428) and MacBook Air, same Apple ID, both on Wi-Fi, Universal Control enabled, placed about 1 m apart.
2. Use Universal Control normally: move the cursor to the Air, work there, then return to the mini.
3. Within 5–15 minutes, the Air shows a Universal Control disconnect banner.
4. On the mini, run: /usr/bin/log show --last 1h --predicate 'process == "UniversalControl"' | grep -E 'Device Lost|Device Unavailable|Deactivating due to idle'. The events follow the Lost → +45 s → +60 s pattern.

Expected

Universal Control stays connected while the peer is nearby, awake, and advertising.

Actual

The mini expires the peer every few minutes even though its advertisements are still being received, and then tears down the Universal Control link.