This patch adds initial support for master mode for zd1211rw USB
wireless driver (via tools such as hostapd).
It enables basic functionality like association from a managed station
and identifying the master mode by scanning from a station.
Signed-off-by: Rami Rosen <[email protected]>
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
b/drivers/net/wireless/zd1211rw/zd_mac.c
index 980acdf..03be818 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -721,6 +721,7 @@ static int zd_op_add_interface(struct ieee80211_hw *hw,
return -EOPNOTSUPP;
switch (conf->type) {
+ case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_MONITOR:
case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_STATION:
@@ -972,6 +973,7 @@ struct ieee80211_hw *zd_mac_alloc_hw(struct
usb_interface *intf)
IEEE80211_HW_SIGNAL_DB;
hw->wiphy->interface_modes =
+ BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_MESH_POINT) |
BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_ADHOC);
On Wed, Nov 19, 2008 at 01:00:46PM -0800, Luis Rodriguez wrote:
> On Wed, Nov 19, 2008 at 12:30:19PM -0800, Johannes Berg wrote:
> > On Wed, 2008-11-19 at 11:01 -0500, John W. Linville wrote:
> >
> > > Is there some way we could take that into account? I'm sure there
> > > are users who would prefer to have an AP (i.e. their laptop) that
> > > can't support PS clients rather than not having an AP at all.
> >
> > That's a good question. The distinction here is between empowering users
> > to do the wrong thing (AP without proper PS support) and enforcing the
> > right thing (with the consequence of complete loss of AP functionality).
> > The issue I see here is that users will see "ohh shiny, AP support"
> > without knowing that it doesn't actually really support it. Not sure
> > which side of the line we want to stand on, I prefer the correctness
> > side but I can see arguments for the other side, would just like to have
> > users know. Maybe we could have some way to tell hostapd this and then
> > have hostapd print a huge warning about it when started up?
>
> How about making it Kconfigable for broken AP support and add the
> warning there?
That is have something like CONFIG_MAC80211_AP_HALF_ASSED
Luis
Hello,
Thanks for your answer.
Now, after looking at the API doc , It seems to me that sequence
numbering is also missing in the zd1211rw driver.
Regards,
Rami Rosen
On Wed, Nov 19, 2008 at 4:49 PM, Johannes Berg
<[email protected]> wrote:
> On Wed, 2008-11-19 at 15:59 +0200, Rami Rosen wrote:
>
>> Two examples:
>> 1.1) In the link below it says: "ZD1211 can operate in the mode of
>> station and access point."
>> http://linux.softpedia.com/get/System/Hardware/ZD1211-Driver-12712.shtml
>
> Maybe it can.
>
>> - Can you please elaborate a bit about how can we know whether a
>> device support or does not support multicast buffering ?
>
> I have no idea. At minimum, the driver needs to do what the wiki says:
> http://wireless.kernel.org/en/developers/Documentation/mac80211/API
> You'll also want to read the 802.11 docs about this.
>
>> - Could it be that some zd1211 chipsets do support multicast
>> buffering, and some do not ?
>
> Doubt it, they all use the same firmware.
>
> johannes
>
On Mon, 2008-11-17 at 17:51 +0200, Rami Rosen wrote:
> This patch adds initial support for master mode for zd1211rw USB
> wireless driver (via tools such as hostapd).
> It enables basic functionality like association from a managed station
> and identifying the master mode by scanning from a station.
NAK. This device does not support multicast buffering.
johannes
On Wed, Nov 19, 2008 at 01:00:46PM -0800, Luis R. Rodriguez wrote:
> On Wed, Nov 19, 2008 at 12:30:19PM -0800, Johannes Berg wrote:
> > On Wed, 2008-11-19 at 11:01 -0500, John W. Linville wrote:
> >
> > > Is there some way we could take that into account? I'm sure there
> > > are users who would prefer to have an AP (i.e. their laptop) that
> > > can't support PS clients rather than not having an AP at all.
> >
> > That's a good question. The distinction here is between empowering users
> > to do the wrong thing (AP without proper PS support) and enforcing the
> > right thing (with the consequence of complete loss of AP functionality).
> > The issue I see here is that users will see "ohh shiny, AP support"
> > without knowing that it doesn't actually really support it. Not sure
> > which side of the line we want to stand on, I prefer the correctness
> > side but I can see arguments for the other side, would just like to have
> > users know. Maybe we could have some way to tell hostapd this and then
> > have hostapd print a huge warning about it when started up?
>
> How about making it Kconfigable for broken AP support and add the
> warning there?
That doesn't really associate the bad behavior with specific drivers.
Probably better to send something do dmesg and/or make hostap aware
of the issue.
Any idea if many STAs are smart enough to stop going to sleep once
(or if) they realize they are missing frames?
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Wed, 2008-11-19 at 16:18 -0500, John W. Linville wrote:
> > How about making it Kconfigable for broken AP support and add the
> > warning there?
>
> That doesn't really associate the bad behavior with specific drivers.
> Probably better to send something do dmesg and/or make hostap aware
> of the issue.
Indeed. It also doesn't help you when you're sitting on a train, IBSS
mode isn't working and you need to exchange information with some other
device :) Mind you, normal users would need to have NM support for APs
anyway...
> Any idea if many STAs are smart enough to stop going to sleep once
> (or if) they realize they are missing frames?
They barely have a chance to tell the difference between that and just
regular packet loss, so I doubt any are. mac80211 certainly wouldn't be,
and I don't see how to program such a thing easily.
johannes
On Wed, Nov 19, 2008 at 09:30:19PM +0100, Johannes Berg wrote:
> That's a good question. The distinction here is between empowering users
> to do the wrong thing (AP without proper PS support) and enforcing the
> right thing (with the consequence of complete loss of AP functionality).
> The issue I see here is that users will see "ohh shiny, AP support"
> without knowing that it doesn't actually really support it. Not sure
> which side of the line we want to stand on, I prefer the correctness
> side but I can see arguments for the other side, would just like to have
> users know. Maybe we could have some way to tell hostapd this and then
> have hostapd print a huge warning about it when started up?
I would be fine adding such a warning into hostapd if someone comes up
with the patch and mac80211/nl80211 changes to provide the
working-PS-mode capability flag.
Is the problem with zd1211rw just in PS buffering of multicast/broadcast
frames or does it also have problems with unicast? Many use cases could
handle the multicast/broadcast case, but if unicast PS buffering does
not work properly, there may be more issues.. Anyway, this leaves a
nasty surprise for the end user who may not even realize what power
saving really means in context of 802.11 and would not have any way of
figuring out why the connection does not work suddenly when the STA goes
to power save mode.
--
Jouni Malinen PGP id EFC895FA
On Wed, 2008-11-19 at 11:01 -0500, John W. Linville wrote:
> Is there some way we could take that into account? I'm sure there
> are users who would prefer to have an AP (i.e. their laptop) that
> can't support PS clients rather than not having an AP at all.
That's a good question. The distinction here is between empowering users
to do the wrong thing (AP without proper PS support) and enforcing the
right thing (with the consequence of complete loss of AP functionality).
The issue I see here is that users will see "ohh shiny, AP support"
without knowing that it doesn't actually really support it. Not sure
which side of the line we want to stand on, I prefer the correctness
side but I can see arguments for the other side, would just like to have
users know. Maybe we could have some way to tell hostapd this and then
have hostapd print a huge warning about it when started up?
johannes
Hello,
Regarding zd1211 working as an access point in master mode:
1) Searching for it shows that zd1211 chips do support acting as an
access point (master mode).
Two examples:
1.1) In the link below it says: "ZD1211 can operate in the mode of
station and access point."
http://linux.softpedia.com/get/System/Hardware/ZD1211-Driver-12712.shtml
2) I saw that in the zd1201 driver there is an access point parameter
to the module ;
in drivers/net/wireless/zd1201.c, we have:
module_param(ap, int, 0).
- Can you please elaborate a bit about how can we know whether a
device support or does not support multicast buffering ?
- Could it be that some zd1211 chipsets do support multicast
buffering, and some do not ?
Regards,
Rami Rosen
On Mon, Nov 17, 2008 at 7:40 PM, Johannes Berg
<[email protected]> wrote:
> On Mon, 2008-11-17 at 17:51 +0200, Rami Rosen wrote:
>> This patch adds initial support for master mode for zd1211rw USB
>> wireless driver (via tools such as hostapd).
>> It enables basic functionality like association from a managed station
>> and identifying the master mode by scanning from a station.
>
> NAK. This device does not support multicast buffering.
>
> johannes
>
On Wed, 2008-11-19 at 15:59 +0200, Rami Rosen wrote:
> Two examples:
> 1.1) In the link below it says: "ZD1211 can operate in the mode of
> station and access point."
> http://linux.softpedia.com/get/System/Hardware/ZD1211-Driver-12712.shtml
Maybe it can.
> - Can you please elaborate a bit about how can we know whether a
> device support or does not support multicast buffering ?
I have no idea. At minimum, the driver needs to do what the wiki says:
http://wireless.kernel.org/en/developers/Documentation/mac80211/API
You'll also want to read the 802.11 docs about this.
> - Could it be that some zd1211 chipsets do support multicast
> buffering, and some do not ?
Doubt it, they all use the same firmware.
johannes
On Thu, 2008-11-20 at 10:27 +0200, Jouni Malinen wrote:
> I would be fine adding such a warning into hostapd if someone comes up
> with the patch and mac80211/nl80211 changes to provide the
> working-PS-mode capability flag.
Alright. I don't particularly care, so I'm not going to do that ;)
> Is the problem with zd1211rw just in PS buffering of multicast/broadcast
> frames or does it also have problems with unicast? Many use cases could
> handle the multicast/broadcast case, but if unicast PS buffering does
> not work properly, there may be more issues.. Anyway, this leaves a
> nasty surprise for the end user who may not even realize what power
> saving really means in context of 802.11 and would not have any way of
> figuring out why the connection does not work suddenly when the STA goes
> to power save mode.
unicast buffering should be doable well in software though, no?
johannes
On Wed, Nov 19, 2008 at 04:17:49PM +0100, Johannes Berg wrote:
> On Wed, 2008-11-19 at 17:09 +0200, Rami Rosen wrote:
> > Hello,
> > Thanks for your answer.
> >
> > Now, after looking at the API doc , It seems to me that sequence
> > numbering is also missing in the zd1211rw driver.
>
> Possible, but that's not a huge problem. Not having multicast buffering
> means it won't work for powersaving clients, which is.
Is there some way we could take that into account? I'm sure there
are users who would prefer to have an AP (i.e. their laptop) that
can't support PS clients rather than not having an AP at all.
John
--
John W. Linville Linux should be at the core
[email protected] of your literate lifestyle.
On Wed, 2008-11-19 at 17:09 +0200, Rami Rosen wrote:
> Hello,
> Thanks for your answer.
>
> Now, after looking at the API doc , It seems to me that sequence
> numbering is also missing in the zd1211rw driver.
Possible, but that's not a huge problem. Not having multicast buffering
means it won't work for powersaving clients, which is.
johannes
On Wednesday 19 November 2008 22:16:00 Luis R. Rodriguez wrote:
> On Wed, Nov 19, 2008 at 01:00:46PM -0800, Luis Rodriguez wrote:
> > On Wed, Nov 19, 2008 at 12:30:19PM -0800, Johannes Berg wrote:
> > > On Wed, 2008-11-19 at 11:01 -0500, John W. Linville wrote:
> > >
> > > > Is there some way we could take that into account? I'm sure there
> > > > are users who would prefer to have an AP (i.e. their laptop) that
> > > > can't support PS clients rather than not having an AP at all.
> > >
> > > That's a good question. The distinction here is between empowering users
> > > to do the wrong thing (AP without proper PS support) and enforcing the
> > > right thing (with the consequence of complete loss of AP functionality).
> > > The issue I see here is that users will see "ohh shiny, AP support"
> > > without knowing that it doesn't actually really support it. Not sure
> > > which side of the line we want to stand on, I prefer the correctness
> > > side but I can see arguments for the other side, would just like to have
> > > users know. Maybe we could have some way to tell hostapd this and then
> > > have hostapd print a huge warning about it when started up?
> >
> > How about making it Kconfigable for broken AP support and add the
> > warning there?
>
> That is have something like CONFIG_MAC80211_AP_HALF_ASSED
This is not acceptable, IMO, because distros will always enable it and users
still won't know about it.
We want _users_ to know.
So the idea of letting hostapd print a huge message is not that bad.
--
Greetings Michael.
On Wed, Nov 19, 2008 at 12:30:19PM -0800, Johannes Berg wrote:
> On Wed, 2008-11-19 at 11:01 -0500, John W. Linville wrote:
>
> > Is there some way we could take that into account? I'm sure there
> > are users who would prefer to have an AP (i.e. their laptop) that
> > can't support PS clients rather than not having an AP at all.
>
> That's a good question. The distinction here is between empowering users
> to do the wrong thing (AP without proper PS support) and enforcing the
> right thing (with the consequence of complete loss of AP functionality).
> The issue I see here is that users will see "ohh shiny, AP support"
> without knowing that it doesn't actually really support it. Not sure
> which side of the line we want to stand on, I prefer the correctness
> side but I can see arguments for the other side, would just like to have
> users know. Maybe we could have some way to tell hostapd this and then
> have hostapd print a huge warning about it when started up?
How about making it Kconfigable for broken AP support and add the
warning there?
Luis