Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
Pavel Roskin wrote: On Sat, 2010-01-30 at 00:34 +0100, Felix Fietkau wrote: Please try this patch and see if it helps. Yes, it worked perfectly!!! Confirm it also solves the problem on my 168c:0023 AR5008, AR5416+AR5133. //Peter ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Tue, 2010-02-02 at 16:08 -0800, Luis Rodriguez wrote: We have reviewed this. The 64 value came from interoperability tests against another 802.11n device which had increased delayed BlockAcks when CTS-to-self was enabled. Although this is a higher value than what the standard says to use we recommend to just leave the value as-is and actually use the values from the initvals as the minimum possible value as those are the values that have been used for a large array of tests, including WMM interop tests. We cannot gaurantee proper functionality against other devices otherwise. Is someone still looking into more details? The current wireless-testing.git state is completely unacceptable and as a quick fix, I can think of two options: 1) revert the patches that introduced the regression (clean up of ACK timeout setting and the new coverage class support (since it depends on the previous one)) or 2) add new code to enforce that the ACK timeout (and CTS timeout, too, I would assume) get set to at least the value from the initvals (i.e., never use smaller values than before). The latter option would mean that the new coverage class support would start kicking in only when the configuration indicates need for longer timeouts than the default values. I don't care too much how this is resolved in short term, but I think that one of the options described above really needs to happen quickly; ath9k in wireless-testing.git has already been more or less completely broken for couple of weeks (at least with some hardware/configuration combinations). Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue The current snapshot is very much broken with my AR9280 (at least on 2.4 GHz band) when using AP mode (the assoc resp frame is not reported as ACK'ed). I haven't really looked into the details (and don't really like to do that either ;-), but the part that broke this was the cleanup patch for ACK timeout/slottime setting. It changed the default AR_TIME_OUT value from 0x08400b00 to 0x03440344 (latter half being the ACK timeout) and reverting that makes the AP work again. - Jouni ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
Jouni Malinen wrote: Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue The current snapshot is very much broken with my AR9280 (at least on 2.4 GHz band) when using AP mode (the assoc resp frame is not reported as ACK'ed). I confirm getting the same behavior on my AR5416+AR5133. Output from hostapd-0.7.1: eth1: STA xx IEEE 802.11: authentication OK (open system) eth1: STA xx MLME: MLME-AUTHENTICATE.indication(xx, OPEN_SYSTEM) eth1: STA xx MLME: MLME-DELETEKEYS.request(xx) eth1: STA xx IEEE 802.11: association OK (aid 1) eth1: STA xx IEEE 802.11: did not acknowledge authentication response eth1: STA xx IEEE 802.11: did not acknowledge association response unknown mgmt cb frame subtype 10 unknown mgmt cb frame subtype 10 ..over and over. Occasionally the station will connect though. the part that broke this was the cleanup patch for ACK timeout/slottime setting. Which commit id is that? //Peter ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Sat, Jan 30, 2010 at 12:46:51PM -0800, Felix Fietkau wrote: On 2010-01-30 9:37 PM, Pavel Roskin wrote: On Sat, 2010-01-30 at 21:10 +0100, Felix Fietkau wrote: The workaround value of '64' is actually wrong. When I had trouble associating in 2.4 GHz in a case where the slot time was actually set correctly, I simply used it, because that's what was being set in the initvals. We shouldn't base the slot time on this though - the initvals don't do this either. I could reduce the minimal value of acktimeout from 64 to 20. With 20, I get a reliable communication every time. With 19, it's doesn't work ever. The distance between STA and AP is about 1 meter. The slottime == -1 thing is obviously a bug, and I'll send a patch to fix it later. It turns out that simply increasing the initial value to 54 is not enough, as ah-slottime will be set to 9 from sc-beacon.slottime, so acktimeout becomes 19. That's why my patch forces it to a minimum of 64 just before it gets set. But using the value of 10 instead of 9 for sc-beacon.slottime does the trick. That's the minimal patch that works for me. Perhaps we should be using ATH9K_SLOT_TIME_9 there (see mac.h) and define it to 10. That value would still be wrong, though. According to the 802.11 docs, the slot time for 2.4 GHz has to be set to 9 usec, not 10. If this is a bug in the hardware, we need to know about the implications before we pick a value that just happened to work in our tests, but may not work in all cases. slottime=9, acktimeout=64 is what the initvals use, so that's tested by Atheros. If we continue to receive no comments from Atheros on this issue, we should probably use those values by default. By the way, 5 GHz seems to be unaffected by this issue, which makes this a little suspicious. I've Cc'd Luis, maybe he can forward this to the right people. We have reviewed this. The 64 value came from interoperability tests against another 802.11n device which had increased delayed BlockAcks when CTS-to-self was enabled. Although this is a higher value than what the standard says to use we recommend to just leave the value as-is and actually use the values from the initvals as the minimum possible value as those are the values that have been used for a large array of tests, including WMM interop tests. We cannot gaurantee proper functionality against other devices otherwise. Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue and the only way to zero in on the issue would be by getting full register dumps to ensure every other register related to ACK Timeout is programmed properly (AR_USEC_USEC I think is one) and taking it from there. Testing different values are welcomed but upstream we should just use what we have tested with until we do WMM interop tests with different values and not sure if we'll be doing that for a while. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote: We have reviewed this. The 64 value came from interoperability tests against another 802.11n device which had increased delayed BlockAcks when CTS-to-self was enabled. Although this is a higher value than what the standard says to use we recommend to just leave the value as-is and actually use the values from the initvals as the minimum possible value as those are the values that have been used for a large array of tests, including WMM interop tests. We cannot gaurantee proper functionality against other devices otherwise. Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue and the only way to zero in on the issue would be by getting full register dumps to ensure every other register related to ACK Timeout is programmed properly (AR_USEC_USEC I think is one) and taking it from there. Testing different values are welcomed but upstream we should just use what we have tested with until we do WMM interop tests with different values and not sure if we'll be doing that for a while. So how should we handle ACK timeout for different coverage class values? That's my primary concern, since I wrote the patch to support that. Should I just send a patch that adds an offset of 45? (= 64us - 19us, based on the diff between calculated and initval) - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau n...@openwrt.org wrote: On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote: We have reviewed this. The 64 value came from interoperability tests against another 802.11n device which had increased delayed BlockAcks when CTS-to-self was enabled. Although this is a higher value than what the standard says to use we recommend to just leave the value as-is and actually use the values from the initvals as the minimum possible value as those are the values that have been used for a large array of tests, including WMM interop tests. We cannot gaurantee proper functionality against other devices otherwise. Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue and the only way to zero in on the issue would be by getting full register dumps to ensure every other register related to ACK Timeout is programmed properly (AR_USEC_USEC I think is one) and taking it from there. Testing different values are welcomed but upstream we should just use what we have tested with until we do WMM interop tests with different values and not sure if we'll be doing that for a while. So how should we handle ACK timeout for different coverage class values? That's my primary concern, since I wrote the patch to support that. Should I just send a patch that adds an offset of 45? (= 64us - 19us, based on the diff between calculated and initval) Well so what I meant is that we should ensure hardware is not programmed with an ACK/CTS Timeout value lower than what is on the initvals already. If changing the coverage class means a different ACK timeout is produced we just take the max of the two values. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote: On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau n...@openwrt.org wrote: On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote: We have reviewed this. The 64 value came from interoperability tests against another 802.11n device which had increased delayed BlockAcks when CTS-to-self was enabled. Although this is a higher value than what the standard says to use we recommend to just leave the value as-is and actually use the values from the initvals as the minimum possible value as those are the values that have been used for a large array of tests, including WMM interop tests. We cannot gaurantee proper functionality against other devices otherwise. Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue and the only way to zero in on the issue would be by getting full register dumps to ensure every other register related to ACK Timeout is programmed properly (AR_USEC_USEC I think is one) and taking it from there. Testing different values are welcomed but upstream we should just use what we have tested with until we do WMM interop tests with different values and not sure if we'll be doing that for a while. So how should we handle ACK timeout for different coverage class values? That's my primary concern, since I wrote the patch to support that. Should I just send a patch that adds an offset of 45? (= 64us - 19us, based on the diff between calculated and initval) Well so what I meant is that we should ensure hardware is not programmed with an ACK/CTS Timeout value lower than what is on the initvals already. If changing the coverage class means a different ACK timeout is produced we just take the max of the two values. Taking the max doesn't make any sense to me if this is about working around delay in the transmission of BlockAcks. Since the coverage class is meant to compensate delay in the air propagation time, the ACK timeout should increase along with it, because along with increasing distance, the worst case delay of the BA of a distant node will get higher as well. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau n...@openwrt.org wrote: On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote: On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau n...@openwrt.org wrote: On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote: We have reviewed this. The 64 value came from interoperability tests against another 802.11n device which had increased delayed BlockAcks when CTS-to-self was enabled. Although this is a higher value than what the standard says to use we recommend to just leave the value as-is and actually use the values from the initvals as the minimum possible value as those are the values that have been used for a large array of tests, including WMM interop tests. We cannot gaurantee proper functionality against other devices otherwise. Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue and the only way to zero in on the issue would be by getting full register dumps to ensure every other register related to ACK Timeout is programmed properly (AR_USEC_USEC I think is one) and taking it from there. Testing different values are welcomed but upstream we should just use what we have tested with until we do WMM interop tests with different values and not sure if we'll be doing that for a while. So how should we handle ACK timeout for different coverage class values? That's my primary concern, since I wrote the patch to support that. Should I just send a patch that adds an offset of 45? (= 64us - 19us, based on the diff between calculated and initval) Well so what I meant is that we should ensure hardware is not programmed with an ACK/CTS Timeout value lower than what is on the initvals already. If changing the coverage class means a different ACK timeout is produced we just take the max of the two values. Taking the max doesn't make any sense to me if this is about working around delay in the transmission of BlockAcks. Since the coverage class is meant to compensate delay in the air propagation time, the ACK timeout should increase along with it, because along with increasing distance, the worst case delay of the BA of a distant node will get higher as well. Well so increased delays would mean you would do premature retries if the ACK timeout is not high enough. If you increase the ACK timeout it means hardware would wait longer for the frame and the default value we have used so far has been programmed on the initvals. So if the ACK timeout is going to be modified to support coverage class support, I take it we are only possibly increasing the ACK timeout and never decreasing it. Please let me know if I am missing something here. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Tue, 2010-02-02 at 16:45 -0800, Luis R. Rodriguez wrote: On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau n...@openwrt.org wrote: On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote: Well so what I meant is that we should ensure hardware is not programmed with an ACK/CTS Timeout value lower than what is on the initvals already. If changing the coverage class means a different ACK timeout is produced we just take the max of the two values. Taking the max doesn't make any sense to me if this is about working around delay in the transmission of BlockAcks. Since the coverage class is meant to compensate delay in the air propagation time, the ACK timeout should increase along with it, because along with increasing distance, the worst case delay of the BA of a distant node will get higher as well. Well so increased delays would mean you would do premature retries if the ACK timeout is not high enough. If you increase the ACK timeout it means hardware would wait longer for the frame and the default value we have used so far has been programmed on the initvals. So if the ACK timeout is going to be modified to support coverage class support, I take it we are only possibly increasing the ACK timeout and never decreasing it. Please let me know if I am missing something here. As I understand, nobody proposes to decrease the ACK timeout. The only question is how it should be increased. Should we use maximum or addition? And that depends on the reasons for having the lower limit for ACK timeout. If the limit is needed to guard against hardware limitations, then we want maximum. It means that the timeout is implemented accurately in the hardware, it just cannot be too low. If the limit is needed to compensate for whatever processing delays, then we want addition. Those delays won't overlap with air propagation. The delay time would be added to the air propagation time. It would mean adding a constant fudge factor to the ACK timeout to make it accurate. I've attached a simple picture to make it more clear. -- Regards, Pavel Roskin attachment: acktimeout.png___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
Luis Rodriguez wrote: Since the issues so far are obaserved on AR9160 and AR9220 (and not AR9280) and AR9271 (sujith) this might be a bus issue and the only way to zero in on the issue would be by getting full register dumps to ensure every other register related to ACK Timeout is programmed properly (AR_USEC_USEC I think is one) and taking it from there. Testing different values are welcomed but upstream we should just use what we have tested with until we do WMM interop tests with different values and not sure if we'll be doing that for a while. Yep, AR9271 doesn't associate at all if the values in the Init arrays are not used. I have not tested with other chipsets. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Sat, 2010-01-30 at 00:34 +0100, Felix Fietkau wrote: Please try this patch and see if it helps. Yes, it worked perfectly!!! I added some debug printks, and it turns out that ah-slottime is negative. The card is Ubiquiti SR71-12, 2 GHz only. phy1: Atheros AR9280 Rev:2 mem=0xc900107c, irq=19 mac80211: debugfs: failed to rename debugfs dir to netdev:wlan0 udev: renamed network interface wlan0 to wlan13 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c2520, conf-channel-band = 0 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c2520, conf-channel-band = 0 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c2520, conf-channel-band = 0 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c25d4, conf-channel-band = 0 ah-slottime = 9, ah-coverage_class = 0, sifstime = 10 acktimeout = 19, conf-channel = a01c25d4, conf-channel-band = 0 phy1: Allocated STA 00:19:e3:05:25:10 phy1: Inserted STA 00:19:e3:05:25:10 I see that ah-slottime is initialized to -1 in ath9k_hw_init_defaults(). Maybe we want a number that is large, but doesn't overflow? Or we could start with 54, which would give 64 in the first iteration. -- Regards, Pavel Roskin ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On 2010-01-30 8:39 PM, Pavel Roskin wrote: On Sat, 2010-01-30 at 00:34 +0100, Felix Fietkau wrote: Please try this patch and see if it helps. Yes, it worked perfectly!!! I added some debug printks, and it turns out that ah-slottime is negative. The card is Ubiquiti SR71-12, 2 GHz only. phy1: Atheros AR9280 Rev:2 mem=0xc900107c, irq=19 mac80211: debugfs: failed to rename debugfs dir to netdev:wlan0 udev: renamed network interface wlan0 to wlan13 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c2520, conf-channel-band = 0 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c2520, conf-channel-band = 0 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c2520, conf-channel-band = 0 ah-slottime = -1, ah-coverage_class = 0, sifstime = 10 acktimeout = 9, conf-channel = a01c25d4, conf-channel-band = 0 ah-slottime = 9, ah-coverage_class = 0, sifstime = 10 acktimeout = 19, conf-channel = a01c25d4, conf-channel-band = 0 phy1: Allocated STA 00:19:e3:05:25:10 phy1: Inserted STA 00:19:e3:05:25:10 I see that ah-slottime is initialized to -1 in ath9k_hw_init_defaults(). Maybe we want a number that is large, but doesn't overflow? Or we could start with 54, which would give 64 in the first iteration. The workaround value of '64' is actually wrong. When I had trouble associating in 2.4 GHz in a case where the slot time was actually set correctly, I simply used it, because that's what was being set in the initvals. We shouldn't base the slot time on this though - the initvals don't do this either. The slottime == -1 thing is obviously a bug, and I'll send a patch to fix it later. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Sat, 2010-01-30 at 21:10 +0100, Felix Fietkau wrote:
The workaround value of '64' is actually wrong. When I had trouble
associating in 2.4 GHz in a case where the slot time was actually set
correctly, I simply used it, because that's what was being set in the
initvals. We shouldn't base the slot time on this though - the initvals
don't do this either.
I could reduce the minimal value of acktimeout from 64 to 20. With 20,
I get a reliable communication every time. With 19, it's doesn't work
ever. The distance between STA and AP is about 1 meter.
The slottime == -1 thing is obviously a bug, and I'll send a patch to
fix it later.
It turns out that simply increasing the initial value to 54 is not
enough, as ah-slottime will be set to 9 from sc-beacon.slottime, so
acktimeout becomes 19.
But using the value of 10 instead of 9 for sc-beacon.slottime does the
trick. That's the minimal patch that works for me.
Perhaps we should be using ATH9K_SLOT_TIME_9 there (see mac.h) and
define it to 10.
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 6796d5c..d230128 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1833,7 +1833,7 @@ static void ath9k_bss_info_changed(struct ieee80211_hw
*hw,
if (changed BSS_CHANGED_ERP_SLOT) {
if (bss_conf-use_short_slot)
- slottime = 9;
+ slottime = 10;
else
slottime = 20;
if (vif-type == NL80211_IFTYPE_AP) {
--
Regards,
Pavel Roskin
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On 2010-01-30 9:37 PM, Pavel Roskin wrote: On Sat, 2010-01-30 at 21:10 +0100, Felix Fietkau wrote: The workaround value of '64' is actually wrong. When I had trouble associating in 2.4 GHz in a case where the slot time was actually set correctly, I simply used it, because that's what was being set in the initvals. We shouldn't base the slot time on this though - the initvals don't do this either. I could reduce the minimal value of acktimeout from 64 to 20. With 20, I get a reliable communication every time. With 19, it's doesn't work ever. The distance between STA and AP is about 1 meter. The slottime == -1 thing is obviously a bug, and I'll send a patch to fix it later. It turns out that simply increasing the initial value to 54 is not enough, as ah-slottime will be set to 9 from sc-beacon.slottime, so acktimeout becomes 19. That's why my patch forces it to a minimum of 64 just before it gets set. But using the value of 10 instead of 9 for sc-beacon.slottime does the trick. That's the minimal patch that works for me. Perhaps we should be using ATH9K_SLOT_TIME_9 there (see mac.h) and define it to 10. That value would still be wrong, though. According to the 802.11 docs, the slot time for 2.4 GHz has to be set to 9 usec, not 10. If this is a bug in the hardware, we need to know about the implications before we pick a value that just happened to work in our tests, but may not work in all cases. slottime=9, acktimeout=64 is what the initvals use, so that's tested by Atheros. If we continue to receive no comments from Atheros on this issue, we should probably use those values by default. By the way, 5 GHz seems to be unaffected by this issue, which makes this a little suspicious. I've Cc'd Luis, maybe he can forward this to the right people. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On Sat, 2010-01-30 at 21:46 +0100, Felix Fietkau wrote: But using the value of 10 instead of 9 for sc-beacon.slottime does the trick. That's the minimal patch that works for me. Perhaps we should be using ATH9K_SLOT_TIME_9 there (see mac.h) and define it to 10. That value would still be wrong, though. According to the 802.11 docs, the slot time for 2.4 GHz has to be set to 9 usec, not 10. OK, we may need a fudge factor elsewhere. Ideally, it should be based on Atheros documentation, but we cannot just keep the driver in a non-functioning state if we don't have such documentation. If this is a bug in the hardware, we need to know about the implications before we pick a value that just happened to work in our tests, but may not work in all cases. slottime=9, acktimeout=64 is what the initvals use, so that's tested by Atheros. If we continue to receive no comments from Atheros on this issue, we should probably use those values by default. By the way, 5 GHz seems to be unaffected by this issue, which makes this a little suspicious. Indeed, it's unaffected. But the reason is because sifstime is 16 for the band, not 10, which pushes acktimeout to 25. I tried setting acktimeout to a lower value. 23 is OK on channel 165, 22 is not. 22 is OK on channel 36 though. -- Regards, Pavel Roskin ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k in wireless-testing won't work in AP mode
On 2010-01-30 12:05 AM, Pavel Roskin wrote: Hello ath9k in wireless-testing won't work in AP mode. Stations fail to associate: # hostapd /etc/hostapd/wlan13.conf Configuration file: /etc/hostapd/wlan13.conf Using interface wlan13 with hwaddr 00:15:6d:84:1f:37 and ssid 'mike2' wlan13: STA 00:17:c4:3b:fc:88 IEEE 802.11: did not acknowledge authentication response I haven't used ath9k in AP mode for a long time if ever, so I don't know when it broke. Please try this patch and see if it helps. --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1229,6 +1229,11 @@ void ath9k_hw_init_global_settings(struc /* As defined by IEEE 802.11-2007 17.3.8.6 */ slottime = ah-slottime + 3 * ah-coverage_class; acktimeout = slottime + sifstime; + + /* Workaround for a hw issue */ + if (conf-channel conf-channel-band == IEEE80211_BAND_2GHZ) + acktimeout = max(64, acktimeout); + ath9k_hw_setslottime(ah, slottime); ath9k_hw_set_ack_timeout(ah, acktimeout); ath9k_hw_set_cts_timeout(ah, acktimeout); ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
