linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kalle.valo@iki.fi>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: linux-wireless@vger.kernel.org,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC PATCH v1 3/3] mac80211: add beacon filtering support
Date: Mon, 23 Feb 2009 21:31:10 +0200	[thread overview]
Message-ID: <87bpst7xxd.fsf@litku.valot.fi> (raw)
In-Reply-To: <43e72e890902231111g3705c5bh445e3317de5967f3@mail.gmail.com> (Luis R. Rodriguez's message of "Mon\, 23 Feb 2009 11\:11\:10 -0800")

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

> On Mon, Feb 23, 2009 at 11:06 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
>>
>>> For the case or cards capable of 5 GHz or of HT I believe we should
>>> consider the cases of dealing with DFS or HT channel switch both of
>>> which can occur dynamically while the STAs are associated. If
>>> hardware is capable of differentiating this (through beacon
>>> checksums) then that's an enhancement but for now I suspect that is
>>> not the case for most hardware that implements this and as such for
>>> the case when on DFS or using HT we can simply have mac80211 disable
>>> this. Not sure... Thoughts?
>>
>> 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.
>
> _should_ -- but I don't think this is yet implemented.

This is transparent for mac80211, if that's what you are asking. Even
though the beacon filtering feature is enabled, the hardware can still
send as much as beacons it wants. The most important is that the
driver will call ieee80211_beacon_loss() whenever beacons are lost
because mac80211 will not be following them.

>> 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.
>
> As IEEE-802.11 advances how does the hardware know which IEs to
> checksum or not for? :)

This is what is documented about stlc45xx firmware beacon filtering:

"The LM_PSM_CHECKSUM flag configures the LMAC to calculate a checksum
over the beacon frame body. The checksum is calculated over the
frame-body, starting after the timestamp element. Excluded from the
checksum calculation are all flexible elements, with a corresponding
element ID in the exclude array structure member. The beacon is
forwarded to the application, if the checksum changes from the
previous received beacon."

So the host can just provide the element ids which need to be excluded.

>> If there is hardware using 5 GHz band and does not support beacon
>> checksumming, then the driver should not even enable beacon filtering.
>
> Heh.. umm, I'd like us to add this as a feature eventually too to be
> able to save power but I think we do not checksum and hence my
> comments.

Other option is that the hardware just periodically passes a beacon to
the host, for example every 10 seconds. Not very elegant, but I guess
good enough for certain use cases.

-- 
Kalle Valo

  reply	other threads:[~2009-02-23 19:31 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 [this message]
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
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=87bpst7xxd.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).