Environment
- usbmuxd version: 1.1.1
- libimobiledevice: 1.4.0
- libusb: 1.0.29
- Distribution: CachyOS (Arch-based), kernel 7.0.1
- Device: iPhone 17 Pro, iOS 26.3.1 (23D8133)
- Connection: USB-C cable, USB 3 port
Summary
On first-time pairing, the Trust dialog on iOS takes > 10 seconds to appear
on screen. During that window, lockdownd returns error -8
(LOCKDOWN_E_PAIRING_DIALOG_RESPONSE_PENDING). The preflight_worker logs the
error and gives up — it never retries even after the user accepts the dialog.
The device is then dropped from usbmuxd's internal list, so subsequent
idevicepair/ideviceinfo calls return "No device found", and ipheth has
no carrier because lockdown handshake never completed.
Steps to reproduce
- Fresh install (no pairing record in /var/lib/lockdown/)
- Plug in unlocked iPhone via USB
- Observe Trust prompt arrives ~20–30s after plug
- Accept Trust on the iPhone
Expected
usbmuxd retries the lockdown handshake after the user accepts Trust, writes
the pairing record, and ipheth gets carrier.
Actual
usbmuxd logs error -8 once and gives up. The device is then removed from its
internal list, even though the user accepts the Trust dialog seconds later.
No pairing record is ever written, and no further attempt is made.
Logs
libusb: warning [op_get_configuration] device unconfigured
libusb: error [op_get_active_config_descriptor] device unconfigured
[3] Could not get old configuration descriptor for device 1-7: LIBUSB_ERROR_NOT_FOUND
[3] Connecting to new device on location 0x10007 as ID 2
[3] Connected to v2.0 device 2 on location 0x10007 with serial number 00008150-...
[1] preflight_worker_handle_device_add: ERROR: Could not connect to lockdownd
on device 00008150-..., lockdown error -8
(Full anonymized journal attached as usbmuxd.log.)
Workaround (confirmed working)
The following manual procedure successfully creates the pairing record on
first connection. After this, every subsequent plug-in works automatically
because usbmuxd reads the cached pairing from /var/lib/lockdown/.
The key insight is timing: idevicepair pair must be sent to usbmuxd
within the short window where (a) the Trust dialog has just been accepted
on iOS, and (b) usbmuxd hasn't yet failed and dropped the device.
- Unplug the iPhone.
- Restart usbmuxd to clear its stale state:
sudo systemctl restart usbmuxd
- Plug the iPhone back in (device unlocked, on home screen).
- In a terminal, type but do not yet run the command:
- Wait for the "Trust This Computer?" prompt to appear on the iPhone.
- Tap Trust on the iPhone and enter the device passcode.
- Immediately press Enter in the terminal to fire the prepared command.
- Expected output:
SUCCESS: Paired with device 00008150-...
- Verify:
idevicepair validate # SUCCESS: Validated pairing
ip -br link # ipheth interface should be UP, not NO-CARRIER
nmcli device # ethernet device should be "connected"
Without this carefully timed manual step, the device stays in a half-paired
state indefinitely (Trust accepted on iOS, but no record on disk), and
tethering never works because ipheth doesn't get carrier from lockdown.
Suggested fix
In src/preflight.c, when lockdownd_client_new_with_handshake() returns
LOCKDOWN_E_PAIRING_DIALOG_RESPONSE_PENDING, retry on a backoff (e.g. every
2s for up to 60s) instead of bailing immediately. iOS only emits the
response-pending error while the dialog is still active; once the user
accepts or denies, subsequent calls succeed or fail definitively. This
would eliminate the need for the manual workaround above and match the
out-of-the-box experience users get on Ubuntu/Debian (where the same
usbmuxd version is shipped, so the difference may come from a downstream
patch worth investigating).
usbmuxd.log
Environment
Summary
On first-time pairing, the Trust dialog on iOS takes > 10 seconds to appear
on screen. During that window, lockdownd returns error -8
(LOCKDOWN_E_PAIRING_DIALOG_RESPONSE_PENDING). The preflight_worker logs the
error and gives up — it never retries even after the user accepts the dialog.
The device is then dropped from usbmuxd's internal list, so subsequent
idevicepair/ideviceinfocalls return "No device found", and ipheth hasno carrier because lockdown handshake never completed.
Steps to reproduce
Expected
usbmuxd retries the lockdown handshake after the user accepts Trust, writes
the pairing record, and ipheth gets carrier.
Actual
usbmuxd logs error -8 once and gives up. The device is then removed from its
internal list, even though the user accepts the Trust dialog seconds later.
No pairing record is ever written, and no further attempt is made.
Logs
(Full anonymized journal attached as
usbmuxd.log.)Workaround (confirmed working)
The following manual procedure successfully creates the pairing record on
first connection. After this, every subsequent plug-in works automatically
because usbmuxd reads the cached pairing from /var/lib/lockdown/.
The key insight is timing:
idevicepair pairmust be sent to usbmuxdwithin the short window where (a) the Trust dialog has just been accepted
on iOS, and (b) usbmuxd hasn't yet failed and dropped the device.
SUCCESS: Paired with device 00008150-...Without this carefully timed manual step, the device stays in a half-paired
state indefinitely (Trust accepted on iOS, but no record on disk), and
tethering never works because ipheth doesn't get carrier from lockdown.
Suggested fix
In
src/preflight.c, whenlockdownd_client_new_with_handshake()returnsLOCKDOWN_E_PAIRING_DIALOG_RESPONSE_PENDING, retry on a backoff (e.g. every
2s for up to 60s) instead of bailing immediately. iOS only emits the
response-pending error while the dialog is still active; once the user
accepts or denies, subsequent calls succeed or fail definitively. This
would eliminate the need for the manual workaround above and match the
out-of-the-box experience users get on Ubuntu/Debian (where the same
usbmuxd version is shipped, so the difference may come from a downstream
patch worth investigating).
usbmuxd.log