Re: wireless: recap of current issues (configuration)

From: Sam Leffler
Date: Sun Jan 15 2006 - 14:53:50 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/