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?
-r1776
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
2011/4/1 Christian Lamparter <[email protected]>:
> On Friday 01 April 2011 18:54:29 G?bor Stefanik wrote:
>> On Fri, Apr 1, 2011 at 9:51 AM, Christian Lamparter
>> <[email protected]> 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 [email protected]
>> > 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. :-)
On Friday 01 April 2011 18:54:29 G?bor Stefanik wrote:
> On Fri, Apr 1, 2011 at 9:51 AM, Christian Lamparter
> <[email protected]> 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 [email protected]
> > 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? ???
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.
Regards,
Chr
On Fri, Apr 1, 2011 at 9:51 AM, Christian Lamparter
<[email protected]> 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 [email protected]
> 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
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On 04/04/11 20:16, G?bor Stefanik wrote:
> 2011/4/1 Christian Lamparter <[email protected]>:
>> On Friday 01 April 2011 18:54:29 G?bor Stefanik wrote:
>>> On Fri, Apr 1, 2011 at 9:51 AM, Christian Lamparter
>>> <[email protected]> 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 [email protected]
>>>> 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
>>
>
>