internal wpa_supplicant frequency and channel issues

[Dan Williams]

On Sun, 2006-11-26 at 09:11 -0800, Jouni Malinen wrote:
> On Sun, Nov 26, 2006 at 11:19:40AM -0500, Dan Williams wrote:
> 
> > 1) The old issue: was there any consensus on how to specify the
> > frequency you wish to tie the card to in the config?  This is a problem
> > for fixed frequency and for IBSS configurations as cards do not always
> > just choose a channel for you in IBSS mode.  I had posted a patch to add
> > a "frequency=" config option, but there were objections that using
> > channel #s was preferable.
> > 
> > What was the decision here?  I'll do that patch either way, but if we
> > use channel #s, the we have to have a channel <-> frequency mapping
> > table somewhere in wpa_supplicant or hostapd.  I'll do that too, but
> > somebody (jouni?) _please_ make decision here.  If we do decided on
> > channel #s, then is there anything besides the BG and A channel sets
> > that I need to have a mapping table for?
> 
> Thanks for bringing this up again. I ended up just using the frequency
> as in your patch since it is more convenient way of doing this for now.
> Channel number is not a unique identifier and it would require
> <hw_mode,channel> type of pair. In addition, the version I applied does
> not override frequency from scan results and only uses the configured
> parameter for IBSS/adhoc case. In other words, it is the initial channel
> for IBSS networks and it is only used by the creator of that network.
> 
> By the way, there is already hw_mode,channel <-> frequency mapping in
> hostapd. That happens to be using a table, but it is also doable with a
> simple function for most commonly used channels.
> 
> > 2) New issue #1: the WEXT driver doesn't support channel #s returned
> > from the card's driver.  ipw*, for example, returns the channel number
> > rather than the actual frequency.  This appears to be legal with WEXT.
> > To determine whether or not a channel # was passed, check that the
> > exponent is 0.  If so, it's a channel.  This means that wpa_supplicant
> > is not getting the right frequency information for scanned access points
> > at least with ipw* cards.  That's an easy fix, but again, it requires a
> > channel <-> frequency mapping table somewhere in wpa_supplicant.  I can
> > do that patch once we decided on a consistent strategy for chan/freq.
> 
> That is broken since channel number is not a unique identifier for the
> channel (e.g., channel 8 can be either IEEE 802.11b/g or IEEE 802.11a
> channel..). In this case, I would assume that the card is 802.11b/g
> only and map the channel to frequency with 2407+channel*5 in
> driver_wext.c. Untested version is in CVS now.

Any way to pull changes from CVS anonymously so I can test this? :)

Dan

> > 3) New issue #2: What unit do we standardize on in wpa_supplicant, or do
> > we support two?  For example, the DBus interface currently pushes the
> > 'frequency' item back to callers.  Either we pick one of [channel |
> > frequency] and expect the caller to do the mapping to whatever unit they
> > desire, or we could push _both_ frequency and channel over the various
> > control interfaces.  I vote for _one_ unit, but what unit is that?  Do
> > we do conversion at the boundaries (ctrl interfaces and config file) or
> > should wpa_supplicant be consistent internally?
> 
> Frequency is the only reasonable choice for one unit case since channel
> number would require hw_mode (802.11g or 802.11a). Though, even
> frequency number alone does not include all cases (proprietary
> extensions like Atheros Turbo modes may use the same frequency as a
> standard channel). Anyway, I would use frequency for now.
> 
> I would not be too surprised if at some point there will be conversion
> code allow <hw_mode,channel> to be used and mapped internally in
> wpa_supplicant in ctrl and config interface.. Driver interface will also
> likely provide both frequency and hw_mode,channel like it already does
> for set_channel handler.
> 
> > - Should _both_ channel and frequency be allowed options at the
> > boundaries? (config file, ctrl interfaces)
> > - If not, what unit should be allowed at the boundaries of
> > wpa_supplicant?
> 
> At the moment, only frequency. In future, likely both (with channel
> replaced by hw_mode,channel).
> 
> > - If not, what unit should be "standardized" on internally in
> > wpa_supplicant in the future?
> 
> At least for now, just frequency. If we need to add support for
> something that requires more (Turbo modes, half-channels, etc.), it will
> be dealt with later.
> 
> > - Either way, a mapping table is needed.  What bands other than BG and A
> > need mappings, if any?
> 
> For now, only the IEEE 802.11b/g channel from scan results is mapped to
> frequency and that is done without a table ;-).
>