Re: RFC: unified BSS configuration approach

["Tomas Winkler" <tomasw@gmail.com>]

> > B) If we decide to skip this initial sync problems may occur, as
> > initial status of mac80211 and low-level driver may be different.
>
> Hm, true, that could happen. Does it happen in practice though? I can't
> see why a low level driver would decide that it should have short
> preamble or CTS protection on by default. Maybe we should just document
> initial state? Or we can keep the initial call and remove that "don't
> call w/o BSS" restriction instead, which seems saner. We should then
> probably rename reset_erp_info() to reset_bss_info() though.

Yes it happens in practices. I think with short slot.
reset_bss_info() sounds good.

> > C) yet, there is no need to make changes from beacons when we are not
> > associated, as our association may influence the beacons.
>
> Huh, yes, do we do that though? I didn't think we did. Well, we do in
> one way, we set our initial status to whatever we "predict" the settings
> will be when we join the BSS, if that changes we follow all changes. Are
> there any problems with that?
>

We better don't predict, you get beacon or probe response and initiate
association with what is there.

Whit assoc==true all the parameters should be sent to driver at once.

> > D) also, configuration should not be applied to low-level driver while
> > scanning as well, even though beacons/probe responses are inspected.
>
> Hm, good point. But we don't really react to things in other BSSes so
> does it really matter whether we're scanning or not while receiving a
> beacon from our own BSS?
>

Either mac80211 or driver have to be aware that there is scanning and
not changing parameters. during that stage. I will get your own BSS
beacons with the relevant information after scanning so no caching is
needed. Need to be careful though about 11h quite period and channel
switch.

> > E) support to user space configuration is needed, e.g. AP mode
> > (although here we may use the fact that AP mode is always in a kind of
> > "associated" mode)
>
> Yup, so far it's required only in AP mode, is there anything that will
> need this when not in AP mode?

Preamble is usually user configurable feature..

> > 1 - change the original intention of bss_info_changed so mac80211 will
> > be able to set low-level driver in the "init" or "configure" flows as
> > well, not only as BSS is formed or changes
> > 2 - maintain original intention, use "bss_info_changed" only when we
> > want to deliver BSS configuration when we get associate or during
> > association state,  and deliver all initial configuration info through
> > different ops
>
> I prefer the first option since that's essentially just a small
> documentation change and it makes sense. We just should make sure that
> it's called only when the device is started (through ->start()).

what about reset_bss_info() ?

Thanks
Tomas

> johannes
>