> Well. You need to consider more than just this. I have a feeling you're
> only considering fixed channel use cases. But if we configure HT40+, and
> then find a peer on a channel that may only use HT40-, then what?
Good point. But still i think this is the same case. Right now, the card would
still be set into HT40+, regardless of the frequency. Then, minstrel_ht would
just use HT20, i suppose.
My proposal would be making the HT iw argument non-advisory: Use it when
creating a network, discard it when joining one.
I also will do some refactoring in nl80211.c in order to check main and
extension channel.
> > - If HT has been configured through iw and a non-HT network is to be
> > joined, iw's HT setting is used and announced.
>
> This isn't possible, you might join a network on a channel that doesn't
> allow HT40+ for example.
Of course it must be checked.
It has to be checked even when joining HT networks.
E.g. a european user travels to America and opens an HT+ Network on
channel 9. The american card should disable HT40+.
On Fri, 2011-04-29 at 14:36 +0200, Alexander Simon wrote:
> - If HT has been configured through iw and a non-HT network is to be
> joined, iw's HT setting is used and announced.
This isn't possible, you might join a network on a channel that doesn't
allow HT40+ for example.
johannes
Sorry for replying to myself but i'll try to explain this a little bit
easier:
- If the channel is not *fixed*, the channel type is only advisory.
This means that a merge of two HT40 networks with fixed channels will
only take place if the HT40 configuration equals.
- When merging, the looser will obey the winner's HT configuration if
there is one. If not, keep the old one.
- If HT has been configured through iw and a non-HT network is to be
joined, iw's HT setting is used and announced.
HT configuration within an IBSS may get inhomogeneous as a HT station
may join from a non-HT beacon but there are other HT members.
- When receiving a different HT configuration from another member of our
BSSID, use this configuration (first beacon wins)
Alex
On Fri, 2011-04-29 at 06:54 +0000, Alexander Simon wrote:
> > Well. You need to consider more than just this. I have a feeling you're
> > only considering fixed channel use cases. But if we configure HT40+, and
> > then find a peer on a channel that may only use HT40-, then what?
>
> Good point. But still i think this is the same case. Right now, the card would
> still be set into HT40+, regardless of the frequency. Then, minstrel_ht would
> just use HT20, i suppose.
>
> My proposal would be making the HT iw argument non-advisory: Use it when
> creating a network, discard it when joining one.
Yeah it would be an option to just always join as HT if HT is available,
but not create as HT unless asked.
johannes
> Yeah it would be an option to just always join as HT if HT is available,
> but not create as HT unless asked.
Ok. I just had a few thoughts about this:
This way an ht ibss has to be created from a (patched) mac80211 HT
hardware. There would be no way to "convert" an existing g network into
n.
Additionally, if a non-ht implementation joins the network, it will
advertise it as non-ht. If a second ht-station joins from one of these
beacons, it won't use ht.
This way a single non-ht station could destroy a ht ibss.
I Think the best way to go would be to obey HT information when joining
HT but using the HT iw parameter when joining non-ht.
Then we could have the following scenario: Non-HT station A creates
non-HT.
HT station B joins and sets HT- (from iw). HT station C joins from A but
doesn't see B. It's iw parameter says ht+.
But when B comes closer to C do a "HT merge", comparing TSFs.
Conclusion:
- Create an ibss with the iw parameter
- When joining a ht ibss, use its parameters
- When joining non-ht, add ht from iw parameter
- When encounter a different ht config, do a ht merge.