internal wpa_supplicant frequency and channel issues

[Jouni Malinen]

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.

> 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 ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA