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:
signature.asc
Description: OpenPGP digital signature
