Linux wireless drivers development
 help / color / mirror / Atom feed
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
To: Gary Morain <gmorain@chromium.org>
Cc: <linux-wireless@vger.kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>, <pstew@chromium.org>
Subject: [PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes
Date: Tue, 22 May 2012 06:26:33 +0530	[thread overview]
Message-ID: <20410.58433.115014.351622@gargle.gargle.HOWL> (raw)
In-Reply-To: <CADfcX6pjFEWyxd5o-t7yPdr+6MkB+7ZvQ-TgAe1A894h7C5vTw@mail.gmail.com>

Gary Morain wrote:
> Scenario:
> 1.  Client connects to a managed AP.
> 2.  Client goes off-channel to scan for APs.
> 3.  AP goes off-channel to scan for rogue APs.  The client misses any
> signaling the AP may have sent.
> 4.  The client returns to its home channel before the AP does.
> 5.  The client immediately probes the AP with a nullfunc.
> (ieee80211_mlme_notify_scan_completed()).
> 6.  The AP does not respond to the nullfunc because it is off-channel.
> 7.  The client retries the nullfunc, which also does not get an ACK, and the
> client disconnects from the AP (ieee80211_sta_work).
> 
> It's worth noticing that the client never detects beacon loss because the AP
> is not off-channel long enough to miss sending multiple beacons.

If this is with ath9k, there is a much more fundamental issue - the HW beacon
timers are never re-programmed with the correct values, which can be done only
after a TSF sync.

The sequence is like this:

* ath9k associates to an AP
* A scan is started on the station side.
* The HW is reset as part of the scan.
* The scan completes.
* ath9k sets the BSSID and configures beacon timers - but,
  without waiting for the HW TSF sync, so the timers
  end up being programmed incorrectly.

This is with wireless-testing.

Sujith

      reply	other threads:[~2012-05-22  0:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 20:49 [PATCH] CHROMIUMOS: mac80211: Increase retry attempts for nullfunc probes Gary Morain
2012-05-21 19:26 ` Johannes Berg
     [not found]   ` <CADfcX6r=GuQh2kdC_OEX9fvfGjWXeGwFKGTfFWs-88nqgGNF_Q@mail.gmail.com>
2012-05-21 22:29     ` Gary Morain
2012-05-22  0:56       ` Sujith Manoharan [this message]

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=20410.58433.115014.351622@gargle.gargle.HOWL \
    --to=c_manoha@qca.qualcomm.com \
    --cc=gmorain@chromium.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pstew@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox