Re: bad packets in monitor mode with ar9170 devices

[Richard Farina <sidhayn@gmail.com>]

On 04/04/11 20:16, Gábor Stefanik wrote:
> 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.
>
zd1211 sent garbage constantly, things were actually added to kismet
because of that failure.

While I personally have no such issues with chr's most excellent driver,
I can still point you to kismet's readme and suggest you search for
'fcs'.  Assuming the card has a similar issue to the zydas it passes bad
frames but validating the fcs drops the bad packets.

-Zero_Chaos

>> Regards,
>>        Chr
>>
>
>