On Thu, 2010-04-01 at 13:40 -0700, Daniel Borca wrote: > Martin, > > ipheth needs ValidatePair, not Pair > http://libiphone.lighthouseapp.com/projects/27916/tickets/89-provide-access-to-validatepair#ticket-89-9 > http://github.com/dgiagio/ipheth/blob/master/ipheth-pair/ipheth-pair.c > > Regards, > Daniel Borca
ideviceinfo and other tools call lockdownd_new_with_handshake(). That also uses ValidatePair in order to verify pairing: http://cgit.sukimashita.com/libimobiledevice.git/tree/src/lockdown.c#n688 Afaik. what counts for ipheth to work is the lockdown key "TrustedHostAttached" to be switched to "True" by the device. This is confirmed and reported by running "ideviceinfo -k TrustedHostAttached". Some idevicepair tool could provide this information. I think to solve this discussion we need to look at how this issue is solved on Mac OS X and Windows by iTunes. --- Martin S. > > > --- On Thu, 4/1/10, Paul McEnery <[email protected]> wrote: > > > From: Paul McEnery <[email protected]> > > Subject: Re: [libimobiledevice-devel] ipheth > > To: "Martin S." <[email protected]> > > Cc: "Ben Hutchings" <[email protected]>, "Julien BLACHE" > > <[email protected]>, [email protected], > > "Debian kernel team" <[email protected]>, "Daniel Borca" > > <[email protected]>, "Diego Giagio" <[email protected]> > > Date: Thursday, April 1, 2010, 11:20 PM > > On 1 April 2010 18:23, Martin S. > > <[email protected]> > > wrote: > > > On Thu, 2010-04-01 at 14:30 +0100, Paul McEnery > > wrote: > > >> On 1 April 2010 14:07, Ben Hutchings <[email protected]> > > wrote: > > >> > Paul, > > >> > > > >> > I missed you talking about ipheth on IRC > > earlier. > > >> > > > >> > I've seen the submission of ipheth on the > > netdev mailing list, and made > > >> > some comments on it there. If it is > > accepted, we can include it in the > > >> > Debian kernel packages and there will then be > > no need for ipheth-dkms. > > >> > You'll still need ipheth-utils. As for the > > udev rules, what do they do? > > >> > > > >> > > >> Hi Ben. > > >> > > >> The udev rules detect when an iPhone has been > > plugged in and execute a > > >> utility (ipheth-pair) which ensures that the > > iPhone is paired with the > > >> system to which it has been attached. Ipheth-pair > > is a small program > > >> written in C which makes use of libimobiledevice. > > Essentially > > >> ipheth-utils provides provides only the udev rules > > file and > > >> ipheth-pair utility. Ipheth-dkms provides the > > kernel module source > > >> code... > > >> > > >> So I'm guessing that ipheth-utils could be a > > package which is > > >> maintained long-term once ipheth is included in > > the mainstream kernel, > > >> or... > > >> > > >> Would it be more sensible to have libimobiledevice > > provide a generic > > >> pairing utility and set of udev rules which > > execute it when an > > >> i<device> is attached? Possibly part of > > libimobiledevice-utils? This > > >> appears to be a cleaner solution than maintaining > > a separate package > > >> for the task. > > >> > > >> Does anyone else have an opinion on this? > > > > > > Afaik. running any tool from libimobiledevice tools > > has the same effect > > > (for instance ideviceinfo). Those will pair a > > previously unpaired device > > > on the fly, too. > > > > > > Only issue to take care of is that password protected > > devices that pair > > > for the first time with the host computer need their > > password disabled > > > in order for the initial pairing to succeed. > > > > > > Additionally, I recently pushed a flag into the > > usbmuxd udev rules named > > > "USBMUX_SUPPORTED" which dependent rules can use to > > detect devices > > > supporting the usbmux protocol without having to > > maintain any usb id > > > ranges which clearly belong into usbmuxd. > > > > > > If you like we can create a simple "idevicepair" tool > > to allow cli based > > > manual pairing, unpairing and managing pairing records > > on the host. > > > > > > Besides that, the only thing I would add for > > discussion is to question > > > the need for a kernel driver since I have seen someone > > on the libiphone > > > ML did implement all the tethering stuff in > > user-space. > > > > > > > Hi Martin. > > > > Thanks for your input on this. I know there was a brief > > discussion on > > the topic of a kernel vs user space tethering driver, and > > speed was > > one of the topics. I recall a few claims being made about > > how much > > faster kernel space is, but this was never substantiated, > > and there > > was never a conclusion to the discussion. IIRC the user > > space driver > > was something that didn't integrate with the other > > components such as > > NetworkManager in quite the same way that ipheth does. > > Ipheth is just > > another interface - which is why it fits in very nicely > > with NM. > > > > That said, ipheth is a tried and tested solution that > > appears to be > > working well for many users [1]. > > > > Ben, one of the reasons that I was slow to respond to the > > call to > > integrate ipheth into the mainline kernel is that I don't > > believe that > > it belongs there. It's far too dependent on other bits and > > pieces in > > order to function. It requires the user space usbmuxd > > daemon - and the > > phone must be paired before it will function. It may well > > be easy to > > add a utility for paring devices to the > > libimobiledevice-utils > > package, but I'm not sure the solution becomes any more > > elegant. Then, > > there is still the matter of what to do with the udev > > rules. I guess > > it could be left to usbmuxd to pair any device which is > > connected, but > > this has purposefully been left to each user space > > application to > > handle appropriately. I'm not sure that all of this can (or > > should for > > that matter) be elegantly put together. > > > > Given what ipheth is, and how it works, I feel that DKMS > > provides a > > flexible and practical way of making it available to users. > > Despite my > > view on it, I am sure there are differing opinions - and I > > would like > > to hear them. > > > > Regards, > > Paul. > > > > 1. http://popcon.ubuntu.com/unknown/by_vote > > > > > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1270154991.6437.248.ca...@mirell
