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
___
ath
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 a
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
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 wrote:
> > > On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote:
> > >> Well so what I meant is that we should ensure hardware i
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 program
On Tue, 2010-02-02 at 16:45 -0800, Luis R. Rodriguez wrote:
> On Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau 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 Tue, Feb 2, 2010 at 4:35 PM, Felix Fietkau wrote:
> On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote:
>> On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau wrote:
>>> On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote:
We have reviewed this. The 64 value came from interoperability
tests against
On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote:
> On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau 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 BlockAck
On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau 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
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 recom
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 ti
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
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
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
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
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=0xc900107c00
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'
> w
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
18 matches
Mail list logo
