We get poked every now and then for Android support for mac80211 or
cfg80211 drivers. Since the questions is quite common I figured It'd
be good to document what needs to get done for this. Android folks,
you listening?
http://wireless.kernel.org/en/developers/Documentation/Android
If you already have worked on this or are going to please feel free to
update the wiki so no one else re-invents the wheel.
Thanks,
Luis
On Tue, Feb 1, 2011 at 6:29 PM, Luis R. Rodriguez <[email protected]> wrote:
> We get poked every now and then for Android support for mac80211 or
> cfg80211 drivers. Since the questions is quite common I figured It'd
> be good to document what needs to get done for this. Android folks,
> you listening?
>
> http://wireless.kernel.org/en/developers/Documentation/Android
>
> If you already have worked on this or are going to please feel free to
> update the wiki so no one else re-invents the wheel.
I don't think it's good to advocate a custom driver. They should be able
to use stock wpa_supplicant w/ nl80211 and put the extensions in the
hardware layer.
--
Bob Copeland %% http://www.bobcopeland.com
On Tue, Feb 1, 2011 at 4:45 PM, Bob Copeland <[email protected]> wrote:
> On Tue, Feb 1, 2011 at 6:29 PM, Luis R. Rodriguez <[email protected]> wrote:
>> We get poked every now and then for Android support for mac80211 or
>> cfg80211 drivers. Since the questions is quite common I figured It'd
>> be good to document what needs to get done for this. Android folks,
>> you listening?
>>
>> http://wireless.kernel.org/en/developers/Documentation/Android
>>
>> If you already have worked on this or are going to please feel free to
>> update the wiki so no one else re-invents the wheel.
>
> I don't think it's good to advocate a custom driver. They should be able
> to use stock wpa_supplicant w/ nl80211 and put the extensions in the
> hardware layer.
Can you elaborate?
Luis
On Tue, Feb 1, 2011 at 7:50 PM, Luis R. Rodriguez <[email protected]> wrote:
>> I don't think it's good to advocate a custom driver. ?They should be able
>> to use stock wpa_supplicant w/ nl80211 and put the extensions in the
>> hardware layer.
>
> Can you elaborate?
>From the wiki:
"The proper approach would be to provide a custom driver_nl80211_android.c
wrapper for the modified wpa_supplicant in Android."
I just don't think it's strictly necessary to ship a modified wpa_s.
Why is Android special when bog standard Linux gets by ok with
driver_nl80211?
--
Bob Copeland %% http://www.bobcopeland.com
On Tue, 2011-02-01 at 21:41 -0500, Bob Copeland wrote:
> On Tue, Feb 1, 2011 at 7:50 PM, Luis R. Rodriguez <[email protected]> wrote:
>
> >> I don't think it's good to advocate a custom driver. They should be able
> >> to use stock wpa_supplicant w/ nl80211 and put the extensions in the
> >> hardware layer.
> >
> > Can you elaborate?
>
> From the wiki:
>
> "The proper approach would be to provide a custom driver_nl80211_android.c
> wrapper for the modified wpa_supplicant in Android."
>
> I just don't think it's strictly necessary to ship a modified wpa_s.
> Why is Android special when bog standard Linux gets by ok with
> driver_nl80211?
Agree, that is a dumb idea. What's that driver going to do? Use custom
nl80211 extensions?! That way lies insanity.
johannes
On Wed, 2011-02-02 at 13:30 +0200, Jouni Malinen wrote:
> > Agree, that is a dumb idea. What's that driver going to do? Use custom
> > nl80211 extensions?! That way lies insanity.
>
> The only reason for that is to be able to support the wpa_supplicant
> modifications used in Android that are not acceptable for upstream
> hostap.git (mainly, driver_cmd). This would not add any custom nl80211
> extensions; the needed functionality should be added properly to
> upstream nl80211.
What's the driver_cmd things they use? If we they add support for
whatever it is to nl80211, why can those not be normal supplicant
interfaces?
> If it is fine to remove the custom wpa_supplicant modifications from
> Android, this is obviously a moot point, but until that happens, the
> easiest approach seems to be to provide a custom driver_*.c based on
> nl80211 to isolate the custom changes to user space and to small part of
> it at that. I don't really want to see new drivers trying to provide
> WEXT support with private ioctls to address need for making it work with
> Android..
Indeed -- no way. Seems Android needs to learn upstream.
johannes
On Wed, 2011-02-02 at 06:57 -0500, Bob Copeland wrote:
> On Wed, Feb 02, 2011 at 01:30:52PM +0200, Jouni Malinen wrote:
> > If it is fine to remove the custom wpa_supplicant modifications from
> > Android, this is obviously a moot point, but until that happens, the
> > easiest approach seems to be to provide a custom driver_*.c based on
> > nl80211 to isolate the custom changes to user space and to small part of
> > it at that. I don't really want to see new drivers trying to provide
> > WEXT support with private ioctls to address need for making it work with
> > Android..
>
> I guess my argument is if Atheros is spending resources on porting
> drivers to Android, it would be nice to take the time to fix Android's
> userspace too. At any rate, I disagree with the wiki's wording "the
> proper approach" as opposed to maybe "the straight-forward approach."
I couldn't let that sit there so I edited it ;-)
> Android already has a custom userspace library that sits between wpa_s
> and their Java stack where they could probably stick all of this stuff.
> If there is something that is truly missing from the kernel, then by
> all means we can add it to nl80211 for everyone's benefit.
Right. But then stock wpa_s can also get it, and everybody is happy, no?
johannes
On Wed, Feb 02, 2011 at 09:02:52AM +0100, Johannes Berg wrote:
> On Tue, 2011-02-01 at 21:41 -0500, Bob Copeland wrote:
> > From the wiki:
> >
> > "The proper approach would be to provide a custom driver_nl80211_android.c
> > wrapper for the modified wpa_supplicant in Android."
> >
> > I just don't think it's strictly necessary to ship a modified wpa_s.
> > Why is Android special when bog standard Linux gets by ok with
> > driver_nl80211?
>
> Agree, that is a dumb idea. What's that driver going to do? Use custom
> nl80211 extensions?! That way lies insanity.
The only reason for that is to be able to support the wpa_supplicant
modifications used in Android that are not acceptable for upstream
hostap.git (mainly, driver_cmd). This would not add any custom nl80211
extensions; the needed functionality should be added properly to
upstream nl80211.
If it is fine to remove the custom wpa_supplicant modifications from
Android, this is obviously a moot point, but until that happens, the
easiest approach seems to be to provide a custom driver_*.c based on
nl80211 to isolate the custom changes to user space and to small part of
it at that. I don't really want to see new drivers trying to provide
WEXT support with private ioctls to address need for making it work with
Android..
--
Jouni Malinen PGP id EFC895FA
On Wed, Feb 02, 2011 at 01:30:52PM +0200, Jouni Malinen wrote:
> If it is fine to remove the custom wpa_supplicant modifications from
> Android, this is obviously a moot point, but until that happens, the
> easiest approach seems to be to provide a custom driver_*.c based on
> nl80211 to isolate the custom changes to user space and to small part of
> it at that. I don't really want to see new drivers trying to provide
> WEXT support with private ioctls to address need for making it work with
> Android..
I guess my argument is if Atheros is spending resources on porting
drivers to Android, it would be nice to take the time to fix Android's
userspace too. At any rate, I disagree with the wiki's wording "the
proper approach" as opposed to maybe "the straight-forward approach."
Android already has a custom userspace library that sits between wpa_s
and their Java stack where they could probably stick all of this stuff.
If there is something that is truly missing from the kernel, then by
all means we can add it to nl80211 for everyone's benefit.
--
Bob Copeland %% http://www.bobcopeland.com
On Wed, Feb 02, 2011 at 12:33:54PM +0100, Johannes Berg wrote:
> What's the driver_cmd things they use? If we they add support for
> whatever it is to nl80211, why can those not be normal supplicant
> interfaces?
I have not reviewed what exactly gets used and how, so this is only
based on what the modification for wpa_supplicant are exposing.
There seems to be some kind of mechanism for stopping/starting/reloading
the driver which I do not fully understand. It includes some kind of
driver hang detection and maybe recovery from that etc..
Then there is a very generic mechanism of passing any command from user
space (i.e., command string to a SIOCSIWPRIV) and that goes
transparently through wpa_supplicant.. The response comes back as a
string. In other words, you could implement pretty much anything in a
driver specific way with that.. At least following commands are used or
have used with that: RSSI, LINKSPEED, MACADDR, GETPOWER, GETBAND.
Since it is difficult to tell just from wpa_supplicant changes what
exactly is done with these interfaces, the answer to the question of
why these could not be normal supplicant interfaces is not immediately
clear to me. I would assume that some of this functionality could
certainly be added once identified clearly what is needed. Some may
already be available (like MACADDR; assuming it is used to fetch local
MAC address).
--
Jouni Malinen PGP id EFC895FA
On Wed, Feb 2, 2011 at 5:38 AM, Jouni Malinen <[email protected]> wrote:
> On Wed, Feb 02, 2011 at 12:33:54PM +0100, Johannes Berg wrote:
>> What's the driver_cmd things they use? If we they add support for
>> whatever it is to nl80211, why can those not be normal supplicant
>> interfaces?
>
> I have not reviewed what exactly gets used and how, so this is only
> based on what the modification for wpa_supplicant are exposing.
>
> There seems to be some kind of mechanism for stopping/starting/reloading
> the driver which I do not fully understand. It includes some kind of
> driver hang detection and maybe recovery from that etc..
>
> Then there is a very generic mechanism of passing any command from user
> space (i.e., command string to a SIOCSIWPRIV) and that goes
> transparently through wpa_supplicant.. The response comes back as a
> string. In other words, you could implement pretty much anything in a
> driver specific way with that.. At least following commands are used or
> have used with that: RSSI, LINKSPEED, MACADDR, GETPOWER, GETBAND.
>
> Since it is difficult to tell just from wpa_supplicant changes what
> exactly is done with these interfaces, the answer to the question of
> why these could not be normal supplicant interfaces is not immediately
> clear to me. I would assume that some of this functionality could
> certainly be added once identified clearly what is needed. Some may
> already be available (like MACADDR; assuming it is used to fetch local
> MAC address).
Sounds like Android kernel guys need to get their shit together. Why
is this so hard?
Luis