linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Michal Kazior <michal.kazior@tieto.com>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mac80211: don't clear all tx flags when requeing
Date: Fri, 17 Jul 2015 11:07:18 +0200	[thread overview]
Message-ID: <1437124038.1933.4.camel@sipsolutions.net> (raw)
In-Reply-To: <1437123955.1933.3.camel@sipsolutions.net> (sfid-20150717_110614_486475_B0C53BCA)

On Fri, 2015-07-17 at 11:05 +0200, Johannes Berg wrote:
> On Thu, 2015-07-02 at 09:59 +0200, Michal Kazior wrote:
> > When acting as AP and a PS-Poll frame is received
> > associated station is marked as one in a Service
> > Period. This state is kept until Tx status for
> > released frame is reported. While a station is in
> > Service Period PS-Poll frames are ignored.
> > 
> > However if PS-Poll was received during A-MPDU
> > teardown it was possible to have the to-be
> > released frame re-queued back to pending queue.
> > In such case the frame was stripped of 2 important
> > flags:
> > 
> >  (a) IEEE80211_TX_CTL_NO_PS_BUFFER
> >  (b) IEEE80211_TX_STATUS_EOSP
> > 
> > Stripping of (a) led to the frame that was to be
> > released to be queued back to ps_tx_buf queue. If
> > station remained to use only PS-Poll frames the
> > re-queued frame (and new ones) was never actually
> > transmitted because mac80211 would ignore
> > subsequent PS-Poll frames due to station being in
> > Service Period. There was nothing left to clear
> > the Service Period bit (no xmit -> no tx status ->
> > no SP end), i.e. the AP would have the station
> > stuck in Service Period. Beacon TIM would
> > repeatedly prompt station to poll for frames but
> > it would get none.
> > 
> > Once (a) is not stripped (b) becomes important
> > because it's the main condition to clear the
> > Service Period bit of the station when Tx status
> > for the released frame is reported back.
> > 
> > This problem was observed with ath9k acting as P2P
> > GO in some testing scenarios but isn't limited to
> > it. AP operation with mac80211 based Tx A-MPDU
> > control combined with clients using PS-Poll frames
> > is subject to this race.
> 
> I'm not sure I quite understand - how is the aggregation teardown
> causing frame filtering?
> 

Never mind, I was looking at the wrong code. I'll apply this.

johannes

  reply	other threads:[~2015-07-17  9:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-02  7:59 [PATCH] mac80211: don't clear all tx flags when requeing Michal Kazior
2015-07-17  9:05 ` Johannes Berg
2015-07-17  9:07   ` Johannes Berg [this message]
2015-07-17  9:09     ` Johannes Berg
2015-07-17  9:35       ` Michal Kazior

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=1437124038.1933.4.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=michal.kazior@tieto.com \
    /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;
as well as URLs for NNTP newsgroup(s).