Capturing packets with bad FCS in monitor mode

Capturing packets with bad FCS in monitor mode

[Daniel Haid]

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.

RE: Capturing packets with bad FCS in monitor mode

[ABM Musa]

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: linux-wireless-owner@vger.kernel.org
[mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Daniel Haid
Sent: Thursday, August 05, 2010 9:14 AM
To: linux-wireless@vger.kernel.org
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.
--
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: Capturing packets with bad FCS in monitor mode

[Johannes Berg]

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

Re: Capturing packets with bad FCS in monitor mode

[Daniel Haid]

> 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?

Re: Capturing packets with bad FCS in monitor mode

[ABM Musa]

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

Re: Capturing packets with bad FCS in monitor mode

[Daniel Haid]

> 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?

Re: Capturing packets with bad FCS in monitor mode

[ABM Musa]

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 majordomo@vger.kernel.org
> 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

Re: Capturing packets with bad FCS in monitor mode

[Qasim Javed]

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 <d.haid@gogi.tv> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Capturing packets with bad FCS in monitor mode

[Daniel Haid]

> 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

Re: Capturing packets with bad FCS in monitor mode

[Daniel Haid]

> 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??

Re: radiotap rate no longer supported in mac80211?

[Daniel Haid]

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?