Subject: Re: slashdot on 'OpenBSD Activism Shows Drivers Can Be Freed'
To: None <dyoung@pobox.com, tech-net@NetBSD.org>
From: List Mail User <track@Plectere.com>
List: tech-net
Date: 11/03/2004 08:47:31
	Dave Young,

	Sorry for taking a day, but I've been busy and didn't immediately
notice you comments.  While I agree with many of your points, you have made
at least a few errors in the last few couple of days;  As an example of the
FCC specifically requiring a manufacturer to "restrict" software and drivers
(NOTE: this IS an Atheros chip in question - in fact its an outstanding
NetBSD PR) look at the documents (on the FCC site):

	https://gullfoss2.fcc.gov/prod/oet/forms/blobs/retrieve.cgi?attachment_id=388828&native_or_pdf=pdf

	https://gullfoss2.fcc.gov/prod/oet/forms/blobs/retrieve.cgi?attachment_id=388829&native_or_pdf=pdf

and
	https://gullfoss2.fcc.gov/prod/oet/forms/blobs/retrieve.cgi?attachment_id=388750&native_or_pdf=pdf

	Also as a counter example to manufacturer calibrating in "absolute"
units;  Here is a diagnostic dump of the calibration information from a
Proxim 8571 access-point (Atheros 5210 - i.e. 5000 family).  Note: the data
is contained within each card's individual EEPROM (it varies across different
individual units).  Also, this AP can put the card into "loopback" mode,
recalibrate itself (I'm not sure how accurately) and rewrite the data in
the EEPROM.  Also, changing the reguatory domain results in rewriting the
calibration data in the EEPROM (when the "proper" sequence of commands is
executed).

Regulatory Domain:  0x10
Regulatory Domains Calibrated into EEPROM
        RD 0: 0x10      RD 1: 0x40      RD 2: 0x30      RD 3: 0xFF

=============================Transmit Power Table==============================
 Channel |    5.18    ||    5.21    ||   5.24     ||    5.27    ||    5.31    |
=========|============||============||============||============||============|
  3 dBm  |pc 63  gf 26||pc 63  gf 25||pc 63  gf 26||pc 63  gf 26||pc 63  gf 24|
  5 dBm  |pc 63  gf 26||pc 63  gf 25||pc 63  gf 26||pc  1  gf  3||pc  1  gf  1|
  7 dBm  |pc 63  gf 16||pc 63  gf 16||pc  1  gf  0||pc  2  gf  0||pc  2  gf  0|
  9 dBm  |pc 63  gf 26||pc  1  gf 10||pc  2  gf 10||pc  3  gf  8||pc  4  gf  5|
 11 dBm  |pc  1  gf 13||pc  2  gf 13||pc  3  gf 12||pc  5  gf 12||pc  7  gf 10|
 13 dBm  |pc  2  gf 16||pc  3  gf 16||pc  6  gf 17||pc  8  gf 16||pc 11  gf 14|
 15 dBm  |pc  4  gf 21||pc  6  gf 21||pc  9  gf 21||pc 12  gf 21||pc 17  gf 20|
 17 dBm  |pc  7  gf 26||pc 63  gf 25||pc 63  gf 26||pc 63  gf 26||pc 63  gf 24|
 19 dBm  |pc 63  gf 26||pc 63  gf 25||pc 63  gf 26||pc 63  gf 26||pc 63  gf 24|
 21 dBm  |pc 63  gf 26||pc 63  gf 25||pc 63  gf 26||pc 63  gf 26||pc 63  gf 24|
 23 dBm  |pc 63  gf 26||pc 63  gf 25||pc 63  gf 26||pc 63  gf 26||pc 63  gf 24|
 rate36  |  pcdac  0  ||  pcdac  2  ||  pcdac  3  ||  pcdac  6  ||  pcdac  8  |
 rate48  |  pcdac  0  ||  pcdac  0  ||  pcdac  1  ||  pcdac  3  ||  pcdac  5  |
 rate54  |  pcdac  0  ||  pcdac  0  ||  pcdac  0  ||  pcdac  1  ||  pcdac  2  |
 RD 0    |  pcdac  6  ||  pcdac  8  ||  pcdac 13  ||  pcdac 17  ||  pcdac 22  |
 RD 1    |  pcdac  1  ||  pcdac  3  ||  pcdac  5  ||  pcdac  8  ||  pcdac 10  |
 RD 2    |  pcdac  1  ||  pcdac  3  ||  pcdac  5  ||  pcdac  8  ||  pcdac 10  |
 RD 3    |  pcdac  0  ||  pcdac  0  ||  pcdac  0  ||  pcdac  0  ||  pcdac  0  |
=========|============||============||============||============||============|

	the table above was generated by the diagnostic firmware in the
AP unit, but I can decode the same information by reading the EEPROM on a PC.
(Sam's statement is quite correct, these chips are very easy to reverse-
engineer) The newer 500x families, for x>=1, families use a different format
and calibrate to many more frequencies, but basically are similar.

	These are definitely not unit-less numbers!

	Please understand, I believe your statements are generally correct,
just that you have over-generalized many of the fine points (and I do think
a company has the right, though possible mistaken, to protect their intellectual
property in any fashion which they see fit to).

	Paul Shupak
	paul@plectere.com