linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Gábor Stefanik" <netrolller.3d@gmail.com>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: Realman Namingston <realname1776@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: Re: bad packets in monitor mode with ar9170 devices
Date: Tue, 5 Apr 2011 02:16:58 +0200	[thread overview]
Message-ID: <BANLkTim51mYCDf-BRbR_GQd+E3DbUWDWYw@mail.gmail.com> (raw)
In-Reply-To: <201104011933.57597.chunkeey@googlemail.com>

2011/4/1 Christian Lamparter <chunkeey@googlemail.com>:
> On Friday 01 April 2011 18:54:29 Gábor Stefanik wrote:
>> On Fri, Apr 1, 2011 at 9:51 AM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > On Friday 01 April 2011 05:12:45 Realman Namingston wrote:
>> >> ar9170-based devices record a fair amount of bad packets in monitor
>> >> mode both with the old ar9170usb and new carl9170 drivers. The packets
>> >> contain random BSSIDs, some measure of additional random data, and
>> >> seem to scale proportional to the amount of traffic occurring on the
>> >> observed channel. This behavior makes the devices rather unattractive
>> >> for use in Kismet and site survey applications.
>> >>
>> >> I assume this is due to a shortcoming of the hardware.. but is there
>> >> any potential fix possible?
>> > no, you misunderstood that completely: it's a shortcoming of kismet!
>> >
>> > quote:
>> > "Usually the wireless adapter is unable to transmit in monitor mode and
>> > is restricted to a single wireless channel, though this is dependent on
>> > the wireless adapter's driver, its firmware, and its chip set's features.
>> > Also, in monitor mode the adapter does not check to see if the cyclic
>> > redundancy check (CRC) values are correct for packets captured, so some
>> > captured packets may be corrupted."
>> >
>> > http://en.wikipedia.org/wiki/Monitor_mode
>> > --
>> > 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
>> >
>>
>> Isn't ar9170 the wireless-N version of zd1211? Because zd1211
>> also had this problem with ZD_SNIFFER_ON. See
>> http://patches.aircrack-ng.org/zd1211rw_inject_2.6.26.patch
>
> inject? ???

The patch is misnamed.

>
> quote from include/net/mac80211.h:
>
> "enum ieee80211_filter_flags - hardware filter flags
>
> These flags determine what the filter in hardware should be
> programmed to let through and what should not be passed to the
> stack. >>>>> It is always safe to pass more frames than requested,
> but this has negative impact on power consumption. <<<<<"
>
> so, if you don't want the garbage then don't enable monitor mode.
> OR set the appropriate FIF_ filter flags and hope the mntr setting
> doesn't affect the way how the hardware/firmware/driver/stack
> marks "bad" frames.

IIRC in zd1211, the garbage was not simply PLCP-failed frames - the HW
returns completely bogus frames with ZD_SNIFFER_ON, even if placed in
an RF isolation chamber. Not sure about ar9170, but AFAIK ar9170
inherits quite a bit from zd1211.

>
> Regards,
>        Chr
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

  reply	other threads:[~2011-04-05  0:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-01  3:12 bad packets in monitor mode with ar9170 devices Realman Namingston
2011-04-01  7:51 ` Christian Lamparter
2011-04-01 16:54   ` Gábor Stefanik
2011-04-01 17:33     ` Christian Lamparter
2011-04-05  0:16       ` Gábor Stefanik [this message]
2011-04-05  0:28         ` Richard Farina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTim51mYCDf-BRbR_GQd+E3DbUWDWYw@mail.gmail.com \
    --to=netrolller.3d@gmail.com \
    --cc=chunkeey@googlemail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=realname1776@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).