On Mon, Feb 23, 2009 at 11:31 AM, Kalle Valo <kalle.valo@xxxxxx> wrote: > "Luis R. Rodriguez" <mcgrof@xxxxxxxxx> writes: > >> On Mon, Feb 23, 2009 at 11:06 AM, Kalle Valo <kalle.valo@xxxxxx> 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. Sure. My concerns was if drivers should enable/disable the flag dynamically based on configuration. If hardware supports checksumming as the one you are working with does then you are set, however if it is not then essentially we either do not support this flag for those type of devices that do not support checksumming _or_ we consider the cases where this can be disabled dynamically depending on the configuration (DFS, HT). If we do support dynamic tuning of this variable due to different type of connections to APs (DFS or HT) it might make sense to just have a separate flag to indicate this and let mac80211 figure things out for you. This is what I was getting at. >>> 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. This is nice :) >>> 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. Not good enough for DFS and not sure about HT as per the spec. I think its easier to not enable this when on DFS channels or connecting using 11n. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
