All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Tyler Gray <graytfg@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: iwlwifi intermittent beacon capture in monitor mode?
Date: Fri, 23 Mar 2018 17:26:06 +0100	[thread overview]
Message-ID: <1521822366.28252.5.camel@sipsolutions.net> (raw)
In-Reply-To: <CAEo4QHwLarcoui=oh+2zX++TBh0juVjp1dV8Gjq77x=W+enAVQ@mail.gmail.com> (sfid-20180323_160239_305970_44135ABA)

On Fri, 2018-03-23 at 11:02 -0400, Tyler Gray wrote:

> I'm positive we're just in monitor mode. [snip]

Ok, it was just a thought.

> To be clear, I'm not claiming I can set two devices up anywhere,
> anytime, and run this test and see huge gaps in beacons, but we've
> tested across multiple devices and multiple brands of devices with
> 7265 cards, and we have data collected in locations that are miles
> apart that show the same behavior, so I'm confident this isn't just
> one bad card or one incredibly unlucky setup that shows the problem.
> I have determined spots where I'm far more likely to see the issue,
> but I'll maintain that outside of a pathologically bad environment, I
> should be able to see beacons from 6 feet away.
> 
> You mentioned the firmware can suppress beacons for powersaving.  Is
> there any debug I could look at to see if that was happening?  I
> posted some fw_rx_stats, would those counters be incremented before
> that filtering would happen?  I just watched the counters during a
> good period and a bad period.  In the "good" period I saw 15 CCK
> packets/second, which is what I'd expect for my AP beaconing plus some
> some probe responses and some beacons from the adjacent channel.
> During the bad period the firmware saw 2 CCK packets in 7 seconds, and
> none of the error counters for the bad period showed an additional 100
> packets lost for any reason.  The two periods had fairly similar
> plcp_err stats.

I'd have to check.

ISTR being told that 8260 devices would make much better sniffers - any
chances you have one of those to try?

> As a side note, if I have a device connect to the AP and run iperf to
> generate data, I'll capture an average of 99% of the data packets, yet
> I'll often see 0 beacons while the transfer is happening.  So it's not
> that I can't receive packets at all, and capturing those data packets
> should be a far harder task, but it seems beacons get dropped in a
> variety of cases and I can't determine why.

Interesting.

> Are there any known conflicts between the bluetooth and the wifi?  Is
> there an easy answer to the best (lowest level) way to disable
> bluetooth if so?

rmmod btusb ;-)

I don't really know for sure, but I wouldn't really expect BT to affect
single-chain RX performance much.

Perhaps you could file a bug on bugzilla.kernel.org so we can track this
better.

johannes

  reply	other threads:[~2018-03-23 16:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-22 20:54 iwlwifi intermittent beacon capture in monitor mode? Tyler Gray
2018-03-22 21:20 ` James Cameron
2018-03-23  8:17 ` Johannes Berg
2018-03-23 15:02   ` Tyler Gray
2018-03-23 16:26     ` Johannes Berg [this message]
2018-03-23 18:28       ` Tyler Gray

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=1521822366.28252.5.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=graytfg@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.