Hi,
the ar9170 is not advertising its AP feature. However, hacking in the
bit allows me to run an AP on my D-Link DWA 160A with the sources of
yesterday's wireless-testing. Works mostly fine so far, just device
startup (firmware loading?) is sometimes a bit fragile, and rate control
seems to jump more than needed when the connection gets worse.
There was some telling the multicast transmission would not work, but I
just tested it and cannot confirm this. Did something change or does a
specific multicast scenario still fail? Otherwise I would like to see AP
mode enabled in the ar9170 so that it works without modifying kernel
sources. Would post a patch then.
Jan
On Mon, 2009-11-09 at 22:09 +0100, Jan Kiszka wrote:
> Could someone briefly explain how the firmware is supposed to handle
> this case? By scanning outgoing frames for multicast addresses? Should
> the DTIM condition be detected and reported (via beacon) only by the
> firmware, or would the driver be involved to some degree? If we handle
> this transparently in the firmware, I guess that it would have to buffer
> not only a single multicast frame, right? Do we have enough memory for
> this on the chip?
The driver is always involved in some way, cf.
IEEE80211_TX_CTL_SEND_AFTER_DTIM and
IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING in mac80211.h
As to what the right thing with ar9170 is -- I don't know. Maybe the
firmware could buffer a few frames, and the driver can push the
remaining frames down once the device tells it the beacon was sent. Or
maybe it's OK, although not perfect, if we simply send the frames once
the device says the beacon was sent... I've never understood how the QoS
implementation in this thing works, and that's kinda related.
johannes
Holger Schurig <[email protected]> writes:
>> How common is the combination of powersaving and mcast in practice?
>> 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.
>
> In my case (hand-help devices) it's very common. Without power-save,
> the battery would be drained so fast it wouldn't be usable.
Yes, just to give a concrete example of n810 wlan idle case
(associated, but no data transfered):
ps off 7 hours
ps on 7 days
Huge difference.
> And with power-save and an AP that can't handle this, you'd get
> weird errors.
Exactly. These kinds of errors are very difficult for the users to
understand.
> So, I personally prefer to have "Do an AP right" or "Don't do it at
> all". But please no general enablement.
>
> But, for example, having some CONFIG_AR9K_AP_MODE depending on
> CONFIG_EXPERIMENTAL and a bit fat warning would do for me. Hopefully
> this would scara away distros, so that they don't turn this on for
> there standard kernel :-)
I think EXPERIMENTAL is not enough, I would prefer that the user needs
to patch the driver to enable it. Or if that's not good enough, then
maybe depend on BROKEN.
--
Kalle Valo
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.
> 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.
johannes
On Mon, Nov 09, 2009 at 10:37:36AM +0200, Kalle Valo wrote:
> Holger Schurig <[email protected]> writes:
> > So, I personally prefer to have "Do an AP right" or "Don't do it at
> > all". But please no general enablement.
> >
> > But, for example, having some CONFIG_AR9K_AP_MODE depending on
> > CONFIG_EXPERIMENTAL and a bit fat warning would do for me. Hopefully
> > this would scara away distros, so that they don't turn this on for
> > there standard kernel :-)
>
> I think EXPERIMENTAL is not enough, I would prefer that the user needs
> to patch the driver to enable it. Or if that's not good enough, then
> maybe depend on BROKEN.
Here we go again... :-)
So I definitely agree that it should be off by default. I also agree
that it should be difficult to turn it on accidentally. We don't
need any extra wierd bug reports.
OTOH, I think we can all acknowledge that many people have reasonable
use cases with their fleet of equipment. I wonder if a sysctl would
be enough of a deterrent? They are fairly simple to turn-on, but
you do have to know about them to do so...
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Mon, Nov 9, 2009 at 10:52 AM, Jeffrey Baker <[email protected]> wrote:
> On Mon, Nov 9, 2009 at 12:37 AM, Kalle Valo <[email protected]> wrote:
>> Holger Schurig <[email protected]> writes:
>>
>>>> How common is the combination of powersaving and mcast in practice?
>>>> 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.
>>>
>>> In my case (hand-help devices) it's very common. Without power-save,
>>> the battery would be drained so fast it wouldn't be usable.
>>
>> Yes, just to give a concrete example of n810 wlan idle case
>> (associated, but no data transfered):
>>
>> ps off 7 hours
>> ps on 7 days
>>
>> Huge difference.
>>
>>> And with power-save and an AP that can't handle this, you'd get
>>> weird errors.
>>
>> Exactly. These kinds of errors are very difficult for the users to
>> understand.
>>
>>> So, I personally prefer to have "Do an AP right" or "Don't do it at
>>> all". But please no general enablement.
>>>
>>> But, for example, having some CONFIG_AR9K_AP_MODE depending on
>>> CONFIG_EXPERIMENTAL and a bit fat warning would do for me. Hopefully
>>> this would scara away distros, so that they don't turn this on for
>>> there standard kernel :-)
>>
>> I think EXPERIMENTAL is not enough, I would prefer that the user needs
>> to patch the driver to enable it. Or if that's not good enough, then
>> maybe depend on BROKEN.
>
> Is this broken on all ar9k or just the 9170?
Just ar9170.
Luis
On Sun, 2009-11-08 at 15:40 +0100, Jan Kiszka wrote:
> OK, confirmed with my cellphone: If I enable powersaving, it actually
> has troubles replying on arp requests.
Thing is that it just won't see the request.
> 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.
Heh. Well most people don't know how to turn off PS on their cellphone,
and shouldn't have to either.
> 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?
No. PS client support is a feature that the standard requires from an
AP.
> 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?
We just need to find a way to buffer multicast frames until after DTIM.
Given that we have the firmware sourcecode, it should be doable.
johannes
Kalle Valo wrote:
> Jan Kiszka <[email protected]> writes:
>
>> the ar9170 is not advertising its AP feature. However, hacking in the
>> bit allows me to run an AP on my D-Link DWA 160A with the sources of
>> yesterday's wireless-testing. Works mostly fine so far, just device
>> startup (firmware loading?) is sometimes a bit fragile, and rate control
>> seems to jump more than needed when the connection gets worse.
>>
>> There was some telling the multicast transmission would not work, but I
>> just tested it and cannot confirm this. Did something change or does a
>> specific multicast scenario still fail? Otherwise I would like to see AP
>> mode enabled in the ar9170 so that it works without modifying kernel
>> sources. Would post a patch then.
>
> Did you test with a client which had power save mode enabled? That's
> the tricky part.
Probably not, ath5k on my notebook doesn't support it. Now looking for
some station that does.
>
> IMHO AP mode should not be enabled until it's confirmed that power
> save mode works properly.
How common is the combination of powersaving and mcast in practice?
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.
Jan
> How common is the combination of powersaving and mcast in practice?
> 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.
In my case (hand-help devices) it's very common. Without power-save,
the battery would be drained so fast it wouldn't be usable. And with
power-save and an AP that can't handle this, you'd get weird errors.
So, I personally prefer to have "Do an AP right" or "Don't do it at
all". But please no general enablement.
But, for example, having some CONFIG_AR9K_AP_MODE depending on
CONFIG_EXPERIMENTAL and a bit fat warning would do for me. Hopefully
this would scara away distros, so that they don't turn this on for
there standard kernel :-)
--
http://www.holgerschurig.de
John W. Linville wrote:
> On Mon, Nov 09, 2009 at 10:37:36AM +0200, Kalle Valo wrote:
>> Holger Schurig <[email protected]> writes:
>
>>> So, I personally prefer to have "Do an AP right" or "Don't do it at
>>> all". But please no general enablement.
>>>
>>> But, for example, having some CONFIG_AR9K_AP_MODE depending on
>>> CONFIG_EXPERIMENTAL and a bit fat warning would do for me. Hopefully
>>> this would scara away distros, so that they don't turn this on for
>>> there standard kernel :-)
>> I think EXPERIMENTAL is not enough, I would prefer that the user needs
>> to patch the driver to enable it. Or if that's not good enough, then
>> maybe depend on BROKEN.
>
> Here we go again... :-)
>
> So I definitely agree that it should be off by default. I also agree
> that it should be difficult to turn it on accidentally. We don't
> need any extra wierd bug reports.
>
> OTOH, I think we can all acknowledge that many people have reasonable
> use cases with their fleet of equipment. I wonder if a sysctl would
> be enough of a deterrent? They are fairly simple to turn-on, but
> you do have to know about them to do so...
/me would be happy about such thing as a short-term workaround if a true
fix is more complicated. So far I'm lacking a feeling for the complexity
- low-level 802.11 is unexplored terrain for me.
Could someone briefly explain how the firmware is supposed to handle
this case? By scanning outgoing frames for multicast addresses? Should
the DTIM condition be detected and reported (via beacon) only by the
firmware, or would the driver be involved to some degree? If we handle
this transparently in the firmware, I guess that it would have to buffer
not only a single multicast frame, right? Do we have enough memory for
this on the chip?
Jan
On Mon, Nov 9, 2009 at 12:37 AM, Kalle Valo <[email protected]> wrote:
> Holger Schurig <[email protected]> writes:
>
>>> How common is the combination of powersaving and mcast in practice?
>>> 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.
>>
>> In my case (hand-help devices) it's very common. Without power-save,
>> the battery would be drained so fast it wouldn't be usable.
>
> Yes, just to give a concrete example of n810 wlan idle case
> (associated, but no data transfered):
>
> ps off ?7 hours
> ps on ? 7 days
>
> Huge difference.
>
>> And with power-save and an AP that can't handle this, you'd get
>> weird errors.
>
> Exactly. These kinds of errors are very difficult for the users to
> understand.
>
>> So, I personally prefer to have "Do an AP right" or "Don't do it at
>> all". But please no general enablement.
>>
>> But, for example, having some CONFIG_AR9K_AP_MODE depending on
>> CONFIG_EXPERIMENTAL and a bit fat warning would do for me. Hopefully
>> this would scara away distros, so that they don't turn this on for
>> there standard kernel :-)
>
> I think EXPERIMENTAL is not enough, I would prefer that the user needs
> to patch the driver to enable it. Or if that's not good enough, then
> maybe depend on BROKEN.
Is this broken on all ar9k or just the 9170?
-jwb
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
Jan Kiszka <[email protected]> writes:
> the ar9170 is not advertising its AP feature. However, hacking in the
> bit allows me to run an AP on my D-Link DWA 160A with the sources of
> yesterday's wireless-testing. Works mostly fine so far, just device
> startup (firmware loading?) is sometimes a bit fragile, and rate control
> seems to jump more than needed when the connection gets worse.
>
> There was some telling the multicast transmission would not work, but I
> just tested it and cannot confirm this. Did something change or does a
> specific multicast scenario still fail? Otherwise I would like to see AP
> mode enabled in the ar9170 so that it works without modifying kernel
> sources. Would post a patch then.
Did you test with a client which had power save mode enabled? That's
the tricky part.
IMHO AP mode should not be enabled until it's confirmed that power
save mode works properly.
--
Kalle Valo