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.
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
<[email protected]> 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 [email protected]
> 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
[email protected]
http://www.venatech.se
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
> <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
>
> 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.
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
On 2010-06-04 5:02 PM, Roberto Riggio wrote:
> On Fri, Jun 4, 2010 at 5:00 PM, Felix Fietkau <[email protected]> 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
On Fri, Jun 4, 2010 at 5:00 PM, Felix Fietkau <[email protected]> wrote:
> Are you using 2.4 or 5 GHz?
5 GHz
> - Felix
R.
> 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.