Strange ACK Behaviour with ath9k

Strange ACK Behaviour with ath9k

[Roberto Riggio]

Hi,

I'm having a very strange behaviour between two sr71a (ath9k) cards
operating in monitor mode. I'm using the following patch to specify
the transmission rate frame by frame:

http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441


However if I try to send some traffic between the two nodes with both
interfaces operating in monitor mode I can see from a third machine
using wireshark that albeit the frame is sent and the corresponding
ack generated, the originator seems to ignore the ACK and keepts
retransmitting the frame. This is happening on both ends of the
communication (i'm ping one node from the other).

As a matter of fact i thought that ACK are handled directly by the
firmware. Any hints?

R.

Re: Strange ACK Behaviour with ath9k

[Björn Smedman]

Hi Roberto,

When I've seen this it has been caused by a mismatch between the
addresses in the injected frame and that configured in the hardware.
The transmitting radio doesn't understand it is the intended recipient
of the ack and continues retrying.

/Björn

On Thu, May 13, 2010 at 6:04 PM, Roberto Riggio
<roberto.riggio@create-net.org> wrote:
>
> Hi,
>
> I'm having a very strange behaviour between two sr71a (ath9k) cards
> operating in monitor mode. I'm using the following patch to specify
> the transmission rate frame by frame:
>
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441
>
>
> However if I try to send some traffic between the two nodes with both
> interfaces operating in monitor mode I can see from a third machine
> using wireshark that albeit the frame is sent and the corresponding
> ack generated, the originator seems to ignore the ACK and keepts
> retransmitting the frame. This is happening on both ends of the
> communication (i'm ping one node from the other).
>
> As a matter of fact i thought that ACK are handled directly by the
> firmware. Any hints?
>
> R.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Venatech AB
Ideon Innovation
Ole Römers väg 12
SE-22370 LUND
Sweden

+46 (0) 46 286 86 20
info@venatech.se
http://www.venatech.se

Re: Strange ACK Behaviour with ath9k

[Roberto Riggio]

Hi,

at both ends of the communications I get the hwaddr from the iwconfig
command and I pass the output to my software. In fact the other host
acks the frame carrying the echo request message and generates the
corresponding echo reply whose frame is actually acked by the recipient
the point is that they keep resending the frames until the max data retries
is reached.

On 05/14/2010 01:15 AM, Björn Smedman wrote:
> Hi Roberto,
>
> When I've seen this it has been caused by a mismatch between the
> addresses in the injected frame and that configured in the hardware.
> The transmitting radio doesn't understand it is the intended recipient
> of the ack and continues retrying.
>
> /Björn
>
> On Thu, May 13, 2010 at 6:04 PM, Roberto Riggio
> <roberto.riggio@create-net.org>  wrote:
>    
>> Hi,
>>
>> I'm having a very strange behaviour between two sr71a (ath9k) cards
>> operating in monitor mode. I'm using the following patch to specify
>> the transmission rate frame by frame:
>>
>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441
>>
>>
>> However if I try to send some traffic between the two nodes with both
>> interfaces operating in monitor mode I can see from a third machine
>> using wireshark that albeit the frame is sent and the corresponding
>> ack generated, the originator seems to ignore the ACK and keepts
>> retransmitting the frame. This is happening on both ends of the
>> communication (i'm ping one node from the other).
>>
>> As a matter of fact i thought that ACK are handled directly by the
>> firmware. Any hints?
>>
>> R.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>      
>
>
>    

Re: Strange ACK Behaviour with ath9k

[Roberto Riggio]

> On 05/14/2010 01:15 AM, Björn Smedman wrote:
> > Hi Roberto,
> >
> > When I've seen this it has been caused by a mismatch between the
> > addresses in the injected frame and that configured in the hardware.
> > The transmitting radio doesn't understand it is the intended recipient
> > of the ack and continues retrying.

It seems that the problem is related to the ack timeout. The strange thing is 
that if is use (on the transmitter)

iw phy phy0 set distance 600

everything works fine

however if I use:

iw phy phy0 set distance 300

ack are ignored. 

R.

Re: Strange ACK Behaviour with ath9k

[Felix Fietkau]

On 2010-06-04 3:59 PM, Roberto Riggio wrote:
> 
>> On 05/14/2010 01:15 AM, Björn Smedman wrote:
>> > Hi Roberto,
>> >
>> > When I've seen this it has been caused by a mismatch between the
>> > addresses in the injected frame and that configured in the hardware.
>> > The transmitting radio doesn't understand it is the intended recipient
>> > of the ack and continues retrying.
> 
> It seems that the problem is related to the ack timeout. The strange thing is 
> that if is use (on the transmitter)
> 
> iw phy phy0 set distance 600
> 
> everything works fine
> 
> however if I use:
> 
> iw phy phy0 set distance 300
> 
> ack are ignored. 
Are you using 2.4 or 5 GHz?

- Felix

Re: Strange ACK Behaviour with ath9k

[Roberto Riggio]

On Fri, Jun 4, 2010 at 5:00 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> Are you using 2.4 or 5 GHz?

5 GHz

> - Felix
R.

Re: Strange ACK Behaviour with ath9k

[Felix Fietkau]

On 2010-06-04 5:02 PM, Roberto Riggio wrote:
> On Fri, Jun 4, 2010 at 5:00 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> Are you using 2.4 or 5 GHz?
> 
> 5 GHz
Did you test a recent version of wireless-testing/compat-wireless?
IIRC versions before the AR9300 merge had some bugs/inconsistencies in
the fast clock handling for 5 GHz.

- Felix

Re: Strange ACK Behaviour with ath9k

[Roberto Riggio]

> Did you test a recent version of wireless-testing/compat-wireless?
> IIRC versions before the AR9300 merge had some bugs/inconsistencies in
> the fast clock handling for 5 GHz.

I'm using compat wireless 2010-05-24 (the version available in openwrt trunk).

> - Felix
R.