* bad packets in monitor mode with ar9170 devices @ 2011-04-01 3:12 Realman Namingston 2011-04-01 7:51 ` Christian Lamparter 0 siblings, 1 reply; 6+ messages in thread From: Realman Namingston @ 2011-04-01 3:12 UTC (permalink / raw) To: linux-wireless 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bad packets in monitor mode with ar9170 devices 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 0 siblings, 1 reply; 6+ messages in thread From: Christian Lamparter @ 2011-04-01 7:51 UTC (permalink / raw) To: Realman Namingston; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bad packets in monitor mode with ar9170 devices 2011-04-01 7:51 ` Christian Lamparter @ 2011-04-01 16:54 ` Gábor Stefanik 2011-04-01 17:33 ` Christian Lamparter 0 siblings, 1 reply; 6+ messages in thread From: Gábor Stefanik @ 2011-04-01 16:54 UTC (permalink / raw) To: Christian Lamparter; +Cc: Realman Namingston, linux-wireless 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 -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bad packets in monitor mode with ar9170 devices 2011-04-01 16:54 ` Gábor Stefanik @ 2011-04-01 17:33 ` Christian Lamparter 2011-04-05 0:16 ` Gábor Stefanik 0 siblings, 1 reply; 6+ messages in thread From: Christian Lamparter @ 2011-04-01 17:33 UTC (permalink / raw) To: Gábor Stefanik; +Cc: Realman Namingston, linux-wireless 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? ??? 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bad packets in monitor mode with ar9170 devices 2011-04-01 17:33 ` Christian Lamparter @ 2011-04-05 0:16 ` Gábor Stefanik 2011-04-05 0:28 ` Richard Farina 0 siblings, 1 reply; 6+ messages in thread From: Gábor Stefanik @ 2011-04-05 0:16 UTC (permalink / raw) To: Christian Lamparter; +Cc: Realman Namingston, linux-wireless 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. :-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bad packets in monitor mode with ar9170 devices 2011-04-05 0:16 ` Gábor Stefanik @ 2011-04-05 0:28 ` Richard Farina 0 siblings, 0 replies; 6+ messages in thread From: Richard Farina @ 2011-04-05 0:28 UTC (permalink / raw) To: Gábor Stefanik Cc: Christian Lamparter, Realman Namingston, linux-wireless 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 >> > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-04-05 0:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2011-04-05 0:28 ` Richard Farina
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).