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.

Comments

How about the FCC just does its job?

[clonehappy]

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".

Re: How _real_ an issue is it?

[Rainbow Nerds]

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.

the set is small

[fyngyrz]

It's pretty easy for someone competent in radio engineering to pass the license test, and many thousands of people hold the license today

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