FCC's WiFi Rule-Making: Making It Fair For Both Open Source and Proprietary (fcc.gov)
Bruce Perens writes: The FCC wants to be sure that WiFi drivers don't cause interference with airport weather radars, but their proposal to lock down WiFi firmware, won't fly. Many commenters in the proceeding have made it clear that Open Source firmware for WiFi devices must remain legal. While an "alternative" proposal to the FCC that would require that all WiFi routers be Open Source is getting most of the publicity today, I have proposed another alternative that would be fair for both Open Source and proprietary software. It requires approval of the source code of a WiFi driver by a person with a technical license from FCC, the GROL+Radar, if that driver is to be mass-distributed in binary form for use by RF-naïve users by either the manufacturer or Open Source. The license assures that the responsible person actually understands how to protect radar systems in a WiFi driver. It's pretty easy for someone competent in radio engineering to pass the license test, and many thousands of people hold the license today. Vendors and Open Source are treated the same. It doesn't place restrictions on testing and development, or conversion of WiFi equipment to other radio services. And it includes an explanation of the problem, for those of you who don't know what the uproar is about.
Bruce,
Is it your experience that people at the FCC even understand what Open Source is and that not all software is made by some huge entity like Microsoft and Adobe? It seems to be in my travels there are so many people making important decisions on the governmental level that either don't care about the greater Open Source community because of close ties to big corporations or don't have the background to understand why open software is important.
If someone is interfering with a licensed station, why doesn't the FCC investigate the source of the interference? In the old days, if you were being a nuisance to a licensed station, you were in for a world of hurt if being intentionally malicious. At the bare minimum, and idiot user would have had their equipment confiscated for being clueless.
Is it too hard for them to actually go out and do the one thing they unquestionably have the authority to do? Or is this just another power grab by the FCC and the administration to quash tech freedom wherever they see fit in the name of "safety".
Have you heard about the airplanes dropping out of the sky because "Mom's WiFi" ruined the weather forecast?
Have you heard about government bureaucracies that constantly seek to expand using the flimsiest of justifications to increase their power?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
The GROL is not for just transmitting- that's a restricted license - the GROL is required to "... to adjust, maintain, or internally repair FCC licensed radiotelephone transmitters ..."
Terminal Doppler weather radars (TDWRs) are installed at about 40 major airports. They operate in the 5 GHz range and are used to detect things like wind shear and microbursts, which are dangerous to aircraft. The higher resolution than the WSR-88D (Nexrad) radars probably makes it easier to detect these features. Also, if the nearest WSR-88D is a significant distance away from the, the beam will be significantly above the ground over the airport. Interference from wi-fi isn't an issue for the WSR-88D radars because they operate around 2.7-3.0 GHz.
As I understand it, the 5 GHz band used for wi-fi systems is shared with TDWRs. This allows wi-fi to operate on TDWR frequencies in areas where there isn't a TDWR using that frequency. Wi-fi equipment is required to detect when a TDWR is operating and, upon detection, switch to another frequency to avoid interference. There have been quite a few enforcement actions by the FCC for wi-fi interfering with TDWR operation: https://www.fcc.gov/encyclopedia/weather-radar-interference-enforcement.
M-I-Z
kU still sucks!
These radars are used to detect hazardous weather, not aircraft. There are about 45 terminal doppler weather radars installed in the US, which share the 5 GHz band with wi-fi. They are primarily used to detect wind shear and microbursts, which are dangerous to aircraft.
M-I-Z
kU still sucks!
Dear Bruce:
...which is why I have tried to initially limit the call to merely opening up the binary blobs going into wifi, particularly as getting the current 802.11ac trends towards doing so have failed so dismally and wifi far less safety critical than many other things.
In your slashdot posting today you mischaracterized our efforts as attempting to "open source" all routers. (as have multiple other reporters and people)
I lost sleep for years trying to create a third not "open source" or "closed source" *option* for making society's safety critical source code *public* vs what is currently buried in inauditable binary blobs - and in this letter, tried to shift the core fcc licensing requirements to mandating that the source code at the lowest layers of the network stack be "public, maintained, and regularly updated".
What license is slapped on this "public" code I totally do not care about - it could mandate you have to sell off your first born child, or slit your throat after reading, for all I care.
I care only that the sources be public, buildable, maintained and updated.
http://www.bufferbloat.net/pro...
Open source and closed source alike have been doing a terrible job of maintenance, and in the embedded market - aside from higher end devices like android and mainline OSes like redhat/ubuntu - are not being updated. That is the *real problem* here that we are trying to solve.
thx in advance for any efforts you might make to correct your messaging, particularly when talking about our efforts! I have been busting my b**ls to make these points with every reporter I've talked to.
Aside from that... I think extremely highly of your characterization of the problem's stakeholders, the quality of your letter is even better than ours overall, and your proposed solution quite possibly one that could succeed (although I would shoot for a new licensing regime that made the git committer more responsible, perhaps - it is very worthy of discussion!)
I am totally willing to discuss restrictions on "how public" things become - and how fast they become so! particularly as I am well aware dismal code quality in many mission and public safety critical pieces of software that is out there. Mandating that all that be made public all at once would induce a terrifying amount of risk to society as a whole, and a staged approach towards making the core blobby bits public would be best.
I would dearly like, also, to fix the dsl drivers and firmware worldwide, at least in part, because I strongly suspect quite a lot of it, in light of snowden's revelations, is compromised already, and they just need 50 lines of code or so, and a firmware update, to eliminate the bufferbloat in them - and verify, it really is doing what the authors say in the tin, to the FCC.
Sincerely,
Dave Taht
lead author, the cerowrt project's letter to the fcc
http://fqcodel.bufferbloat.net...
Actually, there are many examples of FCC enforcement against transmitters on certain 5 GHz bands interfering with terminal doppler weather radars: https://www.fcc.gov/encyclopedia/weather-radar-interference-enforcement. This is actually a real issue.
No, it isn't especially frequent, but it does take place. There are two reasons it isn't more frequent:
1) Most transmitters aren't located in buildings that are high enough to be in the line of sight of airport weather radars. Generally the enforcement actions are against operators of transmitters in or atop tall buildings. Your transmitter a couple of floors above ground is highly unlikely to ever interfere with a radar. And if the radar beam was refracted severely enough for this to occur, there would almost certainly be a lot more interference from ground clutter than your wi-fi transmitter. This is more of an issue in tall buildings. The actual buildings are normally pretty unlikely to cause problems because they are stationary point targets that get filtered as ground clutter. Wi-fi, however, would probably contaminate an entire radial, similar to a sun spike.
2) Transmitters operating on either of the 5.25-5.35 GHz and 5.47-5.725 GHz bands are required to use dynamic frequency selection. They are supposed to listen for the signals transmitted by weather radars and, upon detection, switch to a frequency that does not cause interference.
M-I-Z
kU still sucks!
Are you actually arguing that the FCC, the regulatory body *created* to ensure that the radio spectrum within the United States doesn't become an unusable mess of noise created by overlapping bands, and horribly out of any reasonable spec transmitters blasting white noise everywhere, actually has "no business even being involved in" doing exactly that?
Hint: You don't need the FCC license to *write* the drivers. You don't need the FCC license to *deploy* the drivers. You just need someone with the FCC license to *certify* that the driver complies with existing laws before you can use/deploy devices utilizing those driver. And, to top it all off, the license is neither difficult to get, nor prohibitively expensive, nor limited in quantity.
Anyone who gets the Gordon West / W5YI book on the GROL+Radar. Gordy himself will probably be at Pacificon (Pacificon.org) tomorrow. Ham Radio Outlet will be there, with the book. Or of course you can buy it on Amazon :-)
Bruce Perens.
-- Ralph Waldo Emerson, in his famous essay Self-Reliance
Heck, it was late. I try not to mangle the English language.
Bruce Perens.
That is so. I hold two different USG RF licenses (old commercial first class with radar endorsement, amateur extra class.) And I blitzed all the tests (there were a series off them in both cases) so yes, not all that difficult for me.
However, the set of people competent to do what was described about must meet the above criteria, and be of the set of programmers that understands exactly how every layer of wifi is supposed to work and the set of programmers that is conversant with data- and code-hiding / obfuscation techniques. I'm a good programmer -- (about 45 continuous years of experience with many types and sizes of successful projects under my belt), and my debugging skills are right up there as well. I'm very good at seeing that vulnerabilities in my code are minimized. I'm also a good EE, and know RF backwards and forwards. Heck, I write some of the most advanced SDR software out there, so I pretty much eat RF for breakfast.
But I wouldn't be competent to do this job because first, I don't have the hiding / obfuscation chops (and the reason I know that is because I'm a good programmer and realize that's a skill in and of itself... :), nor am I intimately familiar with how wifi works at every level (and I also know that becoming so is non-trivial, because I've skimmed some of the specs.)
So this really doesn't sound like much of a "solution" to me. In practical terms, it doesn't seem achievable. I just don't think there is likely to be a pool of qualified persons being available to fill this kind of role. I suspect that for the workings of a router, you will almost always find a team underneath who (more or less) trust each other for some reason(s), and now we're talking about more risk if we, in turn must trust them and only them.
Closed source opens the door for closed attacks from uncheckable sources, like the NSA. And we know the NSA has been doing things outside the law and outside the acceptable constitutional bounds (and some laws are, in fact, also outside acceptable constitutional bounds.)
So open source for all routers seems to me to be a lot better path to follow. If you're going to mandate anything, I'd say it should be the ability to read the binary out of the depths of the various SOCs that are, or will be, at the core of many routers, as well as from the various types of external ROMs, flashable storage and so on for the types of systems that use them.
This means the router code can be compared bit-for-bit against the code we have been told it is running, and any number of people can then have looked at said code, and in such groups we are much more likely to bring together all the skills required: Joe says there's no obfustcated functionality, Larry says the relevant wifi specs are met, Linda says the networking protocols are okay, Fred tells us that the code itself isn't vulnerable to buffer overruns, Shannon tells us that it isn't going to transmit over the FAA's portion of the 5 MHz band, Mergatroid says what he built from the code that's supposed to be in the router matches every bit of what was actually lifted out of the router. (mind you, that's not perfect either, because a really sneaky team [cough, NSA, cough] could design the hardware to read out one set of code while the router runs something else entirely, but any such "prove it's okay" mechanism has those kinds of limits. Although perhaps Beverly who knows silicon foundry stuff and has access to the right kind of microscope and so forth might be so kind as to look at the die under the microscope and perhaps let us know that it doesn't look like there is a primary/spoof code storage mechanism in there. That, I think, would be one very difficult undertaking, but I'll allow for the possibility, anyway.)
Open source's key strength in re "trust" has almost always been, in a nutshell, "more than one person looks at this." Focusing all trust through one person doesn't leverage that.
IMHO
I've fallen off your lawn, and I can't get up.
Pretty much all spectrum is shared. Sometimes, you get incompatible sharing partners. Some WiFi channels are to one side or the other of the ISM band rather than in the spectrum reserved for ISM. FCC now wants to allocate yet more of those frequencies to WiFi.
Bruce Perens.