linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Capturing packets with bad FCS in monitor mode
@ 2010-08-05 14:14 Daniel Haid
  2010-08-05 14:43 ` ABM Musa
  2010-08-05 22:58 ` Qasim Javed
  0 siblings, 2 replies; 14+ messages in thread
From: Daniel Haid @ 2010-08-05 14:14 UTC (permalink / raw)
  To: linux-wireless

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: Capturing packets with bad FCS in monitor mode
  2010-08-05 14:14 Capturing packets with bad FCS in monitor mode Daniel Haid
@ 2010-08-05 14:43 ` ABM Musa
  2010-08-05 14:56   ` Johannes Berg
  2010-08-05 16:19   ` Daniel Haid
  2010-08-05 22:58 ` Qasim Javed
  1 sibling, 2 replies; 14+ messages in thread
From: ABM Musa @ 2010-08-05 14:43 UTC (permalink / raw)
  To: 'Daniel Haid', linux-wireless


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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: Capturing packets with bad FCS in monitor mode
  2010-08-05 14:43 ` ABM Musa
@ 2010-08-05 14:56   ` Johannes Berg
  2010-08-05 16:19   ` Daniel Haid
  1 sibling, 0 replies; 14+ messages in thread
From: Johannes Berg @ 2010-08-05 14:56 UTC (permalink / raw)
  To: ABM Musa; +Cc: 'Daniel Haid', linux-wireless

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Capturing packets with bad FCS in monitor mode
  2010-08-05 14:43 ` ABM Musa
  2010-08-05 14:56   ` Johannes Berg
@ 2010-08-05 16:19   ` Daniel Haid
  2010-08-05 16:30     ` ABM Musa
  1 sibling, 1 reply; 14+ messages in thread
From: Daniel Haid @ 2010-08-05 16:19 UTC (permalink / raw)
  To: ABM Musa; +Cc: linux-wireless

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Capturing packets with bad FCS in monitor mode
  2010-08-05 16:19   ` Daniel Haid
@ 2010-08-05 16:30     ` ABM Musa
  2010-08-05 16:40       ` Daniel Haid
  0 siblings, 1 reply; 14+ messages in thread
From: ABM Musa @ 2010-08-05 16:30 UTC (permalink / raw)
  To: Daniel Haid; +Cc: linux-wireless

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Capturing packets with bad FCS in monitor mode
  2010-08-05 16:30     ` ABM Musa
@ 2010-08-05 16:40       ` Daniel Haid
  2010-08-05 16:50         ` ABM Musa
  0 siblings, 1 reply; 14+ messages in thread
From: Daniel Haid @ 2010-08-05 16:40 UTC (permalink / raw)
  To: ABM Musa; +Cc: linux-wireless

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Capturing packets with bad FCS in monitor mode
  2010-08-05 16:40       ` Daniel Haid
@ 2010-08-05 16:50         ` ABM Musa
  0 siblings, 0 replies; 14+ messages in thread
From: ABM Musa @ 2010-08-05 16:50 UTC (permalink / raw)
  To: Daniel Haid; +Cc: linux-wireless

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Capturing packets with bad FCS in monitor mode
  2010-08-05 14:14 Capturing packets with bad FCS in monitor mode Daniel Haid
  2010-08-05 14:43 ` ABM Musa
@ 2010-08-05 22:58 ` Qasim Javed
  2010-08-06  0:58   ` Daniel Haid
                     ` (2 more replies)
  1 sibling, 3 replies; 14+ messages in thread
From: Qasim Javed @ 2010-08-05 22:58 UTC (permalink / raw)
  To: Daniel Haid; +Cc: linux-wireless

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Capturing packets with bad FCS in monitor mode
  2010-08-05 22:58 ` Qasim Javed
@ 2010-08-06  0:58   ` Daniel Haid
  2010-08-06  1:06   ` Daniel Haid
  2010-08-06 10:09   ` radiotap rate no longer supported in mac80211? Daniel Haid
  2 siblings, 0 replies; 14+ messages in thread
From: Daniel Haid @ 2010-08-06  0:58 UTC (permalink / raw)
  To: linux-wireless; +Cc: Qasim Javed

> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Capturing packets with bad FCS in monitor mode
  2010-08-05 22:58 ` Qasim Javed
  2010-08-06  0:58   ` Daniel Haid
@ 2010-08-06  1:06   ` Daniel Haid
  2010-08-06 10:09   ` radiotap rate no longer supported in mac80211? Daniel Haid
  2 siblings, 0 replies; 14+ messages in thread
From: Daniel Haid @ 2010-08-06  1:06 UTC (permalink / raw)
  To: linux-wireless, Qasim Javed

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: radiotap rate no longer supported in mac80211?
  2010-08-05 22:58 ` Qasim Javed
  2010-08-06  0:58   ` Daniel Haid
  2010-08-06  1:06   ` Daniel Haid
@ 2010-08-06 10:09   ` Daniel Haid
  2 siblings, 0 replies; 14+ messages in thread
From: Daniel Haid @ 2010-08-06 10:09 UTC (permalink / raw)
  To: linux-wireless

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?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: radiotap rate no longer supported in mac80211?
  2010-06-15 20:18 ` Pavel Roskin
@ 2011-03-30 15:42   ` Roberto Riggio
  0 siblings, 0 replies; 14+ messages in thread
From: Roberto Riggio @ 2011-03-30 15:42 UTC (permalink / raw)
  To: linux-wireless

Pavel Roskin <proski@...> writes:

> I posted a patch that would add rate and retry flags:
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441
> 
> I didn't see any interest in the patch.  Perhaps injecting packets at a
> specific rate in not particularly needed.

Well maybe it is a little late to reply to this. Anyway I'm actually using
your patch as part of a custom routing protocol for a mesh based on the roofnet 
code.







^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: radiotap rate no longer supported in mac80211?
  2010-06-14 22:18 Steve deRosier
@ 2010-06-15 20:18 ` Pavel Roskin
  2011-03-30 15:42   ` Roberto Riggio
  0 siblings, 1 reply; 14+ messages in thread
From: Pavel Roskin @ 2010-06-15 20:18 UTC (permalink / raw)
  To: Steve deRosier; +Cc: linux-wireless

On Mon, 2010-06-14 at 15:18 -0700, Steve deRosier wrote:
> I'm trying to support per-packet setting of rate on a packet injection
> via the radiotap header.  In an earlier version of mac80211 (around
> 2.6.26), there was code in __ieee80211_parse_tx_radiotap (in
> net/mac80211/tx.c) to support the use of the the rate element from the
> radiotap header.  In current versions of wireless-testing, most of the
> code here has been removed and only the flags are parsed.
> 
> I want to return the IEEE80211_RADIOTAP_RATE portion of this function
> in order to support this.  So the questions:
> 1. Why were all fields other than IEEE80211_RADIOTAP_FLAGS removed?
> 2. Would it be OK for me to prepare and submit a patch to restore the
> rate functionality?

I posted a patch that would add rate and retry flags:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441

I didn't see any interest in the patch.  Perhaps injecting packets at a
specific rate in not particularly needed.

Also, the patch is somewhat inelegant because of the requirement to
specify the rate when the retry count is specified.

mac80211 has an array of rates with corresponding retry counts.  The
radiotap standard has one rate and one retry count.  This doesn't map
well to the mac80211 approach.  Supporting the retry count without the
rate would require some tricky logic, and I don't know if anyone needs
that.

I don't feel good about pushing a patch that makes the code more complex
without knowing the use case.

-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 14+ messages in thread

* radiotap rate no longer supported in mac80211?
@ 2010-06-14 22:18 Steve deRosier
  2010-06-15 20:18 ` Pavel Roskin
  0 siblings, 1 reply; 14+ messages in thread
From: Steve deRosier @ 2010-06-14 22:18 UTC (permalink / raw)
  To: linux-wireless

I'm trying to support per-packet setting of rate on a packet injection
via the radiotap header.  In an earlier version of mac80211 (around
2.6.26), there was code in __ieee80211_parse_tx_radiotap (in
net/mac80211/tx.c) to support the use of the the rate element from the
radiotap header.  In current versions of wireless-testing, most of the
code here has been removed and only the flags are parsed.

I want to return the IEEE80211_RADIOTAP_RATE portion of this function
in order to support this.  So the questions:
1. Why were all fields other than IEEE80211_RADIOTAP_FLAGS removed?
2. Would it be OK for me to prepare and submit a patch to restore the
rate functionality?

Thanks,
- Steve

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2011-03-30 15:45 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-05 14:14 Capturing packets with bad FCS in monitor mode Daniel Haid
2010-08-05 14:43 ` ABM Musa
2010-08-05 14:56   ` Johannes Berg
2010-08-05 16:19   ` Daniel Haid
2010-08-05 16:30     ` ABM Musa
2010-08-05 16:40       ` Daniel Haid
2010-08-05 16:50         ` ABM Musa
2010-08-05 22:58 ` Qasim Javed
2010-08-06  0:58   ` Daniel Haid
2010-08-06  1:06   ` Daniel Haid
2010-08-06 10:09   ` radiotap rate no longer supported in mac80211? Daniel Haid
  -- strict thread matches above, loose matches on Subject: below --
2010-06-14 22:18 Steve deRosier
2010-06-15 20:18 ` Pavel Roskin
2011-03-30 15:42   ` Roberto Riggio

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).