Stuffed Crust wrote:
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
This can be accomplished by passing a static table to the
register_wiphy_device() call (or perhaps via a struct wiphy_dev
parameter) or through a more explicit, dynamic interface like:
wiphy_register_supported_frequency(hw, 2412).
For completely programmable hardware, the stack should interact with a
module like ieee80211_geo, to help ensure the hardware stays within
legal limits.
While there is much to debate about where to draw the functionality
line, completely programmable hardware is the norm these days.
... and said code would be responsible for driving the scanning state
machines, and also for more esoteric functions like handling RADAR
traps, automatic channel switching, etc.
Handling scans is quite interesting -- I've seen hardware which requires
manual channel changing (including full RF parameter specification),
host timing for the channel dwell time, and manual probe request
issuance.. and on the other end of the spectrum, a simple "issue scan"
command that takes few, if any, parameters.
And unfortunately, many things in between.
This leads me to belive that the internal scan workflow should work
something like this:
* Userspace app issues scan request (aka "refresh AP list")
* Knowing the hardware frequency capabilities, the 802.11 stack applies
802.11d and regdomain rules to the available frequency set, and
issues multiple internal "scan request" commands to the hardware
driver. (eg "perform an initial passive sweep across the entire
2.4G band", "perform an active scan on frequencies 2412->2437
looking for ssid "HandTossed", "perform an active scan on
frequencies 5200-5400 looking for ssid "HandTossed", etc)
(note that ideally, userspace apps/libs would be at least partially
aware of 802.11d rules, but the kernel must do the RightThing if
told to "scan all available channels for any access points")
* The hardware driver takes this scan request, and maps it into the
capabilities of the hardware:
Hardware A: (very thin MAC)
- Using library code, generates an appropriate probe request frame,
translates it into a format the hardware expects/needs,
and schedules it appropriately.
- Loops through the frequency set specified, and for each:
- Issues a channel change command
- Immediately transmits the probe request (for active scans)
- Dwells for an appropriate time
- RX'ed beacon/probe response frames come down as regular 802.11
frames into the stack
- Moves to the next channel
Hardware B: (thinner MAC)
- Using library code, generates an appropriate probe request frame,
and translate it into a format the hardware expects.
- Program the probe request frame into the hardware as a probe
template.
- Loops through the frequency set specified, and for each:
- Issues a channel change command
- Wait for a scan complete signal
- RX'ed beacon/probe response frames come down as regular 802.11
frames into the stack
- Moves to the next channel
Hardware C: (thick MAC, ala prism2 or prism54)
- Issues a hardware "scan request"
- Waits for the hardware to signal "scan complete"
- Requests hardware scan results
- For each scan result, the hardware returns:
- Translate result into an 802.11 probe response frame and
pass down the regular RX path.
So as you can see, I think the channel iteration, dwell, etc should
be performed by the hardware driver itself, as the variation at the
logical "tell the hardware perform a scan" step is so extreme.
* Meanwhile, the 802.11 stack is receiving the beacons/probe responses
from the hardware via the regular rx path. It diverts these (and
other 802.11 management/control) frames, decodes them, and then adds
them to the stack's internal list of available stations, updating any
internal states/counters as necessary. (These frames could also be
echoed to a special netdev interface if desired)
(stuff like detecting an AP going away depends on us noticing a lack
of beacons arriving, for example. Most hardware does not
notify us of this event. Likewise, we should expire other
APs from our list if they go away.. etc. For AP operation we need
to maintain this STA list, period -- so why not use it across the
board? But this is another discussion for another time..)
* The 802.11 stack issues a MLME-Scan-Complete notification to
userspace.
* Interested userspace apps see this event, then query the
scan results and presents them to the user in some pretty format, or
alternatively perform automatic roaming based on scan results.
The above is a great synopsis but there is more. For example to support
roaming (and sometimes for ap operation) you want to do background
scanning; this ties in to power save mode if operating as a station.
Further you want to order your channel list to hit the most likely
channels first in case you are scanning for a specific ap--e.g. so you
can stop the foreground scan and start to associate. In terms of beacon
miss processing some parts have a hardware beacon miss interrupt based
on missed consecutive beacons but others require you to detect beacon
miss in software. Other times you need s/w bmiss detection because
you're doing something like build a repeater when the station virtual
device can't depend on the hardware to deliver a bmiss interrupt.
Then of course there's whole issue of interacting with firmware-based
cards that have limited and/or funkiness in their scanning support.
Scanning (and roaming) is really a big can 'o worms.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
