thank you all for the replies. This is exactly the weird behavior I
experimented. Using the same configuration of Derek (which is simpler
than mine), I further investigate the RX path followed by the packets,
from the interrupt handler to the monitor VAP by printing out the
received packets MAC source and destination filtered on the destination
MAC of the receiver. The functions where I put the prints are (in
order): ath_uapsd_processtriggers (into the interrupt handler),
ath_rx_tasklet, ath_capture and ieee8011_input_monitor. The funny thing
is that even though the packet is acknowledged on the TX side, a
corrupted packet is shown in the interrupt handler which is therefore
discarded by e.g. the ath_rx_tasklet. More specifically, the destination
MAC is always (?) correct but the source MAC is completely wrong and
totally different from that of the transmitter.
However, increasing the ATH_RXBUF this effect disappears but I noticed
an increased packet transmission latency: the larger the ATH_RXBUF value
the higher the latency.
Benoit PAPILLAULT wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Derek Smithies a écrit :
>> I repeated the experiment, with some changes.
>> ATH_RXBUF was set to 2 (not 100) so the receive process had far fewer
>> buffers to put the received frames into.
>> Two nodes got this modified build of madwifi, and were run in adhoc mode.
>> The left node was sending ping packets to the right node.
>> The right node was running tcpdump.
>> A third box running standard ubuntu + standard madwifi with wireshark
>> captured packets on the air.
>> All three boxes are using 5212 hardware.
>> Ecryption was off. This simplified inspection of packet contents.
>> On the right box, tcpdump reported packets with an ICMP seqeuence
>> number of 2, 3, 6, 7, 8, 9,13, 14, 16, 17, 18
>> The third box reported ieee 802.11 acknowledgement packets for ICMP
>> sequence numbers of
>> What is happening?
>> The receive buffers are full (happens cause ATH_RXBUF is so small) but the
>> hardware sends an acknowledgement frame anyhow.
>> This is clearly hal version independent - only the hardware is
>> sufficiently fast to send ackknowledgements in the required time interval.
>> For the current NAPI code that we have to use - the implication is clear.
>> The buffer has to be
>> long enough to cope with delays between being drained by NAPI,
>> completely drained by NAPI when NAPI does process the buffer.
>> On Wed, 17 Dec 2008, y omar wrote:
>>>> At the transmitter, I check, through the driver packet feedback (ath_capture with tx = 1), whether the packet has been correctly
>>>> acknowledged by the receiver or not.
>>> I'm interested to know how did you check if the frames were acknowledged at the transmitter, in more details?
>>>> How is that possible and in which cases can that happen?
>>> There might be a scenario where: a packet is encrypted (e.g. WEP) at the transmitter, the receiver acknowledges it and then checks if the packet was correctly encrypted (using ICV check). If it finds that it is not , it drops the packet. I do not know if, in such case, it will show up in ath_rx_tasklet() but this might be a clue..
>>> Message: 5
>>> Date: Tue, 16 Dec 2008 22:45:14 +0100
>>> From: Alessandro Erta <alessandro.erta@...>
>>> Subject: [Madwifi-devel] Acknowledged frames are never received
>>> To: madwifi-devel@...
>>> Message-ID: <4948216A.1060702@...>
>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> Hi all,
>>> I set up a simple network configuration consisting of two units:
>>> transmitter and receiver. The driver version is 0.9.4 and interfaces
>>> both at the receiver and at the transmitter are set in monitor mode. I
>>> am injecting packets into the transmitter which sends them to the
>>> receiver. At the transmitter, I check, through the driver packet
>>> feedback (ath_capture with tx = 1), whether the packet has been
>>> correctly acknowledged by the receiver or not. However, sometimes it
>>> happens that even though the packet feedback results correct at the
>>> transmitter, the actual packet never shows up at the receiver (I used
>>> sequence numbers to identify the packets). I also printed all the
>>> packets received in the ath_rx_tasklet function of the receiver and, in
>>> fact, I could not see that packet.
>>> Therefore, I am thinking that even though the packet is successfully
>>> acknowledged by the receiver, the received packet is somehow not correct
>>> and it is discarded. How is that possible and in which cases can that
>>> Thank you very much!
>>> Kinda interesting! Did you check that the transmitter really receives
>>> ACK frames (they should be received by the monitor interfaces). Could
>>> you share the code you are using since I'm willing to test it?
>>> Did you try tcpdump/wireshark on both side at the same time?
> Hello Dereck and all,
> I have another strange experiment like this. In my case, tcpdump on the
> RX nodes shows lots of ICMP packets lots, but on the TX node, ICMP
> replies are correctly received! So, it is clear that tcpdump is not
> reliable! (Or, it triggers a bug in madwifi, or this is a consequence of
> a bug in madwifi... who knows...).
> Oh, btw, ath_capture might have a bug in some release. It ignores
> packets if there is no monitor VAP. In this case, it does not do any
> padding, so the RX frames won't be correctly decoded (and hence, they
> might be seen as lost...).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> Madwifi-devel mailing list