Re: tap device support (for iphone)?

[Bradley Baetz <bbaetz gmail com>]

On Sat, Dec 5, 2009 at 11:44 AM, Dan Williams <dcbw redhat com> wrote:
> On Mon, 2009-11-30 at 16:11 +1100, Bradley Baetz wrote:
>> Hi,
>>
>> I'm working on a userspace driver for the iphone's tethering
>> functionality via USB, which I've reverse engineered (my carrier
>> allows tethering - this isn't a jailbroken iPhone). After a bit of
>> setup, this ends up basically just bridging a tap device (userspace L2
>> ethernet) to the appropriate USB pipes.
>
> Any particular reason it's not done as a real ethernet driver in the
> kernel?

Someone else has already done one (which I didn't discover until after
I'd done mine, though) - see
http://giagio.com/wiki/moin.cgi/iPhoneEthernetDriver

The problem is that tethering doesn't work until the iphone has been
paired to the computer - basically generating SSL keypairs and then
passing them over to the device. The existing in-kernel driver has a
python script that needs to be run manually first, although this is
done through udev.

> Most drivers should be in the kernel, because then we get
> access to a lot more information about the device.  If it's a userspace
> driver then we can't follow the device tree, find out what device the
> interface is associated with, we can't respond to events when the device
> is plugged/unplugged, and we can't figure out anything about the device
> since it's not hooked into the normal sysfs mechanisms (AFAIK).

You do get all the udev triggers on the tap device, though.

>> I have this working, and can run dhclient on the tap interface
>> manually, however I'm having trouble getting NetworkManager to
>> recognise the device. Even if I call the interface 'eth1' rather than
>> 'iphone0' NM (NetworkManager-0.7.996-6.git20091021.fc12.x86_64 from
>> F12) logs:
>>
>> NetworkManager: <WARN>  device_creator():
>> /sys/devices/virtual/net/eth1: couldn't determine device driver;
>> ignoring...
>>
>> which is sort of correct, since there isn't a kernel driver for it.
>
> Exactly; see above.  There's quite a lot of benefit to having a kernel
> driver for the device.
>
>> What I'd like to do is have the iphone interface made available to NM,
>> but at a lower priority than ethernet or wifi interfaces, ideally with
>> the 'mobile broadband' icon appearing in the applet, and without DHCP
>
> Yeah, though since it's just a tap device that's no different than a VPN
> tap device really, we can't tell that it's a mobile broadband device.
> We could potentially do that if it were a kernel driver and the devtype
> was set to 'wwan' like Marcel Holtman has sent patches for.

Hmm. Will have to look into that.

>> running unless the interface is the top choice (I don't want to send
>> data over the mobile interface unless we have to, due to cost). There
>> may later be a way to get a signal strength out of the interface, but
>> for the moment the only status messages I can decode are the
>> linkup/linkdown toggles (which my code currently ignores)
>
> Ugh, you want to handle those.  If it were an in-kernel driver, you'd
> call netif_carrier_on/netif_carrier_off and we'd also get normal netlink
> events out of the kernel when the link went up/down as we do for normal
> ethernet devices.

I can do it via the tap ioctls, and you'd get the netlink messages too
- I just haven't written the code (the in-kernel driver doesn't handle
it properly, though, yet)

> In the end, I think there are some pretty good benefits to an in-kernel
> driver, and you'd get those benefits mainly for free.  Some of them can
> be faked with a tun/tap device, but that seems hackish.  Not to diminish
> the work that you've done of course...

Debugging was easier in userspace :) But yeah, I may merge what I have
into the kernel driver.

Bradley