Repository navigation
11.2d: device sessions inside the Wi-Fi tunnel - #100
Merged
Merged
Conversation
A whole device session can now run inside the iOS 17+ tunnel over Wi-Fi: lockdown through com.apple.mobile.lockdown.remote.trusted (no StartSession), every service through its shim. The session opens this way on the 'wifi-tunnel' route, and as the fallback when lockdown over Wi-Fi can't be reached and the device has a remote pairing. DeviceTunnel.openService opens any service RSD lists by its exact name. The Wi-Fi search now reads every authTag in a device's advert: iOS names one per paired computer, authTag, authTag#1, authTag#2… Only the first was read, so a device paired with more than one computer wasn't found. The device probe takes --wifi-tunnel, and opens each usbmuxd device once before searching so it knows its MAC.
On iOS 17 and later, lockdown straight over Wi-Fi still answers, but the device closes every service it starts there (installation_proxy, misagent, AFC; seen on an iPhone on iOS 26.6.1 from Windows). The fallback to the tunnel only ran when lockdown itself didn't answer, so a device on Wi-Fi without usbmuxd's own Wi-Fi link could never install. - A device found on Wi-Fi with a remote pairing now opens through the Wi-Fi tunnel first, and by lockdown only if the tunnel doesn't open. route: 'wifi' stays lockdown only. - Whenever a session opens by cable on iOS 17.4 or later and no remote pairing is saved, one is made (makeRemotePairing, on by default), so the device works on Wi-Fi once the cable is out. A device that would ask the user first is left alone; it never fails the session. - Wi-Fi debugging for a device on Wi-Fi is turned on by lockdown at its address: the tunnel's lockdown doesn't return wireless lockdown values, and iOS 26 resets it on the write. It is read first everywhere, so a device that has it on is never written to.
Lockdown over Wi-Fi closing every service it starts was seen on one iPhone on iOS 26.6.1 from Windows, while the same iPhone installs by lockdown over Wi-Fi from a Mac. The comment and docs said it was true of iOS 17 and later; they now say what was seen, and that the tunnel is also the faster way. The test of the tunnel going first now checks that it is tried before any lockdown connection to the device's address. The roadmap lists what 11.2d does now.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A whole device session can now run inside the iOS 17+ tunnel over Wi-Fi (11.2c), so installs and every other device task work there too.
How it works
com.apple.mobile.lockdown.remote.trusted, which the tunnel already trusts, so there's noStartSession.<service>.shim.remote), checked in.wifi-tunnelroute, and as the fallback when lockdown over Wi-Fi can't be reached (disconnected, not found, timed out) and the device has a remote pairing.DeviceTunnel.openService(name): any service RSD lists, by its exact name.Installs over Wi-Fi go through the tunnel
route: 'wifi'stays lockdown only. The reason: an iPhone on iOS 26.6.1, reached from Windows, answered lockdown over Wi-Fi but closed every service it started there, so installs failed. The same iPhone installs by lockdown over Wi-Fi from a Mac, and why it differs isn't known yet. The tunnel works in both cases and is faster (22.9 MiB/s against 16–18).wifiroute, opens by lockdown only; the remote pairing is made by cable and never fails the session.Fix: the Wi-Fi search on iOS 26.4+
A device signs its Wi-Fi advert once for each computer it's paired with:
authTag,authTag#1,authTag#2… OnlyauthTagwas read, so a device paired with more than one computer wasn't found when this computer's tag wasn't the first. The search now reads all of them. The test now uses the shape a real iPhone sends, with this computer's tag second.Probe
device-probe … --wifi-tunnel: any command through a session inside the Wi-Fi tunnel. The remote pairing is made or checked over USB first.Checks
pnpm verify(1366 tests), and the full suite twice under full CPU load.Devices reachable only through the tunnel (Apple TV, Vision Pro) come with 11.3a.