Slashdot Mirror
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.
The only proposal so far to actually make sense. No corporate is going to open-source their Wifi code if they haven't already, especially those multi-channel directional systems. And binary- and official-only firmware has obvious problems as well.
This is the proposal to get behind, to reinforce to the FCC in the public consulations. It lets the corporates keep their trade secrets and allows open source firmware to exist at the same time.
Trying to become famous by taking photos. Visit my homepage please.
It's not a compromise, and not good. This is nothing but FCC attempting to gain more control over something they have no business even being involved in. They want to require people to have a FCC license. That is FCC will have an implied authority over those people and tell them how and under what conditions they can approve something.
I won't comply with them on any level. Any open source I use or create will be "open source". and I won't even attempt to obtain any nonsensical FCC license or approval.
What exactly does Open Source have to do w/ something being locked down? Are we entering the 'TiVoization' argument again? Open Source simply means that the source code should be made available to the person who has the executables. Nowhere is there the requirement that the customer has to have the capability to actually modify the in-system code.
There are several good reasons to lock down firmware, regardless of where one stands on open source vs closed source. I am generally in favor of open source b'cos it allows an organization to maintain its own software investments, regardless of the status of support by suppliers, and not being forced to migrate on the schedules of suppliers. But for things like firmware, there are several good reasons to lock down firmware, be it providing it on a PROM, or even on a Flash but w/ the device being locked except at the manufacturer's site. Those include things like warranty claims: since your average Grandma or Suzie ain't a coder, leaving the firmware in a condition that they may accidentally alter its contents and make their routers unusable ain't a good idea, and Grandma & Suzie far outnumber your average /. user who may well be able to flash a router w/ DD-WRT or pFsense, and recode it to convert an 802.11g into an 802.11n.
As far as the FCC goes, their proposal to lock down WiFi firmware has nothing to do w/ whether the code in the firmware is FOSS or closed. It just forces WiFi devices to have a limited set of codes that don't muck around w/ air weather RADARs.
What's the best process to add support behind this proposal? At the linked the FCC page it isn't clear to me how I might add support to this proposal as a consumer.
It all starts at 0
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".
The General Radiotelephone Operators License (with Radar endorsement) isn't really the right license. It's an *operators* license for shipboard use, not a designers license, and while the test (20 years ago for me) had some theory, like modern amateur radio licenses, it focuses more on regulatory and installation issues than on design. The radar test had questions about 1/4 wavelength waveguide stubs for TR switches, but not a lot about the kinds of modulations, EMI/EMC issues, etc.
I would suggest, rather, that someone who is licensed as a Professional Engineer might be a better choice for independent review. The PE exam *is* about design and it requires 6 years of engineering experience (as well as references, etc.) to get the license. PE's have professional liability exposure and a variety of laws and regulations to ensure that they consider the public over their customer.
Ultimately, though, this isn't so much an FCC issue as a manufacturing cost issue. Most of the people complaining here want the freedom to modify the *router* part of the software and to consider the radio as a black box. That's counter to modern manufacturing practice: combine everything in one chip, so we can continue to buy $30 WiFi access points.
Hams (who do care about playing with the radio) are up in arms, and claiming "but we won't be able to modify cheap routers for use in ham bands". That's a pretty niche market, and basically a complaint that hams will have to spend a few hundred dollars to experiment with 2.45 GHz radios instead of $20. That, to me, is not a compelling argument. Besides, hams have always scrounged up and modified old gear, and there's plenty of old WRT54s laying around to supply hams for the next 30 years. I fully expect to see articles in QST in 2050 (should I live that long) about "how to restore a 20th century WiFi access point" much as there are articles about repurposing WW2 and Korean war radio equipment today. And they'll be on the 2050 equivalent of eham complaining about these new kids with their 100 GHz links carrying gigabit/second not knowing the real ham radio back when we had 2 Mbps on one channel and thought it was cool. (by then, the guys who pounded brass in the military, or shipboard with their GROL, will have died, so the code vs no-code dispute will have died down)
Ok, I know nothing about radios, or how wi-fi works, or what the issue is. (Assume for the moment that I'm also unable to use google.)
Clearly though it's a Big Deal. Could someone in the know explain why the necessary restrictions to prevent abuse inherently can't be implemented the hardware, such that the software (open or closed) just can't do whatever it is that's causing the problem?
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)
Nice, but there is one big problem: FCC does not give a fuck about open source. Manufacturers piss on one source as well. And Mr Perens has zero influence on either of them.
It's the usual regulatory overenthusiasm. Basically trying to criminalize perfectly ordinary actions that might lead to actual criminal actions.
You can be penalized for emitting interference in a regulated frequency, or for using a regulated frequency for some other purpose. That is correct, and it is all that is necessary. Whether I my device is interfering because it is a cheap piece of crap, or because it is broken, or because I have flashed it - the reason doesn't matter, the result does. On the other side: if my device isn't interfering, there is no reason for the FCC to care how much I paid for it, whether it is in working condition, or whether I have flashed new firmware.
The bureaucrats need to justify their petty little empires, so they seek new regulations to write.
This is like a "pre-crime" unit: If you flash new firmware, you might be doing so with the intent to misuse spectrum. It's no different from stupid crimes like "structuring" that aren't actually (in a sensible world) crimes at all. They may, in rare cases, be evidence that a crime has been, or will be committed. That is no reason to make them illegal in and of themselves. Did you know that European eggs are illegal in the US, and vice versa? It would be perfectly fine to stick with "don't poison your customer", but that's too simple, and doesn't require enough bureaucrats. So in each case, over-eager bureaucrats have dictated a particular egg-cleaning method, and the two contradict each other.
tl;dr: The FCC needs to concentrate on its actual job. Maybe they should downsize by about 90%, so that they don't have time for dumb ideas.
Enjoy life! This is not a dress rehearsal.
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!
People can already interfere with "airport weather radars" in a variety of ways. What evidence is there that custom WiFi firmware is a problem, and that locking things down would fix this?
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...
The transmitters are locked into a frequency set. However, this is shared with the frequencies used by terminal doppler weather radars (TDWRs). Wi-fi equipment is supposed to detect when a radar is operating on a particular frequency and, upon detection, switch to a frequency that's not in use by a radar. Normally this isn't an issue if you're operating a transmitter near the ground. However, if it's located higher up in or atop a building that happens to be within the line of sight of a radar, it can cause interference. Locking wi-fi transmitters out of any frequencies used by TDWRs would greatly reduce the available spectrum and it isn't necessary. Most wi-fi in the 5 GHz band won't interfere with TDWRs because it either a) detects the radar and switches frequencies or b) is located such that it is out of the line of sight of the radar and can't interfere.
M-I-Z
kU still sucks!
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!
A single person has a surprisingly limited amount of bandwidth. They would quickly find themselves overwhelmed by the job.
Chas - The one, the only.
THANK GOD!!!
This makes the most sense of all the proposals I've seen. How can we help encourage the FCC to consider this? Is there an email address at the FCC for taking comments (e.g., to encourage it)? I'd like to send a "me too" so that the FCC knows to consider this proposal carefully.
- David A. Wheeler (see my Secure Programming HOWTO)
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.
but their proposal to lock down WiFi firmware, won't fly
Can we have some legislation against people misusing commas instead?
systemd is Roko's Basilisk.
Bruce Peren's suggestion is an interesting one, but I think misses the point of something being open source in the first place.
File under 'M' for 'Manic ranting'
They already have control; 47 CFR Part 15 covers this completely.
While you can write whatever code you would like, and you can compile it with no worries, if that code causes interference above and beyond Part 15 rules it is a violation of the regulations for that code to be run if the device running that code is within the jurisdiction of the FCC (USA and its possessions). If you have a license, you are covered by the particular section of 47 CFR that covers your particular license, and you must abide by that license and its covering regulations (code for a TV broadcast transmitter, for instance, has a whole separate set of restrictions).
If a device possesses an intentional radiator of RF it is covered by one or more FCC regulations (in the US; internationally it's covered by the ITU and its vast portfolio of regulations). Many of the provisions of various regulations in 47 CFR are there because of ITU regulations, incidentally, including many in Part 15.
It's not a significant issue. There are problems, but we *already* deal with those problems. There are multiple systems to deal with it.
1. DFS stops interference short of somebody tampering with this section of code
2. The FCC has enforcement abilities to fine those who intentionally cause interference (or even unintentionally really)
The rules which have passed and are going into force in June 2016 are draconian and are causing massive collateral damage. I can say this as one of the people behind these campaigns against the FCC. I also have a business that is all about 'openess' that will be negatively impacted if we're even able to operate after these new rules pass. The rules aren't restricted to big companies or wireless routers. We won't be able to sell you computers, routers, or even printers potentially in the near future. And that is all with the rules which have already passed.
No matter what the FCC says is the case the rules state otherwise. We need them to overturn the rules. Otherwise some FCC enforcer could come to us an shut us down. And it would be a total financial collapse. The FCC can fine you up to $20,000 per device sold. We don't do more than a million USD. A single fine on two months of *just routers* would put us out of business. I'm in a position that I have to seriously consider shutting down or risk total financial collapse (and a kind you can't get out of by simply folding).
Anything with a link on a website someplace will be considered "mass-distributed" for regulatory purposes. So in effect that would mean that only peer to peer sharing of open source code would be allowed which undermines the whole point of open source.
I think "commercially distributed" might cover it, so that people can't sell software or hardware without certification. But basically I think some simple disclaimer that comes along with the code that indicates that the code is intended for experimental use or research and not for widespread deployment in a production setting. That should allow individuals to utilize the open source code while dissuading enterprise use. But "mass-distributed" is the wrong wording.
What the hell is the FAA doing running a safety critical (so they say) radar system in an ISM band? And why is the FCC defending them?
No license is required to operate within these bands, making the proposal that a person holding a technical license approve router firmware an exception to current policy. Furthermore, equipment using these bands must be tolerant of interference caused by other in-band transmissions.
As far as I can tell, the FAA is violating FCC rules by operating their radar within these bands. The FCC should immediately order them to move to a licensed band and allocate a frequency specifically for this kind of public safety use. And the FCC should order that a person holding a technical license verify the proper design and operation of the radar system. Because whoever set it up initially wsn't smart enough to get it right.
Have gnu, will travel.
The real answer to the issue that concerns the FCC is to have the chipset manufacturers add write-once registers that can be used to lockout frequencies and power levels that are illegal in certain regions. That way, the manufacturers can make one hardware design, and still ensure compliance with regional regulations. This is such an easy solution to implement, and would completely eliminate the "need" to DRM the firmware.
--- Generation X: The first generation to have SIG lines inferior to their parents... ---
If source code is on a website, it's not "mass-distributed in binary form." I assume that by "binary form", Mr. Perens meant a form other than "the preferred form of the work for making modifications to it" (GPLv3). And if source code is specifically marked as experimental, it's not "mass-distributed [...] for use by RF-naïve users."
I've bumped into Bruce a few times online and, from my interactions, I'd say he's a pretty smart and reasonable person. Those two things don't always go together which is why he's exceptional.
"So long and thanks for all the fish."
Enjoy your fine and possible jail time. You're aware that wireless uses radio spectrum and that spectrum is, quite specifically, under the authority of the FCC, right? No? Well, their charter is a Google away.
Hell, I'll even do the work for you... Go here:
https://transition.fcc.gov/psh... (PDF warning)
That's, specifically, where you want to look. If you're on US soil then they're the governing body, for better or worse, and there's not a whole lot you can do about that. You can violate their rules but I'm going to not have much sympathy when your arrogance gets you a fine that you need to spend the rest of your life paying off. I'm not even going to help you pay it off.
Good luck with that. Let us know how it works out for you. Some of us will be rooting for you. That probably won't be me.
"So long and thanks for all the fish."
As a FOSS aficionado, sometimes I wish you zealots would go away. Just because I use something doesn't mean I'm entitled to make choices for another nor does it mean that others must conform to my ideals.
"So long and thanks for all the fish."
The radar signal needs to reflect well off the things you are trying to observe. It also needs to have a very long range. The bands typically used for Doppler radar stations were chosen for a reason.
Due to the Rayleigh effect, weather radar needs to operate in roughly the 3-30 GHz band. The upper half of that frequency range (on a logarithmic scale) doesn't transmit through the atmosphere very well and is thus incapable of functioning at any reasonable distance. The lower half of that range is compatible with telecom usage.
Now, that range where weather radar and telecom overlap is the only place that weather radar can possibly work. Telecom, on the other hand, can go all the way down to 30 MHz. That is a huge, huge area which is absolutely useless to weather radar.
It is far easier to either (a) require telecom devices to detect radar activity and auto-select channels not in use or (b) specify a frequency range for telecom devices that does not overlap with weather radar.
The FCC chose (a), which is the least restrictive approach that allows both radar and telecom to function.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
it should be the operator that incurs any liability
The legal theory here might be secondary liability for interference with weather radar. If a company profits from an unlawful act (crime or tort) committed by another that it has power to prevent, it has vicarious liability for said other's act. If a company distributes tools that it knows will allow another to commit an unlawful act, it has contributory liability for said other's act.
where else do we have random porn-surfing wackos interfering with a life-safety system?
so don't do it here, either. prohibit the overlap frequencies.
if this is supposed to be a new economy, how come they still want my old fashioned money?
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.
The problem with radio is that one user's operations can block another user's. So, we need some regulation to enable us to share fairly. Think of it as a bus with a lot of bus devices belonging to different people with different goals. If you don't have a bus protocol, one device could grab all of the bandwidth, or lock others out arbitrarily.
Also, get a CB and use it. What you will meet there is what comes from FCC abdicating responsibility to regulate a radio service.
Bruce Perens.
What if vendor is FCC licensee. The system would fail as now vendor can willfully do anything. Open sourcing the firmware is the only REAL solution.
The problem will be that the bureaucracy will cause 'FCC licensed drivers' to be utterly outdated except for a few proprietary ones because someone could line someones pockets to get it pushed through.
The unlicensed firmware will still be shipped on most cheap routers however since they're coming from China where the FCC has no jurisdiction and the resellers don't care much about import requirements.
Be careful what you wish for if you let a government agency get involved with your plans. Your plans however good will be overburdened with legalese and pork, in the end you'll get a law that is ripe for abuse by those in power and those with money.
Custom electronics and digital signage for your business: www.evcircuits.com
The only way to ensure the frequencies is to lock the transmitters into a specific frequency set.
To what frequency set should a transmitter designed for different countries with different spectrum allocations be locked? For example, in the United States, the frequencies corresponding to Wi-Fi channels 1 through 11 are under an FCC unlicense for part 15 operation, while Wi-Fi channels 12 through 14 aren't.
I imagine that it's workable because it becomes easier to pinpoint an offender: a single user rather than all users of a particular make and model of transmitter.
Can the FCC point to any specific instances of aircraft radar interference, and especially, instances of interference caused by routers running Open Source software? Or is this another case of a Gov't agency using a bogy man (It's to prevent terrorism, It's for the children, etc) to assert control over a market segment that it didn't previously control.
Wondering which.
I suspect it's more the latter rather than the former, but not for the reasons given..
My money is on this being a method for the government to attempt to prevent widespread use of modified WiFi routers as mesh-network routers when they decide to shut down internet access due to 'terrorism' or domestic uprisings/protests.
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
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.
If all you want is someone "with the FCC license", then you might as well make it the Restricted Radiotelephone Operator's Permit, because that license requires just as much technical background relevant to software development and WiFi as the GROL (even with a ship radar endorsement) has. If you're going to claim that someone with a GROL can learn what he needs to do the job right, well, so can someone with the RROP.
My money is on this being a method for the government to attempt to prevent widespread use of modified WiFi routers as mesh-network routers when they decide to shut down internet access due to 'terrorism' or domestic uprisings/protests.
Right. I've been working on just such a system, experimentally. Lots of commodity ($20) wifi routers, loaded with Open-WRT, connected to a small solar panel and rechargeable battery. They run forever and you can mount them anywhere, even on trees. Even if the access points are down, the hosts connected to the network can talk to each other. It's a neat system, and except for the wider Internet connections, relies on no ISP whatsoever.
"Somebody has to do something. It's just incredibly pathetic it has to be us."
--- Jerry Garcia
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...
It happened. Back in the days when ships were wood and men were steel (1926), the Attorney General ruled the Dept of Commerce (prior to FCC) had no legal authority to assign freq, power levels, etc. Hundreds of stations had a field day, millions of listeners across America turned off their receivers, and sale of receivers slowed to a trickle (ref GROL License Prep book by Maia and West).
Getting back to a general radio operator license (GROL), I'm not sure how applicable license questions are to wifi but someone holding a license is at least familiar with RF, frequencies, harmonics, how square waves in computers generate lots of frequencies (white noise). It seems many software people are not aware but then if talking about 2.4GHz or other ISM bands, it's all Wild West. I think FCC is probably more concerned manufacturers keep their RF emitters within this band and lot splatter out.
But then FCC mostly is a shill for broadcast industries. Much of their technical base has been lost due to budgets and political objectives. I see lots of RF products that have Part 90 ratings (which I find dubious but I've not spent time with test equipment verifying performance), and worse off are 1.2GHz wireless video transmitters that transmit in the aeronautical navigation band (950 to 1200 MHz).
mfwright@batnet.com
not sure how this fits into this thread, http://nist.gov/el/isd/cs/wpsm...
mfwright@batnet.com
Cell phones, xbox, and other devices have the claim that the device accesses their networks and therefore they must retain control. There is no such argument for a wifi router firmware which is in almost every case 99+% modified open code and 100% the property of the end purchaser.
There is a huge security risk, with radar interference the least of it, and no upside to locking people out of their devices to which the manufacturer has no access right after the point of sale.
To what frequency set should a transmitter designed for different countries with different spectrum allocations be locked?
To the frequencies appropriate for the country where the transmitter is operated. Of course. I would have thought that was an obvious answer.
How can the transmitter securely determine in which country it is being operated?