Hello,
is it possible to receive packets with bad FCS in monitor mode (ath9k driver)?
There is a comment in ath9k/common.c which says that a bad checksum is
ignored in monitor mode, but I have so far never been able to receive a
packet with bad FCS (I do not know how to generate such packets,
so I might just be too lucky that all packets are received unimpaired).
Does ath9k hardware drop packets with bad FCS directly? If so, can
it be disabled?
Best regards.
> I can get packets with crc error using this method and I get lot of
> corrupted packets. I am using ath9k with openwrt for router station
> pro+ubiquity sr-71A card and tplink 1043nd.
I am using an ubiquity sr-71X card, and still not one corrupted packet.
I think I need to artificially create and transmit a corrupted packet. How
can I do that?
> if (ah->opmode == NL80211_IFTYPE_MONITOR) {
> if (rx_stats->rs_status &
> ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
> ATH9K_RXERR_CRC))
> return false;
>
> Clearly, this function will return false in case of a CRC error while
> receiving on a monitor interface.
Wait a moment, should it not be the other way around? ATH9K_RXERR_CRC
is removed from rx_stats->rs_status and the comment above
also says that DECRYPT and MIC errors are ignored normally, while
CRC is additionally ignored in monitor mode.
Are you 100% certain that you were able to receive corrupted
packets after removing ATH9K_RXERR_CRC above??
Hi Daniel,
I am using the same card and the ath9k driver. I was also not able to
receive frames with CRC errors by setting the fcsfail flag while
creating the monitor mode interface. I looked up the code and found
that ath9k ignores frames with CRC errors in monitor mode.
The ath9k_rx_accept function in common.c has the following condition
if (ah->opmode == NL80211_IFTYPE_MONITOR) {
??????? if (rx_stats->rs_status &
??????????????? ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
??????????????? ATH9K_RXERR_CRC))
??????? return false;
Clearly, this function will return false in case of a CRC error while
receiving on a monitor interface.
For your info, this function is called by ath9k_rx_skb_preprocess
which in turn is invoked in ath9k_rx_tasklet.
In order to receive frames with CRC errors in monitor mode, I just
removed ATH9K_RXERR_CRC from the above snippet, recompiled and
reloaded ath9k and was able to receive frames with CRC errors.
I hope that helps.
-Qasim
On Thu, Aug 5, 2010 at 9:14 AM, Daniel Haid <[email protected]> wrote:
>
> Hello,
>
> is it possible to receive packets with bad FCS in monitor mode (ath9k driver)?
> There is a comment in ath9k/common.c which says that a bad checksum is
> ignored in monitor mode, but I have so far never been able to receive a
> packet with bad FCS (I do not know how to generate such packets,
> so I might just be too lucky that all packets are received unimpaired).
>
> Does ath9k hardware drop packets with bad FCS directly? If so, can
> it be disabled?
>
> Best regards.
> --
> 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
On 08/05/2010 11:40 AM, Daniel Haid wrote:
>> I can get packets with crc error using this method and I get lot of
>> corrupted packets. I am using ath9k with openwrt for router station
>> pro+ubiquity sr-71A card and tplink 1043nd.
>>
> I am using an ubiquity sr-71X card, and still not one corrupted packet.
>
> I think I need to artificially create and transmit a corrupted packet. How
> can I do that?
> --
> 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
>
>
I am not sure about how to create corrupted packets. Normally you should
get lot of corrupted packets from surrounding transmission. In my case,
monitor mode hangs sometime and I don't get any packets. Then if I
delete the interface and create a new interface using the iw command I
gave earlier, I get packets with crc error. You can also modify already
created interface using
iw wlan0 set monitor flag fcsfail
Musa
> Packets with crc error can be captured using corresponding flag of iw.
>
> iw phy phy0 interface add wlan0 type monitor flags fcsfail
Is this supported on ath9k? I do not see any difference so far
with the packet capturing.
I also do not find the FIF_FCSFAIL flag be used anywhere in
the ath9k code.
Will I get lots of corrupted packets if this is enabled properly or only
casually?
> In order to receive frames with CRC errors in monitor mode, I just
> removed ATH9K_RXERR_CRC from the above snippet, recompiled and
> reloaded ath9k and was able to receive frames with CRC errors.
I assume this is the case because the driver is still being developed and
the correct behaviour would be that frames with CRC errors are recieved
in monitor mode if and only if the fcsfail flag is not set.
Will a patch be accepted that implements that behaviour? What else
must the patch contain for it to be accepted?
(For example, what about the radiotap header? Will it automatically
have the bad fcs flag set when for a corrupted packet? Or does that
have to be still implemented as well?)
Thank you
On 08/05/2010 11:19 AM, Daniel Haid wrote:
>> Packets with crc error can be captured using corresponding flag of iw.
>>
>> iw phy phy0 interface add wlan0 type monitor flags fcsfail
>>
> Is this supported on ath9k? I do not see any difference so far
> with the packet capturing.
> I also do not find the FIF_FCSFAIL flag be used anywhere in
> the ath9k code.
>
> Will I get lots of corrupted packets if this is enabled properly or only
> casually?
>
>
I can get packets with crc error using this method and I get lot of
corrupted packets. I am using ath9k with openwrt for router station
pro+ubiquity sr-71A card and tplink 1043nd.
Musa
On Thu, 2010-08-05 at 09:43 -0500, ABM Musa wrote:
> Packets with crc error can be captured using corresponding flag of iw.
>
> iw phy phy0 interface add wlan0 type monitor flags fcsfail
>
> However, there is also option for plcpfail flag but I never obtained any
> packet with plcpfail using this flag. Any info about that will be helpful.
It only works with very few drivers (b43) and also had issues -- you'll
probably need this patch:
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/NNN-mac80211-no-rate-check.patch
johannes
Packets with crc error can be captured using corresponding flag of iw.
iw phy phy0 interface add wlan0 type monitor flags fcsfail
However, there is also option for plcpfail flag but I never obtained any
packet with plcpfail using this flag. Any info about that will be helpful.
Musa
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Daniel Haid
Sent: Thursday, August 05, 2010 9:14 AM
To: [email protected]
Subject: Capturing packets with bad FCS in monitor mode
Hello,
is it possible to receive packets with bad FCS in monitor mode (ath9k
driver)?
There is a comment in ath9k/common.c which says that a bad checksum is
ignored in monitor mode, but I have so far never been able to receive a
packet with bad FCS (I do not know how to generate such packets, so I might
just be too lucky that all packets are received unimpaired).
Does ath9k hardware drop packets with bad FCS directly? If so, can it be
disabled?
Best regards.
On 2010-06-15 Pavel Roskin wrote:
> I don't feel good about pushing a patch that makes the code more complex
> without knowing the use case.
I need this as well. How can it be implemented correctly, so that it can
be accepted?