On Thursday 13 May 2010 06:02:23 Benoit Papillault wrote: > > Also I just noticed that there's a TODO item in rx.c when we receive an > > HT frame from a peer we don't know about yet. Not sure what to do there, > > but you'll need to look at it. > > I did some patch in this area in my tree. Basically, the peer STA is > created only on beacon/probe response since only those frames contains > peer capabilities. Any frames received before is simply ignored. i think the same applies to non-HT. when we receive a frame from a STA we haven't seen a beacon from yet, we just mark the rate at which we received the frame and can use that for a reply. later, when we receive a beacon, the rate- set is updated. i guess the same can be done for HT and i'd argue that it should be done like this in order to be able to communicate even though we have not received a beacon from that particular STA yet - there are some reasons why the beacon might not have reached us: * the STA might have deferred beacon sending for a few intervals as part of the normal beacon backoff * the beacon might have been lost due to interference * or the other STA might be a buggy implementation which doesn't send IBSS beacons for a while, like some madwifi versions. in any case the ability to communicate is more important than a complete rate- set... bruno -- 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
