From: "Jouni Malinen" <jkm@devicescape.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Rick Jones <rick.jones2@hp.com>,
Christoph Hellwig <hch@infradead.org>,
netdev@vger.kernel.org
Subject: Re: [RFC] Geographical/regulatory information for ieee80211
Date: Fri, 28 Apr 2006 17:31:35 -0700 [thread overview]
Message-ID: <20060429003135.GP31601@instant802.com> (raw)
In-Reply-To: <44501647.8070308@lwfinger.net>
On Wed, Apr 26, 2006 at 07:54:31PM -0500, Larry Finger wrote:
> I don't think it would make that much difference as the user could easily
> lie about their locality and get any set of parameters that they wanted.
Well, not any set.. One of the configured countries, yes, but that is
not same as setting arbitrary TX power limit and allowed channel sets..
Anyway, users should be allowed to move from one country to another and
still being able to use their wlan card (within the limits of the
current location).
> I am leaning toward putting the geographical information into a userland
> daemon. That way we won't have to patch the kernel every time a country
> modifies its regulations. In addition, the kernel will be smaller. The
> downside is that the daemon will have to be updated and supplied in some
> convenient form, perhaps as part of a wireless tools package.
I'm strongly in favor of doing this in user space, too. In order to
provide some control on what end users do with this, I would consider
including a signature on a data file and have the user space tool verify
that signature before accepting the data. This signature need not be
anything extra secure, i.e., it could just be a keyed checksum of the
file using a well-known key. The main point here is that it shows some
attempt on limiting end users from setting random values to regulatory
limits. Of course, if someone really wants to change these values, they
could do so since the source code for the tool would be available and so
would the key used for signing the file in the first place.
I don't know how secure a system would be needed to pass requirements
that FCC and similar organizations place on wireless devices. I would
like to handle this with fully open source tools and having some kind of
simple signature on the data file would be good starting point. It is up
to vendors then to decide whether they are fine with such a mechanism or
whether some additional tool (like the Intel plan on using a closed
source user space tool) would be needed on top of this.
--
Jouni Malinen PGP id EFC895FA
prev parent reply other threads:[~2006-04-29 0:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-14 0:59 [RFC] Geographical/regulatory information for ieee80211 Larry Finger
2006-04-14 11:41 ` Ulrich Kunitz
2006-04-14 11:58 ` Faidon Liambotis
2006-04-14 15:27 ` Jouni Malinen
2006-04-14 20:01 ` Larry Finger
2006-04-15 17:07 ` Faidon Liambotis
2006-04-15 17:47 ` Christoph Hellwig
2006-04-17 17:55 ` Rick Jones
2006-04-27 0:54 ` Larry Finger
2006-04-28 11:17 ` Harald Welte
2006-04-29 0:31 ` Jouni Malinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060429003135.GP31601@instant802.com \
--to=jkm@devicescape.com \
--cc=Larry.Finger@lwfinger.net \
--cc=hch@infradead.org \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).