Strange ACK Behaviour with ath9k
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
Quoted 26 lines · 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.
--
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
Signature · 9 lines
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.
Quoted 41 lines · 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
Quoted 26 lines · 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.
--
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
Quoted 8 lines · Björn Smedman
Quoted 6 lines
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.
Quoted 14 lines · Roberto Riggio
Quoted 8 lines · Björn Smedman
Quoted 6 lines
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
Quoted 7 lines
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
Quoted 1 line · Felix Fietkau
Are you using 2.4 or 5 GHz?
5 GHz
Quoted 1 line
- Felix
R.
Quoted 4 lines · Roberto Riggio
Quoted 1 line · Felix Fietkau
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
Quoted 3 lines
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).
Quoted 1 line
- Felix
R.