On Thu, 2011-11-17 at 00:38 +0100, Dmitry Tarnyagin wrote: > I think I need to add more comment in the logic :) Please :-) > Idea is to fill beacon ies of incoming unknown probe responses with > existing, but possibly incorrect information from aliases and replace > it when and if the real beacon comes. Hm ok I guess that makes sense. > Then, addressing the first scenario: > 1a. There is a beacon bss entry in the list and a probe response is coming > Probe resp is filled with beacon ies and contains complete set of IEs. > Existing beacon bss entry is not updating to keep consistence of rb > tree. > 1b. There is a probe response bss entry in the list and a beacon is coming > The beacon updates the probe response with its ies. > > Second: > 2a. There is an existing entry in the list with a whole set of ies and > a new beacon comes > The beacon starts a new bss entry. The old one is getting expired soon. > 2b. Same, but a new probe response comes > It starts a new bss entry with inconsistent set of ies. After > reception of an updated beacon the inconsistence is getting fixed. The > old entry is getting expired soon. > > Third: > Similar to second, but old entry does not expire. Ok. I'm not sure I follow, need to take a closer look at the code I guess ... johannes -- 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
