Hi Pat, On Sat, 2009-08-01 at 19:55 -0400, Pat Erley wrote: > I've been kicking around the idea of attacking the addition of the > ability to set non 20MHz channels to the mac80211 stack. I've come up > with 2 potentially un-intrusive ways to do this, but before starting, > I'd like to get a touch of discussion on which way would be > preferred/acceptable upstream (if any are). > > > 1. Extend nl80211_channel_type to have values for the other channel > bandwidths we want to support. > > Maybe something like NL80211_CHAN_NO_HT_5 for 5MHz, etc. > > This is the option I like least and have put the least thought into. Personally, it's the option I like most, combined with registering, for each channel, which channel widths are supported on it. > The upside to this is, it'd be the least intrusive into the actual > code, with the downside being, that enum is currently really more > aptly named nl80211_ht_channel_type, and as such, pretty much > everywhere it's used currently would have to test to see if ht is > supported, and if it is, if the current ht mode is supported, but > also, if it's not NO_HT, if it's a non-standard channel width. You're right that it currently is mostly about HT, but I don't see why all this testing should be necessary. I'd just use the managed mode interface flag IEEE80211_STA_DISABLE_11N. > With this route, setting the channel width would be done something like: > iw dev <devname> set width <width in MHz> > or maybe > iw dev <devname> set freq <freq in MHz>[@<width in MHZ>] I don't like the technicalities of this, I think that the channel width should be set with the "connect" call. Of course, it has to be supported here as well, for monitor purposes, but shouldn't be required here. > > -- Problems common to both -- > > In the beginning, I think that leaving the supported channels static > to whatever operating band the card is in, is fine. Yes, going to > 10MHz channels would double the number of available channels in a > band, but with the absolute lack of hardware(AP/Router) that supports > it, having a pre-set double sized channel list seems pointless. I > suspect most people who would use this would want to set center > frequency anyways, rather than specific channel, but that's another > can of worms. Also keep in mind that there _are_ standard uses for smaller bandwidth channels, Jouni has helpfully collected them on http://wireless.kernel.org/en/developers/Documentation/ChannelList > Another problem, odd channel width channels. With a 5MHz channel, > would you do center freq +/-2.5MHz, or center freq +2/-3MHz/etc? Or > maybe limit the problem to only even channel widths? I don't think even channel widths can work, since we really do need 5 MHz :) But it shouldn't be that much of a problem, we already use KHz in a number of places. > Next problem, background scanning. I think that disabling background > scanning when not operating in a standard frequency would be a 'good > thing', as all of the applications I can think of that would use this > are cases where scanning isn't really necessary. I could go either > way on this topic though. We don't have any background scanning. > Final problem, HT channels. I think that channel bonding should be > mutually exclusive with non 20MHz channels. In theory, bonded 10MHz > channels could provide better throughput than a single 20MHz channel, > due to the ability of a 10MHz channel to get above the noise floor at > a distance, but again, this seems like the amount of work to implement > would grossly increase the complexity of the problem. Maybe this is > something that should be left up to drivers as to if they can support > it. I can agree with this -- I think "HT" should be left reserved for real HT, that is 20 or 40 MHz 'channels', where 40 really is bonding as you say. So let me outline how I'd handling this, by extending the flags instead of using a bandwidth number. The first thing I'd do is start with some cleanup -- remove the 'max_bandwidth' member from struct ieee80211_channel, it's used only write-only in a few places afaict. In fact, I'm happy to do that unrelated to this work. The second thing I'd do is refactor the use of IEEE80211_CHAN_NO_HT40*, remove that from the flags field (maybe making the flags field a u16) and introducing a new "types" field, which would take a bitmask of BIT(NL80211_CHAN_*) values. This would have to be set to default to BIT(NL80211_CHAN_NO_HT) or, if HT is supported, BIT(NO_HT) | BIT(HT20) | BIT(HT40+) | BIT(HT40-) and would also need an orig_types field, and then regulatory code removes the bits from "types" as appropriate, leaving them in "orig_types" for future regulatory changes. Just like "flags" works. Note that the default value for types should be applied if, and only if (!), the types field is set to 0 (i.e. unset) by the driver. IOW, cfg80211's channel checking loop in wiphy_register() would get this code: if (!sband->channels[i].types) { sband->channels[i].types = BIT(NL80211_..._NO_HT); if (sband->ht_cap.ht_supported) sband->channels[i].types |= ...; } Third, the channel type needs to be a bit more pervasive. As a start, I'd start with adding it to connect(), ibss_join() (maybe) and set_channel() commands. This mostly involves cfg80211 and mac80211, but not all the full-mac drivers since they don't support anything other than NO_HT yet (which should probably be renamed to 20MHZ). This would already have one good thing: it would give us the ability to request, from userspace, to disable HT40 and/or HT40, by passing: - no flags: automatic, use all - HT20: no HT40 permitted (don't think we can _force_ ht20?) - NO_HT: no HT permitted This is a little strange though, but at least NO_HT would be easy by setting IEEE80211_STA_DISABLE_11N, maybe reject the others for a start. This is validated against the channel you're using, of course, in the cfg80211 SME etc. One other thing that would be necessary is adding channel type to scan results, I guess? Then, finally, I'd add a new channel type, NL80211_CHANNEL_TYPE_5MHZ. Document it to imply that HT is being turned off, of course. Now this bit should be really simple. I don't think the 'specify bandwidth' instead of using flags really gains you much in this process? Mind you I'm not nailing down that process now, it's just how I'm currently thinking about it. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
