On Fri, 2013-08-16 at 15:36 +0200, Simon Wunderlich wrote:
> Hmm ... changing HT40+/- can only be represented by using either ECSA (which i did not
> implement) or secondary channel offsets in action frames (which comes in a later
> patch, but could be merged ...). Secondary channel offsets are not allowed in
> beacon/presp, and therefore the client would keep the current mode (HT40+ or HT40-)
> as announced in the HT IEs of the beacon/presp. If I add support for secondary channel
> offsets in the action frames, the beacons and action frames would contradict, and that
> would not be good either.
>
> So I thought it is easier to forbid this case and avoid this mess. :)
Oh, hmm. ok.
> > And why disallow switching bandwidth (was above this code)? That doesn't
> > seem right either?
>
> IEEE 802.11-2012 10.9.8.3 says:
>
> "A 20/40 MHz IBSS cannot be changed to a 20 MHz IBSS, and a 20 MHz IBSS cannot be changed to a 20/40 MHz IBSS."
Interesting, I wonder why they say that.
> Also I don't want to allow to switch to a 5 MHz/10 MHz channel or other funky stuff.
Obviously.
> TBH I don't understand the TSF magic completely, but as far as I know it is
> used for IBSS cell merging. What we don't want is to change the tsf when
> generating the new beacon and therefore (accidently) kick of some merging process.
> Therefore I'm keeping the TSF just as in ieee80211_sta_join_ibss().
>
> ieee80211_ibss_build_presp() needs to put in the beacon, so I need to supply some
> valid TSF, don't I?
Doesn't make much sense - the host can't put the TSF into the frame
accurately anyway so the device should be doing it ... anyway I guess
you're not changing this so let's not discuss it here.
> > > +static void ieee80211_ibss_disconnect(struct ieee80211_sub_if_data *sdata)
> > > +{
> >
> > Is this some refactoring that should be separate? I don't see how it's
> > really related to CSA? Maybe I'm missing something?
>
> The only relation is that I need it refactored for IBSS/CSA. Disconnecting for
> some reason and going back to search mode wasn't required so far.
>
> I can put that in a separate patchset.
Please do. I also might have to make a patch to add some new driver API
and this would probably help there as well as making this particular
patch easier to read.
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
