On Thu, Oct 9, 2008 at 11:54 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2008-10-08 at 10:33 -0500, Nils Bagge wrote: >> My humble opinion is yes, the HT capabilities field should be constant, >> from the perspective of a typical AP. > > Yeah I totally agree. > >> Practically speaking, I doubt that an AP would want to toggle SM power >> save at all, let alone on a per-beacon basis, as historically power >> consumption is not as critical at the AP vs. at the client. > > True. > >> But, if you want to be 'green'... (I can see how this would benefit a >> 'low power AP') The only problem I see is with the AP entering 'static >> SM power save'. You might run into interoperability trouble with varying >> behavior of client STA's, due to different interpretations of the >> standard or assumptions. It wouldn't surprise me if some clients ignore >> changes to the HT capabilities IE once associated, or if some ignore the >> SM power save field in beacons entirely. Hence, they could transmit a >> 2-stream MCS which would not be decodable with a single RX chain. >> >> Theoretically, the only SM power save mode I'd recommend for an AP is >> dynamic SM power save. I would say that recommended mode is SM disabled, Dynamic only in case u want to be green. > Right, but if you enter dynamic SM PS then it doesn't matter much > anyway, does it? I mean, there's no protection requirement in that case, > is there? Or am I reading it wrong? I _think_ I will handle the SM PS > change in mac80211, but I'm not entirely sure right now. If AP announce dynamic it requires STA to precede SM packet with legacy one preferable RTS. See the iwlagn implementation Tomas -- 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
