ar9170 in AP mode
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
Quoted 11 lines · Jan Kiszka
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.
Signature · 1 line
Kalle Valo
Quoted 8 lines · Kalle Valo
Quoted 6 lines · Jan Kiszka
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 3 lines
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
Quoted 2 lines · Jan Kiszka
Quoted 2 lines
IMHO AP mode should not be enabled until it's confirmed that power save mode works properly.
Agreed.
Quoted 1 line
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.
Quoted 4 lines
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
Quoted 7 lines · Johannes Berg
Quoted 2 lines · Jan Kiszka
Quoted 2 lines
IMHO AP mode should not be enabled until it's confirmed that power save mode works properly.
Agreed.
Quoted 8 lines
Quoted 1 line
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.
Quoted 9 lines
Quoted 5 lines
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
Quoted 2 lines · Jan Kiszka
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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 5 lines
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 :-)
Quoted 8 lines · Holger Schurig
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
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_MODEdepending onCONFIG_EXPERIMENTALand 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.
Signature · 1 line
Kalle Valo
Quoted 5 lines · Kalle Valo
Quoted 3 lines · Holger Schurig
So, I personally prefer to have "Do an AP right" or "Don't do it at all". But please no general enablement.
Quoted 8 lines
Quoted 4 lines
But, for example, having some
CONFIG_AR9K_AP_MODEdepending onCONFIG_EXPERIMENTALand 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
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 16 lines · John W. Linville
Quoted 5 lines · Kalle Valo
Quoted 3 lines · Holger Schurig
So, I personally prefer to have "Do an AP right" or "Don't do it at all". But please no general enablement.
Quoted 7 lines
Quoted 4 lines
But, for example, having some
CONFIG_AR9K_AP_MODEdepending onCONFIG_EXPERIMENTALand 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... :-)
Quoted 8 lines
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
Quoted 7 lines · Jan Kiszka
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
Quoted 28 lines · Kalle Valo
Quoted 8 lines · Holger Schurig
Quoted 5 lines
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 daysHuge difference.
Quoted 2 lines
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.
Quoted 3 lines
So, I personally prefer to have "Do an AP right" or "Don't do it at all". But please no general enablement.
Quoted 8 lines
Quoted 4 lines
But, for example, having some
CONFIG_AR9K_AP_MODEdepending onCONFIG_EXPERIMENTALand 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
Quoted 34 lines · Jeffrey Baker
Quoted 33 lines · Kalle Valo
Quoted 8 lines · Holger Schurig
Quoted 5 lines
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 daysHuge difference.
Quoted 2 lines
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.
Quoted 7 lines
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_MODEdepending onCONFIG_EXPERIMENTALand 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 :-)
Quoted 5 lines
Quoted 3 lines
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