Re: ar9170 in AP mode

[Jan Kiszka <jan.kiszka@web.de>]

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

Johannes Berg wrote:
> On Sun, 2009-11-08 at 14:47 +0100, Jan Kiszka wrote:
> 
>>> IMHO AP mode should not be enabled until it's confirmed that power
>>> save mode works properly.
> 
> Agreed.
> 
>> How common is the combination of powersaving and mcast in practice?
> 
> Uh, it's nothing to do with the combination. If you don't support proper
> mcast buffering, any powersaving client will be in big trouble due to
> ARP/NDP etc.
> 
> Any device that supports powersaving is thus impacted. That ranges from
> desktops and laptops down to your cellphone.

OK, confirmed with my cellphone: If I enable powersaving, it actually
has troubles replying on arp requests.

I kept it disabled as my previous AP setup (rt2500usb on a special
2.6.21 kernel) used to fail with powersaving as well. So the good news
is that one can perfectly run with such a setup for multiple years, and
I will continue to do so with ar9170 for now - but I also see your point.

> 
>> Given that quite a few useful scenarios are blocked right now (unless
>> you know what to patch), I would at least vote for a config option or a
>> module parameter. That gives a chance to warn the user about this
>> limitation without locking out people that are no hackers.
> 
> Given that we want to have everything support powersave on the client
> side, I have to disagree -- supporting something that will be
> troublesome for many clients will just make it look bad.

OK, carrying that patch locally will not kill me. Hmm, is there a way in
the 802.11 to tell a client to not apply powersaving in this cell - just
in case?

And what can be done to resolve this issue for real? Does the legacy
otus driver work fine in this regard? Or are we lacking more information
about the hardware?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]