internal wpa_supplicant frequency and channel issues

Dan Williams dcbw at redhat.com
Sun Nov 26 11:19:40 EST 2006


While working on the wpa_supplicant + NetworkManager interaction over
the DBus interface this week (the light at the end is bright), I came
across three issues, one old and two new:

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?

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.

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?

So:

- 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?
- If not, what unit should be "standardized" on internally in
wpa_supplicant in the future?
- Either way, a mapping table is needed.  What bands other than BG and A
need mappings, if any?

Thanks,
Dan





More information about the HostAP mailing list