[Q] ath5k : doesn't support AP mode?

[Q] ath5k : doesn't support AP mode?

[김영환]

Hello~

Lately, I've researched for AP mode in linux. I'm testing 802.11a about
atheros 5414, rt61, zyDAS USB(a/b/g).
I know AP mode are supportted on Prism chipset, Atheros(madwifi).
then how the nic using atheros 5414 chipset?

thank you, friends~~

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 11:54 +0900, =B1=E8=BF=B5=C8=AF wrote:
> Hello~
>=20
> Lately, I've researched for AP mode in linux. I'm testing 802.11a abo=
ut
> atheros 5414, rt61, zyDAS USB(a/b/g).
> I know AP mode are supportted on Prism chipset, Atheros(madwifi).
> then how the nic using atheros 5414 chipset?

mac80211 based drivers including ath5k don't support AP mode yet.
Please use MadWifi with it for now.

--=20
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Wed, 2008-06-25 at 22:57 -0400, Pavel Roskin wrote:
> On Thu, 2008-06-26 at 11:54 +0900, 김영환 wrote:
> > Hello~
> > 
> > Lately, I've researched for AP mode in linux. I'm testing 802.11a about
> > atheros 5414, rt61, zyDAS USB(a/b/g).
> > I know AP mode are supportted on Prism chipset, Atheros(madwifi).
> > then how the nic using atheros 5414 chipset?
> 
> mac80211 based drivers including ath5k don't support AP mode yet.
> Please use MadWifi with it for now.

s/use Madwifi.*\./help fix mac80211 AP mode./

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 15:33 +0200, Johannes Berg wrote:
> On Wed, 2008-06-25 at 22:57 -0400, Pavel Roskin wrote:
> > On Thu, 2008-06-26 at 11:54 +0900, =B1=E8=BF=B5=C8=AF wrote:
> > > Hello~
> > >=20
> > > Lately, I've researched for AP mode in linux. I'm testing 802.11a=
 about
> > > atheros 5414, rt61, zyDAS USB(a/b/g).
> > > I know AP mode are supportted on Prism chipset, Atheros(madwifi).
> > > then how the nic using atheros 5414 chipset?
> >=20
> > mac80211 based drivers including ath5k don't support AP mode yet.
> > Please use MadWifi with it for now.
>=20
> s/use Madwifi.*\./help fix mac80211 AP mode./

That's probably not an answer expected by somebody researching what it
supported now.  But I agree, it would be very nice to have more people
working on the AP mode in mac80211.

--=20
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] ath5k : doesn't support AP mode?

[Stefanik Gábor]

MjAwOC82LzI2IFBhdmVsIFJvc2tpbiA8cHJvc2tpQGdudS5vcmc+Ogo+IE9uIFRodSwgMjAwOC0w
Ni0yNiBhdCAxNTozMyArMDIwMCwgSm9oYW5uZXMgQmVyZyB3cm90ZToKPj4gT24gV2VkLCAyMDA4
LTA2LTI1IGF0IDIyOjU3IC0wNDAwLCBQYXZlbCBSb3NraW4gd3JvdGU6Cj4+ID4gT24gVGh1LCAy
MDA4LTA2LTI2IGF0IDExOjU0ICswOTAwLCCx6L+1yK8gd3JvdGU6Cj4+ID4gPiBIZWxsb34KPj4g
PiA+Cj4+ID4gPiBMYXRlbHksIEkndmUgcmVzZWFyY2hlZCBmb3IgQVAgbW9kZSBpbiBsaW51eC4g
SSdtIHRlc3RpbmcgODAyLjExYSBhYm91dAo+PiA+ID4gYXRoZXJvcyA1NDE0LCBydDYxLCB6eURB
UyBVU0IoYS9iL2cpLgo+PiA+ID4gSSBrbm93IEFQIG1vZGUgYXJlIHN1cHBvcnR0ZWQgb24gUHJp
c20gY2hpcHNldCwgQXRoZXJvcyhtYWR3aWZpKS4KPj4gPiA+IHRoZW4gaG93IHRoZSBuaWMgdXNp
bmcgYXRoZXJvcyA1NDE0IGNoaXBzZXQ/Cj4+ID4KPj4gPiBtYWM4MDIxMSBiYXNlZCBkcml2ZXJz
IGluY2x1ZGluZyBhdGg1ayBkb24ndCBzdXBwb3J0IEFQIG1vZGUgeWV0Lgo+PiA+IFBsZWFzZSB1
c2UgTWFkV2lmaSB3aXRoIGl0IGZvciBub3cuCj4+Cj4+IHMvdXNlIE1hZHdpZmkuKlwuL2hlbHAg
Zml4IG1hYzgwMjExIEFQIG1vZGUuLwo+Cj4gVGhhdCdzIHByb2JhYmx5IG5vdCBhbiBhbnN3ZXIg
ZXhwZWN0ZWQgYnkgc29tZWJvZHkgcmVzZWFyY2hpbmcgd2hhdCBpdAo+IHN1cHBvcnRlZCBub3cu
ICBCdXQgSSBhZ3JlZSwgaXQgd291bGQgYmUgdmVyeSBuaWNlIHRvIGhhdmUgbW9yZSBwZW9wbGUK
PiB3b3JraW5nIG9uIHRoZSBBUCBtb2RlIGluIG1hYzgwMjExLgo+Cj4gLS0KPiBSZWdhcmRzLAo+
IFBhdmVsIFJvc2tpbgo+IC0tCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQg
dGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LXdpcmVsZXNzIiBpbgo+IHRoZSBib2R5IG9mIGEg
bWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnCj4gTW9yZSBtYWpvcmRvbW8gaW5m
byBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sCj4KCk1heWJl
IHdlIGhhZCBtb3JlIHBlb3BsZSB3b3JraW5nIG9uL2RlYnVnZ2luZyBBUCBtb2RlIGlmIHdlIGRp
ZG4ndAppbnRlbnRpb25hbGx5IGRpc2FibGUgdGhlIGV4aXN0aW5nIGxpbWl0ZWQgc3VwcG9ydCBm
b3IgaXQuLi4gUG9zc2libHkKcHJpbnQgYSBiaWcgd2FybmluZyB0aGF0ICJUSElTIElTIE5PVCBT
VEFOREFSRFNfQ09NUExJQU5UIFlFVCEiLCBidXQKb3V0cmlnaHQgZGlzYWJsaW5nIGl0IGFuZCBy
ZXF1aXJpbmcgYW4gZXh0ZXJuYWwgcGF0Y2ggaXMgSU1ITyBzdHVwaWQuClBlcmhhcHMgYSBLY29u
ZmlnIG9wdGlvbiB3aXRoIEVYUEVSSU1FTlRBTCBhbmQgZGVmYXVsdD1uIHdvdWxkIGJlCmJldHRl
ci4KCi0tIApWaXN0YTogW1ZdaXJ1c2VzLCBbSV1udHJ1ZGVycywgW1NdcHl3YXJlLCBbVF1yb2ph
bnMgYW5kIFtBXWR3YXJlLiA6LSkK

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 17:46 +0200, Stefanik G=E1bor wrote:

> Maybe we had more people working on/debugging AP mode if we didn't
> intentionally disable the existing limited support for it... Possibly
> print a big warning that "THIS IS NOT STANDARDS_COMPLIANT YET!", but
> outright disabling it and requiring an external patch is IMHO stupid.
> Perhaps a Kconfig option with EXPERIMENTAL and default=3Dn would be
> better.

I agree.  More people would be looking into AP support for individual
drivers if mac80211 didn't need a patch.

Alone the requirement for hostapd would indicate that the AP mode is no=
t
ready for general consumption.  Going further can actually discourage
some potential contributors.

I suspect somebody in the ath5k camp would look at the AP mode if
mac80211 wasn't forbidding it unconditionally.

--=20
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] ath5k : doesn't support AP mode?

[Michael Buesch]

On Thursday 26 June 2008 18:01:26 Pavel Roskin wrote:
> On Thu, 2008-06-26 at 17:46 +0200, Stefanik G=E1bor wrote:
>=20
> > Maybe we had more people working on/debugging AP mode if we didn't
> > intentionally disable the existing limited support for it... Possib=
ly
> > print a big warning that "THIS IS NOT STANDARDS_COMPLIANT YET!", bu=
t
> > outright disabling it and requiring an external patch is IMHO stupi=
d.
> > Perhaps a Kconfig option with EXPERIMENTAL and default=3Dn would be
> > better.
>=20
> I agree.  More people would be looking into AP support for individual
> drivers if mac80211 didn't need a patch.

I'd also like to get something like the following merged:




Subject: mac80211: allow AP and VLAN modes

This patch is based on a patch by Johannes Berg.
It allows switching interfaces into AP/VLAN modes using
cfg80211 (nl80211). Don't allow doing it with wext because then
people will just attempt to do it manually (without hostapd) and
complain that it doesn't work.

Signed-off-by: Michael Buesch <mb@bu3sch.de>

Index: wireless-testing/net/mac80211/cfg.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-testing.orig/net/mac80211/cfg.c	2008-06-10 13:58:23.000000=
000 +0200
+++ wireless-testing/net/mac80211/cfg.c	2008-06-26 18:12:31.000000000 +=
0200
@@ -33,6 +33,12 @@ nl80211_type_to_mac80211_type(enum nl802
 	case NL80211_IFTYPE_MESH_POINT:
 		return IEEE80211_IF_TYPE_MESH_POINT;
 #endif
+#ifdef CONFIG_MAC80211_AP
+	case NL80211_IFTYPE_AP:
+		return IEEE80211_IF_TYPE_AP;
+	case NL80211_IFTYPE_AP_VLAN:
+		return IEEE80211_IF_TYPE_VLAN;
+#endif /* AP */
 	case NL80211_IFTYPE_WDS:
 		return IEEE80211_IF_TYPE_WDS;
 	default:
Index: wireless-testing/net/mac80211/Kconfig
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-testing.orig/net/mac80211/Kconfig	2008-06-10 13:58:23.0000=
00000 +0200
+++ wireless-testing/net/mac80211/Kconfig	2008-06-26 18:19:13.000000000=
 +0200
@@ -92,6 +92,25 @@ config MAC80211_LEDS
 	  This option enables a few LED triggers for different
 	  packet receive/transmit events.
=20
+config MAC80211_AP
+	bool "AccessPoint and VLAN modes (read help text!)"
+	depends on MAC80211 && EXPERIMENTAL
+	---help---
+	  =3D=3D=3D> BIG FAT WARNING <=3D=3D=3D
+	  This is not IEEE 802.11 compliant, yet!
+	  You might disturb operation of other accesspoints and
+	  stations in your neighbourhood. Do only enable this, if
+	  you want to help out fixing this to make this warning disappear.
+	  If you enable this, expect that your neighbour will ring your
+	  door and yell at you for disturbing his network.
+
+	  This option enables AP/VLAN support in mac80211.
+	  Note that the latest GIT snapshot of the userspace hostapd
+	  daemon is required for this. It will not work without
+	  hostapd or with an old version of hostapd without nl80211 support.
+
+	  Say N.
+
 config MAC80211_DEBUGFS
 	bool "Export mac80211 internals in DebugFS"
 	depends on MAC80211 && DEBUG_FS



--=20
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 18:21 +0200, Michael Buesch wrote:
> +	  ===> BIG FAT WARNING <===
> +	  This is not IEEE 802.11 compliant, yet!
> +	  You might disturb operation of other accesspoints and
> +	  stations in your neighbourhood. Do only enable this, if
> +	  you want to help out fixing this to make this warning disappear.
> +	  If you enable this, expect that your neighbour will ring your
> +	  door and yell at you for disturbing his network.

Gladly there will be no black helicopters :-)

But is it really so bad?  What's the current TODO list for the AP mode?
Is it an issue with 802.11h?  Maybe we could limit Tx power and channels
until the remaining issues are fixed?

Also, I think that the 802.11 simulator should be exempt from any
limitations for obvious reasons.

-- 
Regards,
Pavel Roskin

Re: [Q] ath5k : doesn't support AP mode?

[Michael Buesch]

On Thursday 26 June 2008 18:34:31 Pavel Roskin wrote:
> On Thu, 2008-06-26 at 18:21 +0200, Michael Buesch wrote:
> > +	  ===> BIG FAT WARNING <===
> > +	  This is not IEEE 802.11 compliant, yet!
> > +	  You might disturb operation of other accesspoints and
> > +	  stations in your neighbourhood. Do only enable this, if
> > +	  you want to help out fixing this to make this warning disappear.
> > +	  If you enable this, expect that your neighbour will ring your
> > +	  door and yell at you for disturbing his network.
> 
> Gladly there will be no black helicopters :-)

Oh right. I forgot these :)

> But is it really so bad?

Well no. But I think we should try hard to make users not use this, yet.
Something that is not IEEE 802.11 compliant is not what everybody should use.
There's enough noise in the air that disturbs wireless. I don't want
to have yet another neighbour installing yet another broken thing. ;)

> What's the current TODO list for the AP mode?

I think there are some issues with the rates.
Maybe more. I don't really know.
I was going to look into this, but I was pushed back a little bit
by some hardware and software defects. I probably need to get new
hardware first.

-- 
Greetings Michael.

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]


> > What's the current TODO list for the AP mode?
> 
> I think there are some issues with the rates.
> Maybe more. I don't really know.

It's on the todo list on wireless.kernel.org

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 19:23 +0200, Johannes Berg wrote:
> > > What's the current TODO list for the AP mode?
> > 
> > I think there are some issues with the rates.
> > Maybe more. I don't really know.
> 
> It's on the todo list on wireless.kernel.org

I see it now:
http://wireless.kernel.org/en/developers/todo-list#APsupport

It would be great to split the list into categories.  I don't think
"data frames on cooked monitor" make the AP mode non-compliant.

I also suspect that certain fixed are needed only for 802.11g or 802.11b
compliance, but not for the original 802.11 compliance.

Say, if we limit the rate to 1 Mbps, are there any issues that really
make us non-compliant?

-- 
Regards,
Pavel Roskin

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Thu, 2008-06-26 at 14:03 -0400, Pavel Roskin wrote:
> On Thu, 2008-06-26 at 19:23 +0200, Johannes Berg wrote:
> > > > What's the current TODO list for the AP mode?
> > > 
> > > I think there are some issues with the rates.
> > > Maybe more. I don't really know.
> > 
> > It's on the todo list on wireless.kernel.org
> 
> I see it now:
> http://wireless.kernel.org/en/developers/todo-list#APsupport
> 
> It would be great to split the list into categories.  I don't think
> "data frames on cooked monitor" make the AP mode non-compliant.

That's true.

> I also suspect that certain fixed are needed only for 802.11g or 802.11b
> compliance, but not for the original 802.11 compliance.
> 
> Say, if we limit the rate to 1 Mbps, are there any issues that really
> make us non-compliant?

The fact that we cannot limit the rate like that that?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 20:08 +0200, Johannes Berg wrote:

> > I also suspect that certain fixed are needed only for 802.11g or 802.11b
> > compliance, but not for the original 802.11 compliance.
> > 
> > Say, if we limit the rate to 1 Mbps, are there any issues that really
> > make us non-compliant?
> 
> The fact that we cannot limit the rate like that that?

That shouldn't be hard to implement.

-- 
Regards,
Pavel Roskin

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On Thu, 2008-06-26 at 14:18 -0400, Pavel Roskin wrote:
> On Thu, 2008-06-26 at 20:08 +0200, Johannes Berg wrote:
> 
> > > I also suspect that certain fixed are needed only for 802.11g or 802.11b
> > > compliance, but not for the original 802.11 compliance.
> > > 
> > > Say, if we limit the rate to 1 Mbps, are there any issues that really
> > > make us non-compliant?
> > 
> > The fact that we cannot limit the rate like that that?
> 
> That shouldn't be hard to implement.

Go ahead and post patches then.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]


> > > The fact that we cannot limit the rate like that that?
> > 
> > That shouldn't be hard to implement.
> 
> Go ahead and post patches then.

Mind you, I'm thinking of patches that actually address hostapd's
incapability of setting rates to use/basic rates etc. in the kernel, not
a two-line workaround that only enables 1mbit for AP mode interfaces.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 20:27 +0200, Johannes Berg wrote:
> > > > The fact that we cannot limit the rate like that that?
> > > 
> > > That shouldn't be hard to implement.
> > 
> > Go ahead and post patches then.
> 
> Mind you, I'm thinking of patches that actually address hostapd's
> incapability of setting rates to use/basic rates etc. in the kernel, not
> a two-line workaround that only enables 1mbit for AP mode interfaces.

OK, I won't interfere with your efforts.  I'm sitting on a pile of
unfinished patches myself, so once I'm done with them, I may have a look
at the AP mode in mac80211.  Just please don't make it too hard to help
you, as I have other things waiting for my attention.

-- 
Regards,
Pavel Roskin

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Thu, 2008-06-26 at 14:36 -0400, Pavel Roskin wrote:
> On Thu, 2008-06-26 at 20:27 +0200, Johannes Berg wrote:
> > > > > The fact that we cannot limit the rate like that that?
> > > > 
> > > > That shouldn't be hard to implement.
> > > 
> > > Go ahead and post patches then.
> > 
> > Mind you, I'm thinking of patches that actually address hostapd's
> > incapability of setting rates to use/basic rates etc. in the kernel, not
> > a two-line workaround that only enables 1mbit for AP mode interfaces.
> 
> OK, I won't interfere with your efforts.

I'm not doing anything at the moment, and don't plan to in the
foreseeable future. (Right now I can foresee about half a year.)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Michael Buesch]

On Thursday 26 June 2008 20:18:08 Pavel Roskin wrote:
> On Thu, 2008-06-26 at 20:08 +0200, Johannes Berg wrote:
> 
> > > I also suspect that certain fixed are needed only for 802.11g or 802.11b
> > > compliance, but not for the original 802.11 compliance.
> > > 
> > > Say, if we limit the rate to 1 Mbps, are there any issues that really
> > > make us non-compliant?
> > 
> > The fact that we cannot limit the rate like that that?
> 
> That shouldn't be hard to implement.

We are not going to work around the bugs, I guess.
I'd suggest to put the patch into wireless-testing only.

-- 
Greetings Michael.

Re: [Q] ath5k : doesn't support AP mode?

[John W. Linville]

On Thu, Jun 26, 2008 at 06:21:31PM +0200, Michael Buesch wrote:
> On Thursday 26 June 2008 18:01:26 Pavel Roskin wrote:
> > On Thu, 2008-06-26 at 17:46 +0200, Stefanik G=E1bor wrote:
> >=20
> > > Maybe we had more people working on/debugging AP mode if we didn'=
t
> > > intentionally disable the existing limited support for it... Poss=
ibly
> > > print a big warning that "THIS IS NOT STANDARDS_COMPLIANT YET!", =
but
> > > outright disabling it and requiring an external patch is IMHO stu=
pid.
> > > Perhaps a Kconfig option with EXPERIMENTAL and default=3Dn would =
be
> > > better.
> >=20
> > I agree.  More people would be looking into AP support for individu=
al
> > drivers if mac80211 didn't need a patch.
>=20
> I'd also like to get something like the following merged:

> Subject: mac80211: allow AP and VLAN modes
>=20
> This patch is based on a patch by Johannes Berg.
> It allows switching interfaces into AP/VLAN modes using
> cfg80211 (nl80211). Don't allow doing it with wext because then
> people will just attempt to do it manually (without hostapd) and
> complain that it doesn't work.

I dunno...that last thing I want is to let this go in and then be
locked-in to the current API no-matter-what like we now are with WEXT.

John
--=20
John W. Linville
linville@tuxdriver.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] ath5k : doesn't support AP mode?

[Pavel Roskin]

On Thu, 2008-06-26 at 13:36 -0400, John W. Linville wrote:

> I dunno...that last thing I want is to let this go in and then be
> locked-in to the current API no-matter-what like we now are with WEXT.

Is there any API that needs to be _changed_ (not added) for AP support?
I understand it may be hard to anticipate future needs, but some things
should be clear at this point already.

-- 
Regards,
Pavel Roskin

Re: [Q] ath5k : doesn't support AP mode?

[Michael Buesch]

On Thursday 26 June 2008 19:36:45 John W. Linville wrote:
> On Thu, Jun 26, 2008 at 06:21:31PM +0200, Michael Buesch wrote:
> > On Thursday 26 June 2008 18:01:26 Pavel Roskin wrote:
> > > On Thu, 2008-06-26 at 17:46 +0200, Stefanik G=E1bor wrote:
> > >=20
> > > > Maybe we had more people working on/debugging AP mode if we did=
n't
> > > > intentionally disable the existing limited support for it... Po=
ssibly
> > > > print a big warning that "THIS IS NOT STANDARDS_COMPLIANT YET!"=
, but
> > > > outright disabling it and requiring an external patch is IMHO s=
tupid.
> > > > Perhaps a Kconfig option with EXPERIMENTAL and default=3Dn woul=
d be
> > > > better.
> > >=20
> > > I agree.  More people would be looking into AP support for indivi=
dual
> > > drivers if mac80211 didn't need a patch.
> >=20
> > I'd also like to get something like the following merged:
>=20
> > Subject: mac80211: allow AP and VLAN modes
> >=20
> > This patch is based on a patch by Johannes Berg.
> > It allows switching interfaces into AP/VLAN modes using
> > cfg80211 (nl80211). Don't allow doing it with wext because then
> > people will just attempt to do it manually (without hostapd) and
> > complain that it doesn't work.
>=20
> I dunno...that last thing I want is to let this go in and then be
> locked-in to the current API no-matter-what like we now are with WEXT=
=2E

Well, I really do think that AP development is stuck due to nobody test=
ing it.
So, something like the following patch?
http://foobar would be some page on wireless.kernel.org
describing what additional patches are needed for the latest wireless-t=
esting kernel.

Additionally we might want to put this into wireless-testing only.
There's not a big need for pushing this upstream.
If somebody wants to test AP mode, he'll need to get wireless-testing a=
nyway.






Subject: mac80211: allow AP and VLAN modes

This patch is based on a patch by Johannes Berg.
It allows switching interfaces into AP/VLAN modes using
cfg80211 (nl80211). Don't allow doing it with wext because then
people will just attempt to do it manually (without hostapd) and
complain that it doesn't work.

Signed-off-by: Michael Buesch <mb@bu3sch.de>

Index: wireless-testing/net/mac80211/cfg.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-testing.orig/net/mac80211/cfg.c	2008-06-10 13:58:23.000000=
000 +0200
+++ wireless-testing/net/mac80211/cfg.c	2008-06-26 18:12:31.000000000 +=
0200
@@ -33,6 +33,12 @@ nl80211_type_to_mac80211_type(enum nl802
 	case NL80211_IFTYPE_MESH_POINT:
 		return IEEE80211_IF_TYPE_MESH_POINT;
 #endif
+#ifdef CONFIG_MAC80211_AP
+	case NL80211_IFTYPE_AP:
+		return IEEE80211_IF_TYPE_AP;
+	case NL80211_IFTYPE_AP_VLAN:
+		return IEEE80211_IF_TYPE_VLAN;
+#endif /* AP */
 	case NL80211_IFTYPE_WDS:
 		return IEEE80211_IF_TYPE_WDS;
 	default:
Index: wireless-testing/net/mac80211/Kconfig
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- wireless-testing.orig/net/mac80211/Kconfig	2008-06-10 13:58:23.0000=
00000 +0200
+++ wireless-testing/net/mac80211/Kconfig	2008-06-26 20:05:26.000000000=
 +0200
@@ -92,6 +92,29 @@ config MAC80211_LEDS
 	  This option enables a few LED triggers for different
 	  packet receive/transmit events.
=20
+config MAC80211_AP
+	bool "AccessPoint and VLAN modes (read help text!)"
+	depends on MAC80211 && EXPERIMENTAL
+	---help---
+	  =3D=3D=3D> BIG FAT WARNING <=3D=3D=3D
+	  This is not IEEE 802.11 compliant, yet!
+	  You might disturb operation of other accesspoints and
+	  stations in your neighbourhood. Do only enable this, if
+	  you want to help out fixing this to make this warning disappear.
+	  If you enable this, expect that your neighbour will ring your
+	  door and yell at you for disturbing his network.
+	  Also note that the AccessPoint userspace ABI is not stable, yet,
+	  and subject to change until this warning disappears.
+
+	  This option enables AP/VLAN support in mac80211.
+	  Note that the latest GIT snapshot of the userspace hostapd
+	  daemon is required for this. It will not work without
+	  hostapd or with an old version of hostapd without nl80211 support.
+	  You might need additional patches to hostapd to update it to
+	  the latest nl80211 ABI. See http://foobar for details.
+
+	  Say N.
+
 config MAC80211_DEBUGFS
 	bool "Export mac80211 internals in DebugFS"
 	depends on MAC80211 && DEBUG_FS



--=20
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]


> Alone the requirement for hostapd would indicate that the AP mode is not
> ready for general consumption.

???
That requirement is _never_ going to change.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

On Thu, 2008-06-26 at 12:01 -0400, Pavel Roskin wrote:
> On Thu, 2008-06-26 at 17:46 +0200, Stefanik Gábor wrote:
> 
> > Maybe we had more people working on/debugging AP mode if we didn't
> > intentionally disable the existing limited support for it... Possibly
> > print a big warning that "THIS IS NOT STANDARDS_COMPLIANT YET!", but
> > outright disabling it and requiring an external patch is IMHO stupid.
> > Perhaps a Kconfig option with EXPERIMENTAL and default=n would be
> > better.
> 
> I agree.  More people would be looking into AP support for individual
> drivers if mac80211 didn't need a patch.

Oh and I never answered to this. I disagree. Requiring people to patch
their kernel for AP mode support is a good way to discourage
"contributors" who don't even know how to compile a kernel, trust me,
I've seen a fair share of private mails from those (which I ignore: do
not mail me in private about AP support).

Hence, I don't want to do it for exactly this reason: a bunch of dumb
users will enable it either way, and actually _working_ on AP mode
_will_ require kernel patches, so this isn't one that matters.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Stefanik Gábor]

On Thu, Jun 26, 2008 at 7:27 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2008-06-26 at 12:01 -0400, Pavel Roskin wrote:
>> On Thu, 2008-06-26 at 17:46 +0200, Stefanik G=E1bor wrote:
>>
>> > Maybe we had more people working on/debugging AP mode if we didn't
>> > intentionally disable the existing limited support for it... Possi=
bly
>> > print a big warning that "THIS IS NOT STANDARDS_COMPLIANT YET!", b=
ut
>> > outright disabling it and requiring an external patch is IMHO stup=
id.
>> > Perhaps a Kconfig option with EXPERIMENTAL and default=3Dn would b=
e
>> > better.
>>
>> I agree.  More people would be looking into AP support for individua=
l
>> drivers if mac80211 didn't need a patch.
>
> Oh and I never answered to this. I disagree. Requiring people to patc=
h
> their kernel for AP mode support is a good way to discourage
> "contributors" who don't even know how to compile a kernel, trust me,
> I've seen a fair share of private mails from those (which I ignore: d=
o
> not mail me in private about AP support).
>
> Hence, I don't want to do it for exactly this reason: a bunch of dumb
> users will enable it either way, and actually _working_ on AP mode
> _will_ require kernel patches, so this isn't one that matters.

The problem is that the location of the patch is extremely
non-obvious. Essentially one must know the location of either your or
Michael Buesch's patchset before doing anything with AP mode. Also, to
me "AP support requires mac80211 and nl80211 enhancements. In addition
to this you need external wireless-test.git patches from johill and
hostapd patches" (from the TODO-list) suggests that more than just the
"Allow AP/VLAN modes" patch is required to get any AP support - in
fact, it might feel like it's easier to just write a monitor-mode
injection app that can do all AP work in userspace (=E1 la airbase-ng,
just with better system integration and feature set centered around
normal operation, rather than penetration testing).

Also, someone who can't patch a kernel likely also won't be able to
compile and use a git build of hostapd. IMO this provides enough
foolproofing. If we need more, then maybe add a secret and
undocumented (but clearly deducible from the code, not obfuscated)
parameter to hostapd, without which it refuses to handle nl80211-based
interfaces. The location of the patch can in no way be deduced from
the code.

And, by the way, should we also require a patch for all experimental
drivers? I don't think so.

>
> johannes
>



--=20
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]


> > Oh and I never answered to this. I disagree. Requiring people to patch
> > their kernel for AP mode support is a good way to discourage
> > "contributors" who don't even know how to compile a kernel, trust me,
> > I've seen a fair share of private mails from those (which I ignore: do
> > not mail me in private about AP support).
> >
> > Hence, I don't want to do it for exactly this reason: a bunch of dumb
> > users will enable it either way, and actually _working_ on AP mode
> > _will_ require kernel patches, so this isn't one that matters.
> 
> The problem is that the location of the patch is extremely
> non-obvious.

Umm. The paragraph you're quoting:

> "AP support requires mac80211 and nl80211 enhancements. In addition
> to this you need external wireless-test.git patches from johill and
> hostapd patches" (from the TODO-list) suggests that more than just the
> "Allow AP/VLAN modes" patch is required to get any AP support

actually links to the patch so what is your point?

> Also, someone who can't patch a kernel likely also won't be able to
> compile and use a git build of hostapd. IMO this provides enough
> foolproofing. If we need more, then maybe add a secret and
> undocumented (but clearly deducible from the code, not obfuscated)
> parameter to hostapd, without which it refuses to handle nl80211-based
> interfaces. The location of the patch can in no way be deduced from
> the code.
> 
> And, by the way, should we also require a patch for all experimental
> drivers? I don't think so.

You're missing the point.

We do NOT want people to use mac80211's AP support UNLESS they also work
on improving it.

The "improving it" part REQUIRES patching the kernel. Hence, requiring
patching the kernel to get AP mode support in the first place cannot be
considered a hindrance.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Q] ath5k : doesn't support AP mode?

[Stefanik Gábor]

On Thu, Jun 26, 2008 at 8:20 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> > Oh and I never answered to this. I disagree. Requiring people to patch
>> > their kernel for AP mode support is a good way to discourage
>> > "contributors" who don't even know how to compile a kernel, trust me,
>> > I've seen a fair share of private mails from those (which I ignore: do
>> > not mail me in private about AP support).
>> >
>> > Hence, I don't want to do it for exactly this reason: a bunch of dumb
>> > users will enable it either way, and actually _working_ on AP mode
>> > _will_ require kernel patches, so this isn't one that matters.
>>
>> The problem is that the location of the patch is extremely
>> non-obvious.
>
> Umm. The paragraph you're quoting:
>
>> "AP support requires mac80211 and nl80211 enhancements. In addition
>> to this you need external wireless-test.git patches from johill and
>> hostapd patches" (from the TODO-list) suggests that more than just the
>> "Allow AP/VLAN modes" patch is required to get any AP support
>
> actually links to the patch so what is your point?

It liks to your series file, which is mostly unusable due to the NPUB
patches. (When I wrote the post, there was an additional problem with
the text that suggested that more than just that patch is needed.)
Essentially, one has to patch the patch first.

>
>> Also, someone who can't patch a kernel likely also won't be able to
>> compile and use a git build of hostapd. IMO this provides enough
>> foolproofing. If we need more, then maybe add a secret and
>> undocumented (but clearly deducible from the code, not obfuscated)
>> parameter to hostapd, without which it refuses to handle nl80211-based
>> interfaces. The location of the patch can in no way be deduced from
>> the code.
>>
>> And, by the way, should we also require a patch for all experimental
>> drivers? I don't think so.
>
> You're missing the point.
>
> We do NOT want people to use mac80211's AP support UNLESS they also work
> on improving it.
>
> The "improving it" part REQUIRES patching the kernel. Hence, requiring
> patching the kernel to get AP mode support in the first place cannot be
> considered a hindrance.
>
> johannes
>

Isn't it enough if we only put the patch in the wireless-testing
kernel, and don't commit it to the mainline? Or maybe making it depend
on BROKEN, like b43's NPHY support? What we are doing right now is
essentially the same as if Buesch changed his experimental open-source
b43 firmware to require editing the code and inserting a magic number
to make it compile. I consider that to be quite different from an &&
BROKEN in the dependency list - and && BROKEN can be removed by
someone who really wants to develop AP mode, while the current method
requires finding the patch (because the link leads to a broken SERIES
file.)

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Re: [Q] ath5k : doesn't support AP mode?

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

Can you please remove some of the text you're quoting? Thanks.

> > actually links to the patch so what is your point?
> 
> It liks to your series file, which is mostly unusable due to the NPUB
> patches. (When I wrote the post, there was an additional problem with
> the text that suggested that more than just that patch is needed.)
> Essentially, one has to patch the patch first.

Is it really too much to ask to read the first four paragraphs of my
series file? I can put in some arrow ascii art if you prefer...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]