Support for Android for mac80211 / cfg80211 802.11 drivers

Support for Android for mac80211 / cfg80211 802.11 drivers

[Luis R. Rodriguez]

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

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Bob Copeland]

On Tue, Feb 1, 2011 at 6:29 PM, Luis R. Rodriguez <mcgrof@gmail.com> 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 %% www.bobcopeland.com

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Luis R. Rodriguez]

On Tue, Feb 1, 2011 at 4:45 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Tue, Feb 1, 2011 at 6:29 PM, Luis R. Rodriguez <mcgrof@gmail.com> 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

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Bob Copeland]

On Tue, Feb 1, 2011 at 7:50 PM, Luis R. Rodriguez <mcgrof@gmail.com> 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 %% www.bobcopeland.com

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Johannes Berg]

On Tue, 2011-02-01 at 21:41 -0500, Bob Copeland wrote:
> On Tue, Feb 1, 2011 at 7:50 PM, Luis R. Rodriguez <mcgrof@gmail.com> 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

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Jouni Malinen]

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

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Johannes Berg]

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

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Jouni Malinen]

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

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Luis R. Rodriguez]

On Wed, Feb 2, 2011 at 5:38 AM, Jouni Malinen <j@w1.fi> 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

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[hedwin]

The problem with nl80211 and wpa_supplicant in android is that afaik
libnl is needed, correct?
Only problem with libnl is that it is LGPL which doesn't fit into the
android license policy.
Although this is a mailing list about wireless drivers this also needs
to be addressed
because it is part of the problem to get wireless support working in android.

Hedwin

On Wed, Feb 2, 2011 at 5:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Feb 2, 2011 at 5:38 AM, Jouni Malinen <j@w1.fi> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Luis R. Rodriguez]

On Fri, Jun 10, 2011 at 12:28 PM, hedwin <hedwin.koning@gmail.com> wrote:
> The problem with nl80211 and wpa_supplicant in android is that afaik
> libnl is needed, correct?
> Only problem with libnl is that it is LGPL which doesn't fit into the
> android license policy.
> Although this is a mailing list about wireless drivers this also needs
> to be addressed
> because it is part of the problem to get wireless support working in android.

Oh wow, so you mean you won't use libnl for any other things in
android either? Shit out of luck.

  Luis

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[hedwin]

If it needs to be part of AOSP then it will be a problem.
If not it entirely depends on those maintaining the specific android "distro".
Some follow the google policy others don't.

Hedwin

On Fri, Jun 10, 2011 at 9:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Jun 10, 2011 at 12:28 PM, hedwin <hedwin.koning@gmail.com> wrote:
>> The problem with nl80211 and wpa_supplicant in android is that afaik
>> libnl is needed, correct?
>> Only problem with libnl is that it is LGPL which doesn't fit into the
>> android license policy.
>> Although this is a mailing list about wireless drivers this also needs
>> to be addressed
>> because it is part of the problem to get wireless support working in android.
>
> Oh wow, so you mean you won't use libnl for any other things in
> android either? Shit out of luck.
>
>  Luis
>

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[John W. Linville]

On Fri, Jun 10, 2011 at 10:07:09PM +0200, hedwin wrote:
> If it needs to be part of AOSP then it will be a problem.
> If not it entirely depends on those maintaining the specific android "distro".
> Some follow the google policy others don't.

nl80211 doesn't require libnl -- Google will simply have to implement
their own replacement.  Their apparentl (L)GPL allergy has already
led them to do so for the other system components, so why should they
stop now?

In any case, it is Google's problem to solve.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[hedwin]

If I want to use wpa_supplicant it seems that I need to use libnl. If
not how does wpa_supplicant connect to mac80211?

Well if it is google's problem to solve it, this discussion about
wireless support in android is on hold until they've done so. right?

Hedwin


On Fri, Jun 10, 2011 at 10:09 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Fri, Jun 10, 2011 at 10:07:09PM +0200, hedwin wrote:
>> If it needs to be part of AOSP then it will be a problem.
>> If not it entirely depends on those maintaining the specific android "distro".
>> Some follow the google policy others don't.
>
> nl80211 doesn't require libnl -- Google will simply have to implement
> their own replacement.  Their apparentl (L)GPL allergy has already
> led them to do so for the other system components, so why should they
> stop now?
>
> In any case, it is Google's problem to solve.
>
> John
> --
> John W. Linville                Someday the world will need a hero, and you
> linville@tuxdriver.com                  might be all we have.  Be ready.
>

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Jouni Malinen]

On Fri, Jun 10, 2011 at 10:25:17PM +0200, hedwin wrote:
> If I want to use wpa_supplicant it seems that I need to use libnl. If
> not how does wpa_supplicant connect to mac80211?

wpa_supplicant uses libnl for accessing nl80211. If libnl is not
acceptable for whatever reason, I see two options: 1) re-implement libnl
replacement that provides identical API or 2) modify wpa_supplicant
src/drivers/driver_nl80211.c to process nl80211/netlink messages with
internal implementation instead of libnl. I don't care particularly how
that would be done, but trying to use WEXT is not really a reasonable
approach here.

> Well if it is google's problem to solve it, this discussion about
> wireless support in android is on hold until they've done so. right?

I have no reason to believe that Android support could not be discussed
even if some Android distributions do not like libnl. People seem to be
perfectly fine in using libnl on Android. Sure, some cases may not be
able to include libnl, but that should not stop this discussion or
implementation work and there are clear options described above on how
to address the license concern.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[hedwin]

It is surely a dillema because I need the libertas driver in 2.6.37
which moved entitrely to 80211 ditching wext.
The only option I can see right now is to use wext to connect to
mac80211/cfg80211

Hedwin

On Fri, Jun 10, 2011 at 10:07 PM, hedwin <hedwin.koning@gmail.com> wrote:
> If it needs to be part of AOSP then it will be a problem.
> If not it entirely depends on those maintaining the specific android "distro".
> Some follow the google policy others don't.
>
> Hedwin
>
> On Fri, Jun 10, 2011 at 9:37 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> On Fri, Jun 10, 2011 at 12:28 PM, hedwin <hedwin.koning@gmail.com> wrote:
>>> The problem with nl80211 and wpa_supplicant in android is that afaik
>>> libnl is needed, correct?
>>> Only problem with libnl is that it is LGPL which doesn't fit into the
>>> android license policy.
>>> Although this is a mailing list about wireless drivers this also needs
>>> to be addressed
>>> because it is part of the problem to get wireless support working in android.
>>
>> Oh wow, so you mean you won't use libnl for any other things in
>> android either? Shit out of luck.
>>
>>  Luis
>>
>

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Bob Copeland]

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 %% www.bobcopeland.com

Re: Support for Android for mac80211 / cfg80211 802.11 drivers

[Johannes Berg]

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