Dear all,
I have tried unsuccessfully to obtain any WLAN USB stick with a
chipset that supports AP mode.
This is for testing a mobile device that is supposed to work as an AP
with iPod/iPhone life forms.
There only seem to be two choices: p54usb-based (preferred) and
rt2500-based devices. No luck in buying any of the listed devices
(they seem obsolete).
Turns out that anything current I can buy probably has RTL8187, RT73
or RT2800, and anything used I get from ebay is not what it seems
("Netgear WG111 v2" can mean at least two different things I know of,
both unsuitable).
Any pointers on
a) where to click-and-buy a stick that supports AP mode, or
b) whom to send money in exchange for a used stick are VERY much appreciated.
Thank you,
Stefan.
Jouni Malinen <[email protected]> writes:
>> Also deliberately breaking 802.11 specification sounds very wrong to me.
>> We can, and should, aim higher than that.
>
> Well, breaking specifications may have to be done in some cases ;-), but
> this particular feature is not really such a case.
Yes, you are correct (as usual). The specification is not perfect, far
from it :)
> However, I do understand the desire to be able to use some kind of AP
> mode even if it is known to be broken for some cases.
Actually what are the reasons why an user would prefer AP mode over
Ad-Hoc mode, if he doesn't care about power save? Better coverage
between clients and better encryption, but that's it. Right?
--
Kalle Valo
2009/6/10 Johannes Berg <[email protected]>:
> Now, it may or may not be possible to work around this in software by
> sending out the multicast frames on a high-priority queue right after
> the beacon, or something like that, but frankly I'm not interested in
> working on zd1211rw myself, so that will have to be somebody who is (a)
> familiar with 802.11 powersaving and multicast buffering, (b) wants
> zd1211rw to work, and finally (c) has a lot of time to play with the
> device.
For the sake of being pedantic, can I have some reference (if only for
those sleepless nights for lack of boring reading materials...)? Maybe
I won't understand it anyway, but maybe somebody else who is
listening in to this exchange can chip in.
I have a 1300-page pdf supposedly the 802.11 2007 standard I
downloaded some months ago through one of the wikipedia links, I think
(somewhere under http://standards.ieee.org/) ... chapter 11 is MLME
and section 11.2 is power management, which in turn is split into two
sub-sections about power management in infrastructure nework and IBSS
mode. I found a particular sentence in section 11.2.1. which sounds a
bit like what you are saying (except with some cryptic acronyms!):
------
If any STA in its BSS is in PSmode, the AP shall buffer all broadcast
and multicast MSDUs and deliver them to all STAs immediately
following the next Beacon frame containing a DTIM transmission.
------
Have I found the right place to read up on such things, or there are
other documents, etc (more detailed, or more "layman")?
On the broken-AP mode in the zd1211 vendor driver - presumably Zydas
did not wrote that specially for linux, but just modified/adapted from
their windows driver? So I guess windows users of zd1211 (or other USB
sticks) are used to being able to do such things and assume whatever
it does is normal? It just crossed my mind that if some off-spec
behavior is sufficiently popular on windows (e.g. if
connection-sharing requires AP mode to work and won't take IBSS),
sometimes the spec gets modified to ratify a formerly barbaric
off-spec behavior.
Hin-Tak
On Wed, 2009-06-10 at 17:49 +0200, Johannes Berg wrote:
> Now, it may or may not be possible to work around this in software by
> sending out the multicast frames on a high-priority queue right after
> the beacon, or something like that, but frankly I'm not interested in
> working on zd1211rw myself, so that will have to be somebody who is (a)
> familiar with 802.11 powersaving and multicast buffering, (b) wants
> zd1211rw to work, and finally (c) has a lot of time to play with the
> device.
And also, until the work has been done to determine whether an
acceptable solution in software is possible, I do not want to see any of
the upper-layer work to support this "BROKEN_AP" mode you've been
advocating. IOW, I think we should look into adding that only after we
have determined for sure that we actually need it.
johannes
On Wed, Jun 10, 2009 at 10:19:06PM +0300, Kalle Valo wrote:
> "John W. Linville" <[email protected]> writes:
> > I'm still a bit "on the fence" regarding this requirement for AP mode.
> > I think there is a reasonable body of users that would prefer a
> > not-quite-right AP mode over no AP mode at all.
> I understand your point, but the problems from this are so severe that
> it would just create a headache for everyone, both for the users and for
> us. Think of what kind of problems randomly loosing broadcast and
> multicast frames would create: random disconnects, not finding hosts
> from the local network etc. How would a normal user realise that this is
> because of broken power save support in the AP?
>
> Also deliberately breaking 802.11 specification sounds very wrong to me.
> We can, and should, aim higher than that.
Well, breaking specifications may have to be done in some cases ;-), but
this particular feature is not really such a case. However, I do
understand the desire to be able to use some kind of AP mode even if it
is known to be broken for some cases.
I don't like the idea of making hostapd warn the user somehow, but could
probably live with something like AP mode being implemented in the
driver, but disabled by default. Only if the user were to use a module
parameter, say, broken_ap_mode=1, would the support for AP mode be
registered. As long as distros do not start adding this parameter by
default, this would force the user to become at least somehow informed
about the issues and make a conscious choice in enabling the mode.
--
Jouni Malinen PGP id EFC895FA
Johannes Berg <[email protected]> writes:
> On Wed, 2009-06-10 at 17:22 +0200, G?bor Stefanik wrote:
>> On Wed, Jun 10, 2009 at 3:39 PM, Hin-Tak Leung<[email protected]> wrote:
>
>> (Note that I'm also for allowing such "buggy" AP mode on devices
>> without a HW multicast buffer, perhaps with hostapd spitting out a
>> big, fat warning on startup; but Johannes has the final say in
>> mac80211-related questions.)
>>
>> (To Johannes: exactly why is it required for the multicast buffer to
>> be in hardware?)
>
> It isn't required, ath5k/9k don't have it there, they have the notorious
> "CAB" queue for sending frames directly after the beacon. So does b43,
> and probably other designs. The problem really is that powersave mode is
> very important for small clients like your mobile phone or digital
> camera, or even bluetooth3 device, and not doing multicast buffering
> correctly means that either those devices get into weird unreachable
> states, or you need to turn off powersaving features on them which makes
> the battery drain unbearable.
Not only mobile clients, but as we are talking about enabling power save
by default, also Linux laptops would have problems.
> Now, it may or may not be possible to work around this in software by
> sending out the multicast frames on a high-priority queue right after
> the beacon,
And the DTIM beacon should have the broadcast/multicast TIM bit set
before sending the frames.
> or something like that, but frankly I'm not interested in working on
> zd1211rw myself, so that will have to be somebody who is (a) familiar
> with 802.11 powersaving and multicast buffering, (b) wants zd1211rw to
> work, and finally (c) has a lot of time to play with the device.
If someone really has that much time, I think it's better to spend it on
more important issues than this.
--
Kalle Valo
On Wed, Jun 10, 2009 at 8:30 AM, Johannes Berg<[email protected]> wrote:
> On Wed, 2009-06-10 at 04:18 +0100, Hin-Tak Leung wrote:
>
>> But I have been using vendor driver 3.0 for a few weeks in AP mode and
>> I am as happy with it as I could be, I think; I have
>> suspended//resumed clients. It works adequately.
>
> We're not concerned about suspend/hibernate, we're concerned about
> 802.11 power saving, where the AP is required to buffer frames until the
> clients wake up again. This will work adequately, but not perfectly, for
> unicast frames, but we have not found a way of making zd1211 send
> buffered multicast frames after the DTIM beacon as required.
>
> This means that your sleeping clients will not be receiving multicast,
> and as such be invisible to the network once they fall off the ARP/NDP
> caches. This is the reason we have said that it will not be possible to
> support AP mode with this card. I'm curious how, if at all, the vendor
> driver handles that.
I was talking about the client suspending/resuming (i.e. the client
disappearing).
This is what appears in the AP machine's dmesg during the client's sleep:
---------------------------------------------------------
*****Age one*****
aid:1
now:264313809
ttl:264163665
idleTime:150144
zd1205_notify_disjoin_event
Send Deasoc Req to 00:16:44:8f:71:93 RSN=4
STA_DISASSOCIATED:00:16:44:8f:71:93
Reject Auth Due to ar2524drv/src/zdpsmon.c,568. staSte=4
Update BCN @ 286757537
Re_Asoc: 00:16:44:8f:71:93, aid=1
------------------------------------------------------------
It seems that the vendor driver on the AP machine simply diassociates
a sleeping cliient for inactivity after 10 minutes during the sleep
and let the client does reassociating when it wakes again. I just grep
for 'idleTime' in the 3.0 source and 10 minutes is exactly what it
does.
On Wed, Jun 10, 2009 at 10:19:06PM +0300, Kalle Valo wrote:
> "John W. Linville" <[email protected]> writes:
> > I'm still a bit "on the fence" regarding this requirement for AP mode.
> > I think there is a reasonable body of users that would prefer a
> > not-quite-right AP mode over no AP mode at all.
>
> I understand your point, but the problems from this are so severe that
> it would just create a headache for everyone, both for the users and for
> us. Think of what kind of problems randomly loosing broadcast and
> multicast frames would create: random disconnects, not finding hosts
> from the local network etc. How would a normal user realise that this is
> because of broken power save support in the AP?
I agree that it is a problem -- that is why I'm "on the fence"!
> Also deliberately breaking 802.11 specification sounds very wrong to me.
> We can, and should, aim higher than that.
> Sorry for not being diplomatic here, but hey, I'm a finn. We are born
> to be rude. Heritage from the viking era, I guess :)
(Note to the reader, this is an inside joke -- I threatened to run for
US President and then name Kalle as US Ambassador to the Vikings...have
you seen him? The vikings would be scared!)
Finn's aren't rude! Why Linus is the most diplomatic...hmmm...
nevermind... :-)
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, Jun 10, 2009 at 9:36 PM, Kalle Valo<[email protected]> wrote:
> Jouni Malinen <[email protected]> writes:
>
>>> Also deliberately breaking 802.11 specification sounds very wrong to me.
>>> We can, and should, aim higher than that.
>>
>> Well, breaking specifications may have to be done in some cases ;-), but
>> this particular feature is not really such a case.
>
> Yes, you are correct (as usual). The specification is not perfect, far
> from it :)
>
>> However, I do understand the desire to be able to use some kind of AP
>> mode even if it is known to be broken for some cases.
>
> Actually what are the reasons why an user would prefer AP mode over
> Ad-Hoc mode, if he doesn't care about power save? Better coverage
> between clients and better encryption, but that's it. Right?
>
> --
> Kalle Valo
>
There might be another reason - I'm not sure whether all versions of
Windows are capable of using an ad-hoc network for Internet connection
sharing. So, to bridge the connection from a Linux machine to a
Windows one, one might need to use AP mode.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Wed, Jun 10, 2009 at 3:39 PM, Hin-Tak Leung<[email protected]> wrote:
> On Wed, Jun 10, 2009 at 8:30 AM, Johannes Berg<[email protected]> wrote:
>> On Wed, 2009-06-10 at 04:18 +0100, Hin-Tak Leung wrote:
>>
>>> But I have been using vendor driver 3.0 for a few weeks in AP mode and
>>> I am as happy with it as I could be, I think; I have
>>> suspended//resumed clients. ?It works adequately.
>>
>> We're not concerned about suspend/hibernate, we're concerned about
>> 802.11 power saving, where the AP is required to buffer frames until the
>> clients wake up again. This will work adequately, but not perfectly, for
>> unicast frames, but we have not found a way of making zd1211 send
>> buffered multicast frames after the DTIM beacon as required.
>>
>> This means that your sleeping clients will not be receiving multicast,
>> and as such be invisible to the network once they fall off the ARP/NDP
>> caches. This is the reason we have said that it will not be possible to
>> support AP mode with this card. I'm curious how, if at all, the vendor
>> driver handles that.
>
> I was talking about the client suspending/resuming (i.e. the client
> disappearing).
>
> This is what appears in the AP machine's dmesg during the client's sleep:
> ---------------------------------------------------------
> *****Age one*****
> aid:1
> now:264313809
> ttl:264163665
> idleTime:150144
> zd1205_notify_disjoin_event
> Send Deasoc Req to 00:16:44:8f:71:93 RSN=4
> STA_DISASSOCIATED:00:16:44:8f:71:93
> Reject Auth Due to ar2524drv/src/zdpsmon.c,568. staSte=4
> Update BCN @ 286757537
> Re_Asoc: 00:16:44:8f:71:93, aid=1
> ------------------------------------------------------------
>
> It seems that the vendor driver on the AP machine simply diassociates
> a sleeping cliient for inactivity after 10 minutes during the sleep
> and let the client does reassociating when it wakes again. I just grep
> for 'idleTime' in the 3.0 source and 10 minutes is exactly what it
> does.
>
But again, that is not the problem that prevents proper AP mode; it's
802.11 dynamic power saving of the card, unrelated to
suspend/resume/powersave mode of the host.
(Note that I'm also for allowing such "buggy" AP mode on devices
without a HW multicast buffer, perhaps with hostapd spitting out a
big, fat warning on startup; but Johannes has the final say in
mac80211-related questions.)
(To Johannes: exactly why is it required for the multicast buffer to
be in hardware?)
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Thu, 2009-06-11 at 04:08 +0100, Hin-Tak Leung wrote:
> For the sake of being pedantic, can I have some reference (if only for
> those sleepless nights for lack of boring reading materials...)? Maybe
> I won't understand it anyway, but maybe somebody else who is
> listening in to this exchange can chip in.
> I have a 1300-page pdf supposedly the 802.11 2007 standard I
> downloaded some months ago through one of the wikipedia links, I think
> (somewhere under http://standards.ieee.org/) ... chapter 11 is MLME
> and section 11.2 is power management, which in turn is split into two
> sub-sections about power management in infrastructure nework and IBSS
> mode. I found a particular sentence in section 11.2.1. which sounds a
> bit like what you are saying (except with some cryptic acronyms!):
>
> ------
> If any STA in its BSS is in PSmode, the AP shall buffer all broadcast
> and multicast MSDUs and deliver them to all STAs immediately
> following the next Beacon frame containing a DTIM transmission.
> ------
>
> Have I found the right place to read up on such things, or there are
> other documents, etc (more detailed, or more "layman")?
Yes, that's the right place.
> On the broken-AP mode in the zd1211 vendor driver - presumably Zydas
> did not wrote that specially for linux, but just modified/adapted from
> their windows driver? So I guess windows users of zd1211 (or other USB
> sticks) are used to being able to do such things and assume whatever
> it does is normal? It just crossed my mind that if some off-spec
> behavior is sufficiently popular on windows (e.g. if
> connection-sharing requires AP mode to work and won't take IBSS),
> sometimes the spec gets modified to ratify a formerly barbaric
> off-spec behavior.
I don't think windows supports being an AP at all, afaict it's
connection sharing will create an IBSS.
johannes
On Thu, Jun 11, 2009 at 11:59 AM, Johannes
Berg<[email protected]> wrote:
> On Thu, 2009-06-11 at 04:08 +0100, Hin-Tak Leung wrote:
>
>> For the sake of being pedantic, can I have some reference (if only for
>> those sleepless nights for lack of boring reading materials...)? Maybe
>> ?I won't understand it anyway, but maybe somebody else who is
>> listening in to this exchange can chip in.
>> I have a 1300-page pdf supposedly the ?802.11 2007 standard I
>> downloaded some months ago through one of the wikipedia links, I think
>> (somewhere under http://standards.ieee.org/) ... chapter 11 is MLME
>> and section 11.2 is power management, which in turn is split into two
>> sub-sections about power management in infrastructure nework and IBSS
>> mode. I found a particular sentence in section 11.2.1. which sounds a
>> bit like what you are saying (except with some cryptic acronyms!):
>>
>> ------
>> If any STA in its BSS is in PSmode, the AP shall buffer all broadcast
>> and multicast MSDUs and deliver them to all STAs immediately
>> following the next Beacon frame containing a DTIM transmission.
>> ------
>>
>> Have I found the right place to read up on such things, or there are
>> other documents, etc (more detailed, or more "layman")?
>
> Yes, that's the right place.
>
>> On the broken-AP mode in the zd1211 vendor driver - presumably Zydas
>> did not wrote that specially for linux, but just modified/adapted from
>> their windows driver? So I guess windows users of zd1211 (or other USB
>> sticks) are used to being able to do such things and assume whatever
>> it does is normal? It just crossed my mind that if some off-spec
>> behavior is sufficiently popular on windows (e.g. if
>> connection-sharing requires AP mode to work and won't take IBSS),
>> sometimes the spec gets modified to ratify a formerly barbaric
>> off-spec behavior.
>
> I don't think windows supports being an AP at all, afaict it's
> connection sharing will create an IBSS.
>
> johannes
>
That's not what I meant (though Windows can operate in AP mode using
the utility provided for Zydas cards), but rather using the Linux
machine to give Internet connection to a Windows machine. AFAIK
Windows will never use an IBSS connection for Internet access
purposes, and only allows Internet through wireless if connected to an
AP.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Wed, Jun 10, 2009 at 10:28:25PM +0300, Jouni Malinen wrote:
> I don't like the idea of making hostapd warn the user somehow, but could
> probably live with something like AP mode being implemented in the
> driver, but disabled by default. Only if the user were to use a module
> parameter, say, broken_ap_mode=1, would the support for AP mode be
> registered. As long as distros do not start adding this parameter by
> default, this would force the user to become at least somehow informed
> about the issues and make a conscious choice in enabling the mode.
I would probably lean the other way -- let the driver expose the fact
that his AP mode is dysfunctional, and require hostap to say it is OK
to use it. Then again, it is the kind of thing that a user will say
"OK" and then go on to file bug reports about the problems created
by broken AP mode drivers...
Like I said, "on the fence"... :-)
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Wed, 2009-06-10 at 17:22 +0200, Gábor Stefanik wrote:
> On Wed, Jun 10, 2009 at 3:39 PM, Hin-Tak Leung<[email protected]> wrote:
> > I was talking about the client suspending/resuming (i.e. the client
> > disappearing).
Which isn't relevant for answering the question why there's no AP mode
in zd1211rw, regardless of whether it has problems or not.
> (Note that I'm also for allowing such "buggy" AP mode on devices
> without a HW multicast buffer, perhaps with hostapd spitting out a
> big, fat warning on startup; but Johannes has the final say in
> mac80211-related questions.)
>
> (To Johannes: exactly why is it required for the multicast buffer to
> be in hardware?)
It isn't required, ath5k/9k don't have it there, they have the notorious
"CAB" queue for sending frames directly after the beacon. So does b43,
and probably other designs. The problem really is that powersave mode is
very important for small clients like your mobile phone or digital
camera, or even bluetooth3 device, and not doing multicast buffering
correctly means that either those devices get into weird unreachable
states, or you need to turn off powersaving features on them which makes
the battery drain unbearable.
Now, it may or may not be possible to work around this in software by
sending out the multicast frames on a high-priority queue right after
the beacon, or something like that, but frankly I'm not interested in
working on zd1211rw myself, so that will have to be somebody who is (a)
familiar with 802.11 powersaving and multicast buffering, (b) wants
zd1211rw to work, and finally (c) has a lot of time to play with the
device.
johannes
On Wed, 2009-06-10 at 04:18 +0100, Hin-Tak Leung wrote:
> But I have been using vendor driver 3.0 for a few weeks in AP mode and
> I am as happy with it as I could be, I think; I have
> suspended//resumed clients. It works adequately.
We're not concerned about suspend/hibernate, we're concerned about
802.11 power saving, where the AP is required to buffer frames until the
clients wake up again. This will work adequately, but not perfectly, for
unicast frames, but we have not found a way of making zd1211 send
buffered multicast frames after the DTIM beacon as required.
This means that your sleeping clients will not be receiving multicast,
and as such be invisible to the network once they fall off the ARP/NDP
caches. This is the reason we have said that it will not be possible to
support AP mode with this card. I'm curious how, if at all, the vendor
driver handles that.
johannes
On Tue, Jun 9, 2009 at 1:59 AM, Hin-Tak Leung<[email protected]> wrote:
> On Mon, Jun 8, 2009 at 6:11 PM, Stefan
> Steuerwald<[email protected]> wrote:
>> Dear all,
>>
>> I have tried unsuccessfully to obtain any WLAN USB stick with a
>> chipset that supports AP mode.
>> This is for testing a mobile device that is supposed to work as an AP
>> with iPod/iPhone life forms.
>>
>> There only seem to be two choices: p54usb-based (preferred) and
>> rt2500-based devices. No luck in buying any of the listed devices
>> (they seem obsolete).
>> Turns out that anything current I can buy probably has RTL8187, RT73
>> or RT2800, and anything used I get from ebay is not what it seems
>> ("Netgear WG111 v2" can mean at least two different things I know of,
>> both unsuitable).
>>
>> Any pointers on
>> a) where to click-and-buy a stick that supports AP mode, or
>> b) whom to send money in exchange for a used stick are VERY much appreciated.
>
> At the risk of being yelled at, if you use the vendor driver (not the
> rw driver), Zydas zd1211 based USB stick can be made to work in AP
> mode. Caveats are (1) the vendor driver is known *not* to work on
> 64-bit host, and unlikely on anything but 32-bit intel linux, (2) you
> need a bunch of patches I posted earlier to build against current
> kernels. Search the archive.
> The zd1211 is quite popular for USB sticks.
This will cause problems for power-saving clients, as the ZD1211 chip
has no multicast buffering feature, something that must be done in
hardware even for softmac cards. (Possibly this can be worked around
in the firmware, but so far, no firmware source code has been released
for the ZD1211/AR2524, only for the ZD1221/AR9170.)
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Jon Fairbairn wrote:
> Stefan Steuerwald <[email protected]> writes:
>
>> Dear all,
>>
>> I have tried unsuccessfully to obtain any WLAN USB stick with a
>> chipset that supports AP mode.
>
> [...]
>
>> Turns out that anything current I can buy probably has RTL8187, RT73
>
> There's been recent work on getting rt73 to work as an AP.
> Search the list archive for the subject "rt73usb Access
> point status" and then "rt73usb: fix for master mode"
>
>
But There is still a communication problem when the wireless interface
is bridged with an Ethernet one.
Alexandre
On Wed, Jun 10, 2009 at 09:30:27AM +0200, Johannes Berg wrote:
> This means that your sleeping clients will not be receiving multicast,
> and as such be invisible to the network once they fall off the ARP/NDP
> caches. This is the reason we have said that it will not be possible to
> support AP mode with this card. I'm curious how, if at all, the vendor
> driver handles that.
My completely uninformed guess is that they ignore it. I will hazard
a guess that most scenarios involving "laptop as AP" are for support
of devices that don't (or at least didn't) do a lot of sleeping,
like other laptops.
I'm still a bit "on the fence" regarding this requirement for AP mode.
I think there is a reasonable body of users that would prefer a
not-quite-right AP mode over no AP mode at all.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
Stefan Steuerwald <salsasepp@...> writes:
> There only seem to be two choices: p54usb-based (preferred) and
> rt2500-based devices. No luck in buying any of the listed devices
> (they seem obsolete).
The Gigaset USB Adapter 54 is p54usb based. It was very popular in Germany,
there are more than a dozen listings at eBay.
Best regards,
Chi-Thanh Christopher Nguyen
2009/6/9 G?bor Stefanik <[email protected]>:
> This will cause problems for power-saving clients, as the ZD1211 chip
> has no multicast buffering feature, something that must be done in
> hardware even for softmac cards. (Possibly this can be worked around
> in the firmware, but so far, no firmware source code has been released
> for the ZD1211/AR2524, only for the ZD1221/AR9170.)
Can you elaborate a bit on that - e.g. reference to specific specs, or
dicussions archived elsewhere? This has been mentioned a few times - I
am just a bit curious. Granted that:
(1) Zydas zd1211 is cheap (I know how much I paid for it - I bought it
mostly for its price when I knew nothing about wireless devices and
their differences) and is expected to be minimal hardware-wise;
(2) having worked on the vendor driver, ported it forward to current
kernels and fixes a couple of old and new bugs on the way, the
quality/maintainability of the code isn't anywhere close to that of
any active open-source projects with more than say, 5 active
developers;
(3) there are still known bugs - it certainly does *not* work
correctly on 64-bit host, and not likely to work on non-[32-bit-intel]
hosts; and some of its 'if KERNEL_VERSION()' defines are plain
wrong...
But I have been using vendor driver 3.0 for a few weeks in AP mode and
I am as happy with it as I could be, I think; I have
suspended//resumed clients. It works adequately. I'd like the rw
driver to support AP mode eventually (although I have been told in no
uncertain terms it is not going to happen; maybe only firmware
change). Just for curiosity I might have a crack at the 64-bit host
problem, but I'd like not to spend more effort on the vendor driver.
Stefan Steuerwald <[email protected]> writes:
> Dear all,
>
> I have tried unsuccessfully to obtain any WLAN USB stick with a
> chipset that supports AP mode.
[...]
> Turns out that anything current I can buy probably has RTL8187, RT73
There's been recent work on getting rt73 to work as an AP.
Search the list archive for the subject "rt73usb Access
point status" and then "rt73usb: fix for master mode"
--
Jón Fairbairn [email protected]
On Mon, Jun 8, 2009 at 6:11 PM, Stefan
Steuerwald<[email protected]> wrote:
> Dear all,
>
> I have tried unsuccessfully to obtain any WLAN USB stick with a
> chipset that supports AP mode.
> This is for testing a mobile device that is supposed to work as an AP
> with iPod/iPhone life forms.
>
> There only seem to be two choices: p54usb-based (preferred) and
> rt2500-based devices. No luck in buying any of the listed devices
> (they seem obsolete).
> Turns out that anything current I can buy probably has RTL8187, RT73
> or RT2800, and anything used I get from ebay is not what it seems
> ("Netgear WG111 v2" can mean at least two different things I know of,
> both unsuitable).
>
> Any pointers on
> a) where to click-and-buy a stick that supports AP mode, or
> b) whom to send money in exchange for a used stick are VERY much appreciated.
At the risk of being yelled at, if you use the vendor driver (not the
rw driver), Zydas zd1211 based USB stick can be made to work in AP
mode. Caveats are (1) the vendor driver is known *not* to work on
64-bit host, and unlikely on anything but 32-bit intel linux, (2) you
need a bunch of patches I posted earlier to build against current
kernels. Search the archive.
The zd1211 is quite popular for USB sticks.
On Wed, Jun 10, 2009 at 8:08 PM, Hin-Tak Leung<[email protected]> wrote:
> 2009/6/10 Johannes Berg <[email protected]>:
>
>> Now, it may or may not be possible to work around this in software by
>> sending out the multicast frames on a high-priority queue right after
>> the beacon, or something like that, but frankly I'm not interested in
>> working on zd1211rw myself, so that will have to be somebody who is (a)
>> familiar with 802.11 powersaving and multicast buffering, (b) wants
>> zd1211rw to work, and finally (c) has a lot of time to play with the
>> device.
>
> For the sake of being pedantic, can I have some reference (if only for
> those sleepless nights for lack of boring reading materials...)? Maybe
> I won't understand it anyway, but maybe somebody else who is
> listening in to this exchange can chip in.
> I have a 1300-page pdf supposedly the 802.11 2007 standard I
> downloaded some months ago through one of the wikipedia links, I think
> (somewhere under http://standards.ieee.org/) ... chapter 11 is MLME
> and section 11.2 is power management, which in turn is split into two
> sub-sections about power management in infrastructure nework and IBSS
> mode. I found a particular sentence in section 11.2.1. which sounds a
> bit like what you are saying (except with some cryptic acronyms!):
>
> ------
> If any STA in its BSS is in PSmode, the AP shall buffer all broadcast
> and multicast MSDUs and deliver them to all STAs immediately
> following the next Beacon frame containing a DTIM transmission.
> ------
>
> Have I found the right place to read up on such things, or there are
> other documents, etc (more detailed, or more "layman")?
This might be helpful:
http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings
Luis
"John W. Linville" <[email protected]> writes:
> On Wed, Jun 10, 2009 at 09:30:27AM +0200, Johannes Berg wrote:
>
>> This means that your sleeping clients will not be receiving multicast,
>> and as such be invisible to the network once they fall off the ARP/NDP
>> caches. This is the reason we have said that it will not be possible to
>> support AP mode with this card. I'm curious how, if at all, the vendor
>> driver handles that.
>
> My completely uninformed guess is that they ignore it.
That's my guess as well.
> I will hazard a guess that most scenarios involving "laptop as AP" are
> for support of devices that don't (or at least didn't) do a lot of
> sleeping, like other laptops.
>
> I'm still a bit "on the fence" regarding this requirement for AP mode.
> I think there is a reasonable body of users that would prefer a
> not-quite-right AP mode over no AP mode at all.
I understand your point, but the problems from this are so severe that
it would just create a headache for everyone, both for the users and for
us. Think of what kind of problems randomly loosing broadcast and
multicast frames would create: random disconnects, not finding hosts
from the local network etc. How would a normal user realise that this is
because of broken power save support in the AP?
Also deliberately breaking 802.11 specification sounds very wrong to me.
We can, and should, aim higher than that.
Sorry for not being diplomatic here, but hey, I'm a finn. We are born
to be rude. Heritage from the viking era, I guess :)
--
Kalle Valo