Proxy unable to connect to iOS7 lockdownd

[christianboyle]

This is what I see when I run the proxy. Everything is fully updated (Xcode 5, etc.).

This is what I see when I go to to http://localhost:9221 (which I assume is correct). That link takes me to a full-screen inspector view, but styles don't populate in the Styles pane on the right and nothing populates in the Timeline when reloading the page in the Simulator window. The rendered source does load in the Inspector and corresponding elements highlight correctly in the Simulator when hovering in Inspector, so I presume everything is getting hung up on the problem with the proxy.

Any ideas on what could be wrong?

[kevin1024]

I'm also seeing this on my Linux machine. Every time I run the ios_webkit_proxy command, my phone (running IOS7) pops up a message asking me if would like to trust this computer. Before I can answer, the following error message appears:

Could not connect to lockdownd. Exiting.: No such file or directory
Unable to attach (a really long hash) inspector

[kevin1024]

I'm guessing this is related to libimobiledevice/libimobiledevice#20

I can confirm that ios_webkit_proxy works on an iOS6 device with my setup fine.

[christianboyle]

I'm not sure. People claim this works with iOS 7 and we are both experiencing the same issue even though you are testing on a physical device and I'm testing on the simulator. I'll try to get someone else to test on the simulator tonight and report back.

[zwri]

Thanks, it'd be helpful to run iOS6 vs iOS7 tests on simulated vs physical devices.

Also, can you run other idevice* commands, e.g. "ideviceinstaller -l" and "idevicepair validate"?

[kevin1024]

I don't seem to have the "ideviceinstaller" command on my system.

I have libimobiledevice 1.1.5 installed on my Archlinux box.

On my iOS7 device

idevicepair validate

ERROR: Device (big hash) is not paired with this host

idevicepair pair

ERROR: Could not pair with the device because a passcode is set. Please enter the passcode on the device and retry.

(I don't use a passcode)

On my iOS6 device

idevice pair validate
SUCCESS: Paired with device (big hash)

Seems like an upstream bug, eh?

[kevin1024]

Actually, removing the passcode from my device (prompted by the error message above) seems to have caused ios-webkit-debug-proxy to start working! (depite the error message that I still receive from idevicepair validate)

[christianboyle]

Nice. There doesn't seem to be an iOS Simulator passcode option/functionality, but I also get that same "ERROR: Could not pair with the device because a passcode is set. Please enter the passcode on the device and retry."

[zwri]

A passcode is fine on physical devices, but even desktop Safari can't inspect an iOS6 device unless you unlock the device. Is the ios-webkit-debug-proxy unable to attach to an iOS7 device with an unlocked passcode?

Can desktop Safari's inspector attach to a simulated iOS7 Safari? Or does it have the same error/popup as ios-webkit-debug-proxy?

[christianboyle]

I have the same issue in desktop Safari with iOS Simulator. It can only view/highlight/edit markup, no styles populate and no timeline info. I've never actually seen this error/popup, possibly because I don't have a passcode set. I'll try using my physical device next (which does have a passcode) to see if there's any difference.

[FunkyM]

Please use the libimobiledevice/trustdialog branch to properly test iOS 7 support.

[scottohara]

I was getting the same could not connect to lockdownd error when connecting my device (iOS7).

I installed the libimobiledevice/trustdialog branch as suggested by @FunkyM, but now I get:

Invalid idevice_connection struct?: Undefined error: 0
Unable to get connection file descriptor.: Undefined error: 0
Unable to attach (device hash) inspector

The iOS7 simulator connects OK (both with the standard libimobiledevice and with the libimobiledevice/trustdialog branch).

[tmaximini]

i am also seeing the could not connect to lockdownd error on iOS7 device. no passcode set on device.

[scottohara]

(I'm not a C programmer, so I apologise in advance if I have this wrong)

Looking at the code in webinspector.c (in this repo) and idevice.h (from the libimobiledevice/trustdialog branch); I think the cause of my Invalid idevice_connection struct error above is as follows:

webinspector.c defines an idevice_connection_private struct with three properties:

struct idevice_connection_private {
  enum connection_type type;
  void *data;
  void *ssl_data;
};

idevice.h defines a the same struct, but with an additional udid pointer

struct idevice_connection_private {
    char *udid;
    enum connection_type type;
    void *data;
    ssl_data_t ssl_data;
};

The idevice_connection_get_fd function in webinspector.c recieves an idevice_connection_t (which I believe is equivalent to the latter struct definition above, including udid), casts it to a idevice_connection_private pointer (which is the former struct definition above); then compares the sizeof the two.
As they don't match, it throws an Invalid idevice_connection struct error.

wi_status idevice_connection_get_fd(idevice_connection_t connection,
    int *to_fd) {
  if (!connection || !to_fd) {
    return WI_ERROR;
  }
  // extract the connection fd
  idevice_connection_private *connection_private = 
    (idevice_connection_private *) connection;
  if (!connection ||
      sizeof(*connection) != sizeof(idevice_connection_private) ||
      connection_private->type != CONNECTION_USBMUXD ||
      connection_private->data <= 0 ||
      connection_private->ssl_data) {
    perror("Invalid idevice_connection struct?");
    return WI_ERROR;
  }

Is that a correct interpretation of the issue?

If so, then presumably when @FunkyM merges the trustdialog branch; a corresponding change will need to be made to the struct definition in webinspector.c?

[FunkyM]

@scottohara You are right about the struct. However, the correct change should be to make the project actually use libimobiledevice's webinspector implementation instead of reimplementing it's own. Furthermore it make sense to merge the "higher level" API bits implemented here into the libimobiledevice protocol implementation, too.

[zwri]

The proxy's webinspector was released before libimobiledevice's webinspector, so it's not a "reimpl".

Scott's correct: the above struct must be updated to match libimobiledevice, ideally with an "#ifdef" to support both branches. A better fix would be to modify libimobiledevice to provide access to their "idevice_connection_private" struct's fd.

Merging this code into libimobiledevice would be difficult. The proxy uses non-blocking I/O (e.g. "wi_on_recv(self, buf, len)"), libimobiledevice uses blocking I/O (e.g. "webinspector_receive_with_timeout(client, to_plist, millis)"). Non-blocking I/O requires access to the fd. I strongly prefer non-blocking I/O and see no reason to switch to blocking I/O.

Eventually I'd like to refactor the proxy's webinspector.c into low-level ("wi_recv_packet", "wi_send_msg") v.s. higher-level ("wi_recv_msg", "wi_send_forwardSocketData") files, but, as noted above, merging any of this into libimobiledevice would be awkward.

[scottohara]

Thanks @FunkyM / @wrightt.

Just as a test (notwithstanding both of your comments about the correct way to handle this); I temporarily added char *udid to ios-webkit-debug-proxy's struct declaration; and I can confirm that it now works fine with the libimobiledevice/trustdialog branch.

I was able to successfully debug a webapp running on my connected iOS7 device.

Cheers,
Scott

[zwri]

Great! Once I setup an iOS7 device (ASAP, ideally), I'll commit your fix (w/ #ifdef) and update the README. Thanks, Todd

[FunkyM]

@wrightt You are right by the terms, it's rather another implementation than a reimplementation and you had it working earlier. I really like what you implemented here. I agree with you that it's not an easy task to merge your webinspector implementation in libimobiledevice but it's also not rocket science, clearly doable and the right place for the protocol layer. I'll have to work on it anyways so it would just have been nice if we could join forces and let both projects benefit. If you have an issue about blocking/non-blocking I/O then we can most likely find a solution for that, too. As you also noticed there are two levels of the webinspector "protocol". One low level and one encapsulated higher level protocol, both of which are targeted to become implemented in libimobiledevice at some point for easier "consumption" in other projects.

The trustdialog branch is being merged into master pretty soon.

[tdd]

Hey guys,

FWIW I just installed the proxy on a fully up-to-date OSX ML, using a freshly-updated brew. I use a physical iPhone 4 running iOS 6.1.3 (don't want to update to iOS 7). It was unlocked every time I tried to connect.

Proxy installing worked fine but on the first connect attempts I got the usual "lockdown/unable to attach" messages. I did an idevicepair validate which worked, and didn't get the message again.

BUT when I look at localhost:9221 I keep seeing the iPhone as not usable (not a link, a mere listing), and attempting localhost:9222 (the listed URL) doesn't get anywhere (Chrome network failure).

What gives here?

[programmin1]

This is still happening in Ubuntu 13.10. Can anyone confirm working 7.0.3 or 7.0.4?

[har96]

I'm getting the exact same issue as @tdd with an iPhone 4S running iOS 7.0.4 and Macbook Pro running OSX 10.9. Nothing gets printed to the console. Is this related or does it need a new issue?

[ruudud]

@programmin1: Just built everything (ie. libplist,libusbmuxd, libimobiledevice and ios-webkit-debug-proxy) from HEAD on Ubuntu 13.04 and tested and iPad running 7.0.4.

Same problem.

EDIT: The Safari debugger in OSX works as expected.

[zwri]

Which version of libimobiledevice are you using? To check:
On OSX: brew info libimobiledevice
On Linux: dpkg --list 'libimobiledevice*'
I think only the latest libimobiledevice release (1.1.7?) supports iOS 7.

Also, if you the libimobiledevice tools installed, does ideviceinfo work?

[har96]

libimobiledevice version 1.1.5. Checkmarks on all dependencies. ideviceinfo works fine. So does idevice_id -l and idevice_pair validate.

[jatemack]

@tdd: Had the same issue. I ran ideviceinfo from terminal and communication with my device started again, re-opening iPhoto. I closed iPhoto and iTunes, reran ios_webkit_debug_proxy and then went to http://localhost:9221/ in chrome and the device is now showing.

[markduerden]

@tdd I too had the same issue. ideviceinfo works fine. So does idevice_id -l and idevicepair validate.

I am trying to connect to iPad 2.1 running 7.0.2 from a MacBook running OSX (10.8.5). I see the device listed in localhost:9221 but it isn't clickable and if I try to connect to the device on port 9222 I get a cannot connect to server error.

Any clues?

UPDATE: My solution was here - #49

[lisongx]

@markduerden
can you click the tab then? Now I can see all the tabs opened in my mobile safari, but fail to open

[zwri]

Fixed for Mac: I've updated the proxy to use libimobiledevice 1.1.6 and improved the logging. My Mac can now inspect real & simulated MobileSafari.

Linux seems to have trust dialog issues, so I'm leaving this issue open until they're resolved.

[strangemethod]

@wrightt
How were you able to udpate to libimobiledevice 1.1.6? The latest release seems to be 1.1.5_2:
https://github.com/libimobiledevice/libimobiledevice/releases

[FunkyM]

libimobiledevice 1.1.6 is now available: http://libimobiledevice.org
If you still have these issues after updating make sure to remove any previous traces of the library from your system. One important note for Linux is to also update usbmuxd to git HEAD (a release should be out here soon, too) and related udev rule.

[jasonsilver]

Frustrating, I've just not been able to figure out what's wrong. I compiled and installed everything in Ubuntu from libimobiledevice.org, but have the following issues:
[code]

• idevicepair pair
• SUCCESS: Paired with device 7ec15b69bf887499a6a92ab905bb95088c694a50
• ios_webkit_debug_proxy -f http://chrome-devtools-frontend.appspot.com/static/18.0.1025.74/devtools.html
• Listing devices on :9221
• Could not connect to lockdownd. Exiting.: Operation now in progress
  Unable to attach 7ec15b69bf887499a6a92ab905bb95088c694a50 inspector

[/code]

Now the pairing seems to be lost, and I have to click the 'Trust' dialogue to repair.

What have I done wrong?

[christianboyle]

I just tried this again and things are working as expected now. Starting from scratch on OSX:

1. brew install ios-webkit-debug-proxy
2. start iOS simulator
3. ios_webkit_debug_proxy
4. open http://localhost:9221
5. select device
6. use the websocket URL instead of host: chrome-devtools://devtools/bundled/inspector.html?ws=//localhost:9222/devtools/page/1

[qLb]

Linux ios7 trust issue is still a major problem...

[sargin48]

i fixed this error on mac with

brew reinstall --HEAD libimobiledevice