[ath9k-devel] ath9k in wireless-testing won't work in AP mode

[ath9k-devel] ath9k in wireless-testing won't work in AP mode

[Pavel Roskin]

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
AP-STA-DISCONNECTED 00:17:c4:3b:fc:88
Could not set station 00:17:c4:3b:fc:88 flags for kernel driver
(errno=11).
wlan13: STA 00:17:c4:3b:fc:88 IEEE 802.11: disassociated
wlan13: STA 00:17:c4:3b:fc:88 IEEE 802.11: deauthenticated due to
inactivity
Failed to remove interface (ifidx=0).

Everything is fine with rt73usb on the same system with the same client:

# hostapd /etc/hostapd/wlan5.conf
Configuration file: /etc/hostapd/wlan5.conf
Using interface wlan5 with hwaddr 00:11:6b:39:40:19 and ssid 'mike2'
wlan5: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan5: STA 00:17:c4:3b:fc:88 IEEE 802.11: associated (aid 1)
AP-STA-CONNECTED 00:17:c4:3b:fc:88
wlan5: STA 00:17:c4:3b:fc:88 RADIUS: starting accounting session
4B636488-00000000
wlan5: STA 00:17:c4:3b:fc:88 WPA: pairwise key handshake completed (RSN)

The only difference between wlan13.conf and wlan5.conf is the interface
name.  The client runs MadWifi.  With ath9k on the client side things
look even weirder on the AP side:

# 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
unknown mgmt cb frame subtype 10

Things are still OK with rt73usb on the AP side if the client uses
ath9k.

hostapd is current from the hostap git (essentially version 0.7.1 with a
few more changes).  The AP is an x86_64 PC with the current kernel from
wireless-testing.

I haven't used ath9k in AP mode for a long time if ever, so I don't know
when it broke.

I guess I'll need to look in Wireshark if the authentication response is
indeed acknowledged by the station, but I won't have time for that soon.

-- 
Regards,
Pavel Roskin

[ath9k-devel] ath9k in wireless-testing won't work in AP mode

[Felix Fietkau]

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] ath9k in wireless-testing won't work in AP mode

[Pavel Roskin]

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=0xffffc900107c0000, 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 = ffffffffa01c2520, conf->channel->band = 0
ah->slottime = -1, ah->coverage_class = 0, sifstime = 10
acktimeout = 9, conf->channel = ffffffffa01c2520, conf->channel->band = 0
ah->slottime = -1, ah->coverage_class = 0, sifstime = 10
acktimeout = 9, conf->channel = ffffffffa01c2520, conf->channel->band = 0
ah->slottime = -1, ah->coverage_class = 0, sifstime = 10
acktimeout = 9, conf->channel = ffffffffa01c25d4, conf->channel->band = 0
ah->slottime = 9, ah->coverage_class = 0, sifstime = 10
acktimeout = 19, conf->channel = ffffffffa01c25d4, 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] ath9k in wireless-testing won't work in AP mode

[Felix Fietkau]

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=0xffffc900107c0000, 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 = ffffffffa01c2520, conf->channel->band = 0
> ah->slottime = -1, ah->coverage_class = 0, sifstime = 10
> acktimeout = 9, conf->channel = ffffffffa01c2520, conf->channel->band = 0
> ah->slottime = -1, ah->coverage_class = 0, sifstime = 10
> acktimeout = 9, conf->channel = ffffffffa01c2520, conf->channel->band = 0
> ah->slottime = -1, ah->coverage_class = 0, sifstime = 10
> acktimeout = 9, conf->channel = ffffffffa01c25d4, conf->channel->band = 0
> ah->slottime = 9, ah->coverage_class = 0, sifstime = 10
> acktimeout = 19, conf->channel = ffffffffa01c25d4, 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] ath9k in wireless-testing won't work in AP mode

[Pavel Roskin]

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] ath9k in wireless-testing won't work in AP mode

[Felix Fietkau]

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] ath9k in wireless-testing won't work in AP mode

[Pavel Roskin]

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] ath9k in wireless-testing won't work in AP mode

[Luis R. Rodriguez]

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] ath9k in wireless-testing won't work in AP mode

[Felix Fietkau]

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] ath9k in wireless-testing won't work in AP mode

[Luis R. Rodriguez]

On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau <nbd@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] ath9k in wireless-testing won't work in AP mode

[Felix Fietkau]

On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote:
> On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau <nbd@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] ath9k in wireless-testing won't work in AP mode

[Luis R. Rodriguez]

On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau <nbd@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 <nbd@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] ath9k in wireless-testing won't work in AP mode

[Pavel Roskin]

On Tue, 2010-02-02 at 16:45 -0800, Luis R. Rodriguez wrote:
> On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau <nbd@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acktimeout.png
Type: image/png
Size: 12484 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20100202/7b829921/attachment-0001.png 

[ath9k-devel] ath9k in wireless-testing won't work in AP mode

[Luis R. Rodriguez]

On Tue, Feb 02, 2010 at 07:29:42PM -0800, Pavel Roskin wrote:
> On Tue, 2010-02-02 at 16:45 -0800, Luis R. Rodriguez wrote:
> > On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau <nbd@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.

The reason for having the increase to 64 was documented as a solution
to an interoperability issue against another device which sent out a delayed
BA when CTS-to-self was enabled. The reports about AR9160, AR9220 and AR9271
on this thread might not be the same though and could technically involve
a bus delay issue. Either way the default value of 64 should be used by
default since it is what has been kept and tested widely.

> If the limit is needed to guard against hardware limitations, then we
> want maximum.

Its not a hardware limitation.

> It means that the timeout is implemented accurately in
> the hardware, it just cannot be too low.

Right, that is not the case.

> 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.

You're right, whether the processing delays are bus specific or interop
specific addition is required. So to clarify we should then add the delta
between what the spec says and what is programmed into the initvals
then.

  Luis

[ath9k-devel] ath9k in wireless-testing won't work in AP mode

[Sujith]

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] ath9k in wireless-testing won't work in AP mode

[Jouni Malinen]

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] ath9k in wireless-testing won't work in AP mode

[Peter Stuge]

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] ath9k in wireless-testing won't work in AP mode

[Peter Stuge]

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