Re: [libimobiledevice-devel] ipheth
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 <pmcenery@gmail.com> wrote:
>
> > From: Paul McEnery <pmcenery@gmail.com>
> > Subject: Re: [libimobiledevice-devel] ipheth
> > To: "Martin S." <info@sukimashita.com>
> > Cc: "Ben Hutchings" <ben@decadent.org.uk>, "Julien BLACHE" <jblache@debian.org>, libimobiledevice-devel@lists.libimobiledevice.org, "Debian kernel team" <debian-kernel@lists.debian.org>, "Daniel Borca" <dborca@yahoo.com>, "Diego Giagio" <diego@giagio.com>
> > Date: Thursday, April 1, 2010, 11:20 PM
> > On 1 April 2010 18:23, Martin S.
> > <info@sukimashita.com>
> > wrote:
> > > On Thu, 2010-04-01 at 14:30 +0100, Paul McEnery
> > wrote:
> > >> On 1 April 2010 14:07, Ben Hutchings <ben@decadent.org.uk>
> > 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
> >
>
>
>
>
Reply to: