Dan Williams wrote:
On Fri, 2006-05-05 at 15:14 -0500, Larry Finger wrote:
Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on
those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis,
Jouni Malinen, and Harald Welte. The important points of my proposal are as follows:
* The database will be maintained as a text file to be processed by a userland daemon that will
transform this database into the data structure needed by the ieee80211 code. In addition to the
regulatory data, this file will also contain the information needed for the daemon to set the size
of its data arrays dynamically.
Can you explain a bit more about the dynamic array aspect here? What's
that about? Shouldn't the geo-daemon be able to figure this stuff out
automatically and tell the ieee80211 stack how many countries and groups
there are? It has to parse the file anyway, so it should surely know
how many groups and countries there are after parsing it. (or do I just
not understand the issues...?)
The kernel only has a single geo object for each wireless interface initialized. The kernel routine
would state which country it wanted to the daemon, which would supply that one from the entities
created one when if parsed the database file. The dynamic aspect is to code the daemon in such a way
that changing the number of countries and/or groups will not necessitate changing the code in the
daemon.
* A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo
structure into the kernel. Information passed to the daemon will be the country code in ASCII and
whether the interface is to be used indoors or outdoors.
* Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit
anyone with moderate skills from hacking the channel/power settings, but such hacking will require
some effort.
What I'm concerned about is error reporting. And as a distro packager,
I don't want any user to have to touch the geo file. That's fine if
they do, but nobody should _have_ to.
I agree.
For error reporting, if the geo file does not exist, or contains invalid
information, or if the checksum doesn't match for some reason, what's
the failure case? It's not sufficient to just log that to dmesg and
fail the attempt, because then a program like wpa_supplicant or
NetworkManager will have no clue what the problem is if the driver just
returns ENOENT or EFILESUCKS or whatever. This is the same problem we
currently have with missing firmware. The failure case is not clearly
recognizable by the client.
I plan to put the "unknown country" data into the init_geo routine. In case the geo database is not
available, has been corrupted, or the daemon is not running, the parameters will be the minimal set
of only bg channels 1-11 at minimum power and indoor usage. There would be a valid set of geo
parameters in the ieee80211 structure - likely not the ones that were wanted, but a valid set. In
addition, a failure code would be sent back to the driver, and the exact reason for the failure
logged to dmesg.
If the geo data fails to be read, or fails to be validated by the
driver, user apps that are trying to make connection attempts need to
know exactly why the attempt failed, so they can inform users of the
failure in a smart way. That information needs to come through the
driver, because user apps that make network connection attempts
shouldn't have to talk to the regulatory daemon _at all_.
Agreed.
Conceptually, the regulatory/geo daemon is part of the kernel and the
driver, and just happens to live in userspace because policy
+kernel==ohmygodbad. But that means that it's the kernel's
responsibility to marshal the error information back to clients of the
wireless driver, not the clients problem to ask the regulatory/geo
daemon, if it's actually running, what the heck the problem is and why
the driver returned the error code it did.
U NetworkManager geo-daemon
------------|-----------|-----------
K | |
driver/iee80211
Think of it as a V, not a triangle. That's where we need to be WRT
error reporting.
I'm not sure what additional error reporting mechanisms could/should be
implemented. Any suggestions?
Larry
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
