linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kalle.valo@iki.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>, linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v1 3/3] mac80211: add beacon filtering support
Date: Tue, 24 Feb 2009 22:34:25 +0200	[thread overview]
Message-ID: <873ae3y3ou.fsf@litku.valot.fi> (raw)
In-Reply-To: <1235441919.4455.68.camel@johannes.local> (Johannes Berg's message of "Mon\, 23 Feb 2009 18\:18\:39 -0800")

Johannes Berg <johannes@sipsolutions.net> writes:

> On Mon, 2009-02-23 at 21:06 +0200, Kalle Valo wrote:
>
>> Also my assumption here is that ieee80211_beacon_loss() should be
>> called only after certain number of consecutive beacon misses. While
>> testing these patches on stlc45xx I used number 10. Can ath9k handle
>> anything like this? Or will it just report each beacon miss
>> individually?
>
> Should the number be configurable? The beacon interval might vary so it
> might be useful to set it so that misses * interval is constant?

Yes, I think so. I decided to omit this part for now and add it later
when we know more how different hardware support it.

>> I don't see a problem. Like you said, such hardware should have beacon
>> checksumming support. Whenever the checksum has changed, the hardware
>> should pass the beacon to the host and mac80211 would receive the
>> beacon just like without beacon filtering. 
>> 
>> Beacon filtering can be thought like filtering unrelevant beacons, but
>> passing through the beacons which have new information. For example,
>> stlc45xx already has beacon checksum support even though it doesn't
>> support 5 GHz band. Unfortunately I haven't managed to find the time
>> to test it yet.
>> 
>> If there is hardware using 5 GHz band and does not support beacon
>> checksumming, then the driver should not even enable beacon filtering.
>
> Should the flag be per-band in that case? 

I would like to see such (in my opinion broken) hardware design first.

> Or do we need checksum support anyway?

My current thinking is that to have proper beacon filtering the
hardware needs to support checksumming. Beacon filtering might work
without checksum support in most cases so that the users won't notice
anything. But from engineer's point of view I don't consider it as
good enough, at least ERP protection changes would end up unnoticed,
and I'm sure there are also other cases.

I don't know how beacon filtering works in wl12xx, I need to test that
soon. It might give some hints how other vendors have implemented
this.

> (Actually, we shouldn't call that checksum support, but 'beacon
> change notification' or something, I guess)

Yes. But I don't think we need to add any checksum support to
mac80211. Apart from mentioning it in the documentation, of course.

-- 
Kalle Valo

  reply	other threads:[~2009-02-24 20:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-23 16:37 [RFC PATCH v1 0/3] mac80211: beacon filtering Kalle Valo
2009-02-23 16:37 ` [RFC PATCH v1 1/3] mac80211: decrease execution of the associated timer Kalle Valo
2009-02-24  2:13   ` Johannes Berg
2009-02-24 18:40     ` Kalle Valo
2009-02-23 16:37 ` [RFC PATCH v1 2/3] mac80211: track beacons separately from the rx path activity Kalle Valo
2009-02-24  2:15   ` Johannes Berg
2009-02-24 18:52     ` Kalle Valo
2009-02-23 16:37 ` [RFC PATCH v1 3/3] mac80211: add beacon filtering support Kalle Valo
2009-02-23 17:47   ` Luis R. Rodriguez
2009-02-23 19:06     ` Kalle Valo
2009-02-23 19:11       ` Luis R. Rodriguez
2009-02-23 19:31         ` Kalle Valo
2009-02-23 19:58           ` Luis R. Rodriguez
2009-02-24  4:46           ` Luis R. Rodriguez
2009-02-24  5:17             ` Johannes Berg
2009-02-24  8:58             ` Jouni Malinen
2009-02-24  2:18       ` Johannes Berg
2009-02-24 20:34         ` Kalle Valo [this message]
2009-02-24  2:20   ` Johannes Berg
2009-02-24  9:01     ` Jouni Malinen
2009-02-24 18:36       ` Kalle Valo
2009-02-24 18:43         ` Jouni Malinen
2009-02-24 19:02           ` Kalle Valo
2009-02-24 18:30     ` Kalle Valo
2009-02-23 17:15 ` [PATCH] stlc45xx: " Kalle Valo

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=873ae3y3ou.fsf@litku.valot.fi \
    --to=kalle.valo@iki.fi \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@gmail.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).