From: Luis R. Rodriguez <hidden> Date: 2011-02-01 23:29:57
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
From: Bob Copeland <me@bobcopeland.com> Date: 2011-02-02 00:49:06
On Tue, Feb 1, 2011 at 6:29 PM, Luis R. Rodriguez [off-list ref] 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
From: Luis R. Rodriguez <hidden> Date: 2011-02-02 00:50:44
On Tue, Feb 1, 2011 at 4:45 PM, Bob Copeland [off-list ref] wrote:
On Tue, Feb 1, 2011 at 6:29 PM, Luis R. Rodriguez [off-list ref] wrote:
quoted
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.
From: Bob Copeland <me@bobcopeland.com> Date: 2011-02-02 02:41:28
On Tue, Feb 1, 2011 at 7:50 PM, Luis R. Rodriguez [off-list ref] wrote:
quoted
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
From: Johannes Berg <johannes@sipsolutions.net> Date: 2011-02-02 08:03:03
On Tue, 2011-02-01 at 21:41 -0500, Bob Copeland wrote:
On Tue, Feb 1, 2011 at 7:50 PM, Luis R. Rodriguez [off-list ref] wrote:
quoted
quoted
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
From: Johannes Berg <johannes@sipsolutions.net> Date: 2011-02-02 11:34:01
On Wed, 2011-02-02 at 13:30 +0200, Jouni Malinen wrote:
quoted
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
From: Johannes Berg <johannes@sipsolutions.net> Date: 2011-02-02 12:03:54
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:
quoted
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:
quoted
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
From: Bob Copeland <me@bobcopeland.com> Date: 2011-02-02 12:29:44
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
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
From: Luis R. Rodriguez <hidden> Date: 2011-02-02 16:37:35
On Wed, Feb 2, 2011 at 5:38 AM, Jouni Malinen [off-list ref] wrote:
On Wed, Feb 02, 2011 at 12:33:54PM +0100, Johannes Berg wrote:
quoted
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
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 [off-list ref] wrote:
On Wed, Feb 2, 2011 at 5:38 AM, Jouni Malinen [off-list ref] wrote:
quoted
On Wed, Feb 02, 2011 at 12:33:54PM +0100, Johannes Berg wrote:
quoted
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/
From: Luis R. Rodriguez <hidden> Date: 2011-06-10 19:38:16
On Fri, Jun 10, 2011 at 12:28 PM, hedwin [off-list ref] 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
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 [off-list ref] wrote:
On Fri, Jun 10, 2011 at 12:28 PM, hedwin [off-list ref] wrote:
quoted
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
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 [off-list ref] 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 [off-list ref] wrote:
quoted
On Fri, Jun 10, 2011 at 12:28 PM, hedwin [off-list ref] wrote:
quoted
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
From: John W. Linville <hidden> Date: 2011-06-10 20:16:27
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.
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
[off-list ref] wrote:
On Fri, Jun 10, 2011 at 10:07:09PM +0200, hedwin wrote:
quoted
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.
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