Weekly Edition
Return to the Front page
| |||||||||||
|
| |||||||||||
A green light for free-software defined radio?
Playing around with radio-frequency transmission and reception used to be
restricted to those of us with hardware skills. That has been changing for
some years, though, as processors get faster and software techniques
advance; now, many radio transmitters and receivers are built with simple
(but flexible) hardware. The hard work of generating the signal to be
transmitted is done in software. Some wireless network adapters work that
way now, as do a number of other devices. There is a well-advanced project
- GNU Radio - which
enables experimenters to do amazing things with software defined radio
(SDR) systems.
A potential problem with such devices is that users could, perhaps, modify the software and cause the radio to operate in ways which are not compliant with local spectrum-use regulations. Regulatory agencies tend to frown on such use - and on manufacturers which make it easy for their devices to be used in non-compliant ways. Fear of this sort of tampering is one of the excuses given by wireless adapter vendors for not releasing free drivers for their devices. It has also been an occasional concern for Linux distributors who include free drivers. In general, the combination of SDR and free software has long been the cause of worry and fear, and that has slowed progress on that front. The Software Freedom Law Center has made an attempt to address that fear by doing an analysis of the U.S. Federal Communications Commission's regulations with regard to the use of free software in software-defined radio systems. The resulting white paper is a bit of a challenging reading experience (it may be clearer than the FCC regulations, but it still reads like legalese), but it is probably worthwhile for anybody who is concerned about the interaction of SDR and free software. The white paper starts by looking at the scope of the FCC's regulations with regard to SDR systems. It is noted that many such systems (a wireless router, for example) contain full Linux distributions within them. Almost the entire distribution, however, is unrelated to the device's radio functionality and, thus, is not subject to FCC regulation. Any device software which does not interact directly with the radio is unregulated and can be free software. Next, the SFLC points out that, by its reading, the FCC's regulations only apply to device manufacturers. They do not, in particular, apply to independent software developers. This conclusion is important: it says that distributors who ship free drivers for SDR devices are not bound by the FCC's rules unless those drivers directly operate the radio in non-compliant ways. The down side is that manufacturers of software-defined radio devices really cannot provide free drivers if those drivers could be modified to enable non-compliant operation. The FCC expects that the security measures within these devices will be implemented in a way which resists casual tampering, and it has been clear on its worries that implementing those measures in free software will not yield a sufficiently robust solution. So, if the hardware can be easily programmed to do non-compliant things, it looks like the FCC expects the driver which programs the device to be a non-modifiable binary blob. The SFLC notes that the door is not entirely closed, and that a vendor which can demonstrate sufficient robustness with a fully free-software implementation could still get certification. But it would not be easy. The white paper concludes this way:
The SDR rules promulgated by the FCC represent a positive
development for FOSS developers working in the wireless space. The
rules allow FOSS developers not affiliated with device
manufacturers to continue work on their software without
restriction. They allow SDR manufacturers to employ FOSS for most
of the functionality of their devices, and they leave open the
possibility that a device using a purely FOSS-based software
platform could also pass FCC certification if it managed to
demonstrate the soundness of its security strategy.
It may be a positive development, but only to an extent; as long as the FCC is saying that SDR devices must contain binary blobs to be certified in the U.S., we will not have complete control over our devices. One should note that this document only discusses U.S. regulations. The FCC is certainly a prominent regulator, and its decisions have worldwide impact, but it is not the only regulatory body out there. Every country has its own rules, and some of them have regulatory agencies which are rather more nervous than the FCC; people who have studied the issue often note that Japan can be a very bad place to play loose with spectrum regulations. So, while a partially-green light from the FCC may be somewhat comforting, it's really only a small piece of the larger problem. Spectrum use and regulation is an important issue; it will have an increasing impact on our ability to communicate freely as time goes by. Improving software techniques promise to open up the spectrum in interesting ways, making it possible for more bits to be carried in ways which are difficult to intercept or interfere with. It has been argued that, as a result of improving technology, the need (and justification) for heavy-handed regulation is fading, at least over broad parts of the spectrum. The success of WiFi shows what can happen when even a small bit of spectrum is freed; imagine what could happen if the full innovative power of the free software community could be unleashed on flexible, software-defined radio systems. That is why any progress toward openness on the SDR front is a good thing, even if it remains far from what we really want. (Log in to post comments)
A green light for free-software defined radio? Posted Jul 6, 2007 17:27 UTC (Fri) by shemminger (subscriber, #5739) [Link] But there was also a negative ruling on SDR today:http://a257.g.akamaitech.net/7/257/2422/01jan20071800/edo...
Surprisingly, in this article:
"There is no reason why regulators should discourage open-source approaches that may in the end be more secure, cheaper, more interoperable, easier to standardize, and easier to certify," Bernard Eydt, chairman of the security committee for a global industry association called the SDR (software-defined radio) Forum, said in an e-mail interview this week.
A green light for free-software defined radio? Posted Jul 7, 2007 8:31 UTC (Sat) by pascal.martin (subscriber, #2995) [Link] > But there was also a negative ruling on SDR today:> http://a257.g.akamaitech.net/7/257/2422/01jan20071800/edo...
This is actually the FCC ruling that the SFLC was responding to.
I found the SFLC reaction to be more marketing than substance. Having read the two texts, I believe they do a lot of spin about open source in general instead of analyzing the specifics of the problem. The LWN report seems more rounded (thank you).
I believe there are three main points that the SFLC is wrong about:
- the FCC ruling is not about open source software in general, it is about radio-related software and hardware documentation only. Therefore the FCC is not trying to regulate software, as the SFLC claims.
- the FCC ruling is not about open source software developers, it is about restricting access to hardware (i.e. no access to open radio hardware). The FCC wants to restrict the sale of devices that could be easily modified in a non-compliant way. If a device has public specs and can be reprogrammed, then the FCC will find it non-compliant. Without radio hardware, who care about radio software? In this context the conclusion "The rules allow FOSS developers not affiliated with device manufacturers to continue work on their software without restriction" qualifies as spin.
- The new ruling makes it clear that the burden is on the vendor to prove that the device cannot be so modified. Vendors now have a strong incentive not to give access to firmware update. Those who still want to keep their radio open will be required to provide a binary-only driver an not release hardware specs.
The SFLC actually confuses cryptography code reviews and open access. An open source cryptographic code does not allow people to break a cryptographic-based firmware lock: you need access to the keys, not to the code. Don't they have a competent developer to advise them?.
The GPL v3 makes the problem even more problematic, especially with SDR spreading into personal uses (high speed wireless networks).
A green light for free-software defined radio? Posted Jul 7, 2007 12:26 UTC (Sat) by drag (subscriber, #31333) [Link] Well this is specificly about _software_radio_. Not software to control radios... software as the radio.
They are a bit like Winmodems or software modems. Were you strip out the hardware that did all the work on previous devices and replace it all with software. The hardware that is used it used is kept to a absolute minimum. All the frequency generation, modulation, and other such things are done purely in software.
Sure this uses a lot of CPU, but going this direction has SIGNIFICANT advantages. You can do things with software radios that you simply can not do with regular radio hardware, at least unless your spending a shitload of money.
The Intel wireless devices and other things are essentionally software radios also.
Going back to software modems vs hardware modems. Sure software modems are cheap and crappy and other such things. But what people didn't realise at the time is that once you had the control of the hardware and software you could easily update the protocols the devices supported and changed their behavior so that software modems can be made to significantly out perform contemporary, and much more expensive, 'real' modems. Back when I played Quake2 I could get significantly better internet performance (better bandwidth and better latencies) using a software modem then I could with a hardware modem. And it didn't have anything to do with the hardware modem being crappy or anything like that. (although the phone line was pretty crappy) The difference was that I could change and update the protocols the software modem supported simply by updating my drivers, with the hardware modem I was stuck using older protocols that were less effective.
Software radio is like this, but it's much much more important.
Look at the stuff already being used by GNU Radio software and hardware:
Capture HDTV broadcasts. Detect wifi hotspots. Track people using Cell phones, satellite communications, magnetic signal proccessing, wireless communications, video transimission and reception, audio transmission and reception. Anything people can use a radio for. All with similar hardware and similar software. It's very flexible.
The cost of providing similar functionality in hardware would be outrageous. Software radio is a important foundation for tommorrow's communications.
The future of communication is through global wireless mesh network. All of it ad-hoc, completely open, nearly completely free. Almost organic in nature. All of it working together, satelite, wide-ranging wifi, small time radio operators, high speed/high reliable commercial wired communications etc etc.
The radio spectrum is a literally untapped shared resource for sharing and communicating on a global scale. Right now you have all major governments admitting that this is a resource that belongs to it's citizens. AND you have ALL major governments that have near total restrictions on what those citizens can and cannot do with it.
The key to openning up and making it work is highly sophisticated, open, and cheap radios. Much more sophisticated and open then what we have now. In order to make this affordable for the average person it needs to be software radios. .
Your already seeing this with Intel Wifi, for example. Or Atheros. Pretty much any significant consumer device will be software-based.
Needless to say there are significant advantages for people that have influence over the FCC to keep radio from openning up. For very significant censorship and financial reasons.... FCC doesn't want to lose it's power, the government does not want to lose control of it's regulation of speech, and big media companies do not want to lose control over their monopoly of of the airwaves, etc etc
Look at the tiny amount of open spectrum we have to work with, and look at the massive amout of usefullness and value people are already able to extract from this very crowded and very limited resource.
A green light for free-software defined radio? Posted Jul 7, 2007 19:37 UTC (Sat) by pascal.martin (subscriber, #2995) [Link] I certainly do not want to badmouth SDR. The army invented them for good reasons, and the future sounds very exciting.
My whole point is that the FCC does not want modifiable 100% open source software: either the software is locked on the device or else the driver is not open source and the hardware spec is not public.
Either case, open source developers are left out.
I know about GNU radio. For the time being this is hobbyist equipment. Volume distribution could be well declared illegal by the FCC. This is the message being sent out.
A green light for free-software defined radio? Posted Jul 8, 2007 11:36 UTC (Sun) by drag (subscriber, #31333) [Link] I know..
It's just the whole thing pisses me off.
What sort of sense does it make to have a non-elected government body have massive amount of control over...
the design and manufacture of so many devices,
It's completely absurd. FCC and government regulation and control is doing a massive amount of damage to innovation and the ability for people to communicate freely with one another.
I don't mind having orginization to help set standards, do proper regulation so that inviduals and companies can't abuse the spectrum and hurt everybody else's ability to use it... but right now we have regulations over the use of radio that are 70 years obsolete and were dubious in the first place!
A green light for free-software defined radio? Posted Jul 12, 2007 11:14 UTC (Thu) by smoogen (subscriber, #97) [Link] > The radio spectrum is a literally untapped shared resource for sharing and> communicating on a global scale. Right now you have all major governments > admitting that this is a resource that belongs to it's citizens. AND you > have ALL major governments that have near total restrictions on what those > citizens can and cannot do with it.
The issue is that it is a shared resource.. and ideally the government is there to make sure that it does not suffer from the "Tragedy of the Commons". The problems range from the officially malicious (purposely listening on/blocking other transmitters) to the accidently malicious... two different transmitters using the same frequency with different patterns causing blockage etc.
The issue is how to best police the commons. Each government has come up with its own way.. and most are probably not the most democratic. Getting that fixed requires fixing a government to be accountable by its citizens which requires a participating citizen base... something most nations do not have.
start here: Software Defined Radio receivers Posted Jul 7, 2007 6:50 UTC (Sat) by kbengston (subscriber, #6153) [Link] SDR receivers are a good starting point for anyone interested in this stuff. Not much danger of running afoul of regulatory agencies, because they pretty much only care about radio transmitters.
A good receiver is way more difficult to design than a transmitter. There are lots of radio signals out there for which there is no SDR receiver, particularly with the worldwide move to digital modulation formats for TV, Broadcast Radio, and many mobile services.
SDR Receivers for packet-based signals like 802.11 wlan are specially difficicult because there is a very short (10s of microseconds) preamble in which the gain of the receiver needs to be set so that the Analog to Digital Converter is neither saturated nor in the noise. Most general purpose hardware platforms lack the ability to measure signal strength and set gain fast enough to be able to handle 802.11 (or similar) modulation.
start here: Software Defined Radio receivers Posted Jul 7, 2007 9:00 UTC (Sat) by pascal.martin (subscriber, #2995) [Link] This is somewhat true for radio and television, but there are some lagging "flag" problems with TV and the HD radio "standard" secrets are firmly protected by the DMCA.
The problem is wireless networking. A receiver-only equipment is of little use, except if all you want is to steal credit card numbers ;-)
Did you go to Best Buy lately? Wireless is taking over Ethernet in term of shelf space. You find few choices with Ethernet equipment and much more choice with wireless. In a few years, Ethernet might be relegated to a more professional market (expensive CISCO boxes...) out of range for most personal use.
Open Source could be pushed out of the home network market, smashed between the demands of the FCC and those of GPL v3. With home network there is no home computer either. Worst case, Linux could become unusable for 80% of its users. FCC is telling us that binary-only drivers might be our only way. Not much fun.
start here: Software Defined Radio receivers Posted Jul 10, 2007 19:10 UTC (Tue) by ilmari (subscriber, #14175) [Link] Open Source could be pushed out of the home network market, smashed between the demands of the FCC and those of GPL v3. There's no need to worry about the GPL v3 unless you're worried about wireless support in HURD. The Linux kernel is staying GPLv2 and I doubt the BSDs would accept GPLv3 code in their kernels.
start here: Software Defined Radio receivers Posted Jul 13, 2007 12:09 UTC (Fri) by vonbrand (subscriber, #4458) [Link] But they already accepted CDDL code! See the ZFS on FreeBSD page...
start here: Software Defined Radio receivers Posted Jul 20, 2007 6:58 UTC (Fri) by hazelsct (subscriber, #3659) [Link] Indeed. The new Intel drivers work around this by means of a small free in-kernel driver (using DeviceScape no less) with a user-space binary blob.
As long as it is legal to use proprietary user-space software with free operating system kernels and libraries (which I'm pretty sure GPL v3 does not prevent), this approach will work fine for software-defined radio.
Free Software defined radio cannot pass FCC regulations by nature Posted Jul 7, 2007 14:26 UTC (Sat) by rvfh (subscriber, #31018) [Link] I understand that:- Free Software means you can do whatever you want, especially change the operation frequency - FCC regulations stipulate that you must not be able to do whatever you want, especially change the operation frequency
So there must be a binary blob to set the frequency, all the rest can be
Correct me if wrong.
Free Software defined radio cannot pass FCC regulations by nature Posted Jul 7, 2007 17:09 UTC (Sat) by tzafrir (subscriber, #11501) [Link] Suppose I have a device I take with me from the US to Japan. How can the device magically know that it is suddenly in the domain of Japan and use the rule set for Japan? Shouldn't the software order it to do so?
Free Software defined radio cannot pass FCC regulations by nature Posted Jul 7, 2007 19:39 UTC (Sat) by pascal.martin (subscriber, #2995) [Link] The usual solution for vendors is to follow the most strict regulation...
Not exactly good for open source.
Free Software defined radio cannot pass FCC regulations by nature Posted Jul 9, 2007 4:34 UTC (Mon) by tialaramex (subscriber, #21167) [Link] That's not true, the only thing you could do if you obeyed "the most strict regulation" is remove all radio transceivers from your design. Several small, uninteresting countries have an almost total ban on civlian radio equipment.
What actually seems to happen is that vendors try to ensure that they can meet the letter of the law for a few major markets, such as the US, UK and Western Europe and Japan. Other countries will either certify or not, and if necessary the product won't be officially available in those countries, though if it's popular of course it will enter on the grey market.
They can meet the letter of the law by for example including a different driver CD with a different uploadable firmware for US vs European markets, in the US the driver sets a register to say 0x01, while the European driver asks during installation what country it is in, and chooses one of 0x02, 0x03 or 0x04 according to local regulations. Different radio frequencies are "not available" in software depending on which value is set.
In my country some of the 802.11 frequencies are "not available". Most wireless devices bought here can detect networks on these frequencies but will refuse to connect to them, inevitably some people (the same sort who think NAT is a security feature) see this as a way to control access to their network, they modify a wireless hub by overwriting the firmware to think its in Japan, and then make a registry change or similar small alteration to the software on PCs that connect to the network. Perhaps it may cause interference with safety-of-life critical radio systems here, but no-one cares about that.
sandbox, anyone? Posted Jul 11, 2007 23:43 UTC (Wed) by skybrian (subscriber, #365) [Link] This is probably very hard to implement, but it seems like the best compromise here would be software that runs in a sandbox that restricts transmissions based on FCC regulations, so anything within those boundaries is permitted. It wouldn't be such a bad thing for developers either, since you'd be able to try out new things without worrying that a bug will result in annoying the neighbors.
Just publish the spec Posted Jul 12, 2007 5:37 UTC (Thu) by addw (subscriber, #1771) [Link] As far as I could see it was all about the manufacturer not providing free drivers but shipping a blob instead. Fine: let them do that and get the certification, but let them also publish the full spec of the device - that way a free driver will appear in the kernel before too long. Everybody gets what they want.
Am I missing something ?
Just publish the spec Posted Jul 12, 2007 6:40 UTC (Thu) by DRBaldock (subscriber, #30881) [Link] To receive certification if the radio transceiver hardware can be programmed to operate in ways that are non-compliant with applicable laws, then the manufacturer has to provide some way to "force" compliance - either by firmware/hardware limits, or by assuring that the software drivers aren't easily modifiable by the user.
It's apparently the "also publish the full spec of the device" part that would cause the FCC to withhold certification in the first place. Or to withdraw the certification if the spec is published after the device is certified.
Progress inevitable. More enforcement vs. abuse better than luddite paranoia. Posted Jul 15, 2007 9:42 UTC (Sun) by InnateTech (subscriber, #44362) [Link] The fact of the matter is that SDR will eventually become a reality, and there will be an implementation (developed outside the US if neccessary) that will not be crippled or closed.
I'm a FCC licensed amateur radio operator, and the fact of the matter is that it has been possible to modify more traditional equipment to operate outside of the intended freqs for -- well, pretty much forever. Same thing with amplification and regulation on peak emitted power. For instance, many ham band 6m/2m/70cm etc. radios also have AM aircraft band receive and can be modified to transmit in that band illegally--often through flashing the radio's firmware, or cutting a trace that goes to a chip that exists only to perform checks associated w/allowable frequencies. Similarly, there are simple modifications to allow amateur equipment to operate on military frequencies--legally made under the MARS program (if it's still going, not sure.) So radios have been partially "firmware defined" for some time, either by embedded logic on chips or actual code held in flash.
The eventual evolution to more software and less hardware is simply following the developmental path well marked by other sectors of the overall electronics and communications industries. It is The Right Thing, and therefore is/should be inevitable.
The answer is to allow SDR to proceed at full speed, completely open, and to amp up enforcement against those who would abuse the freedom it offers in ways that might compromise public safety or cause a denial of other services.
Progress inevitable. More enforcement vs. abuse better than luddite paranoia. Posted Jul 19, 2007 7:01 UTC (Thu) by tbrownaw (guest, #45457) [Link] Is this really a good idea? These *WILL* end up installed in computers, attached to the internet. And since standard operating systems can't be considered secure in such a hostile environment, should there really be a way that viruses/worms/etc can arbitrarily chew up (possibly imortant) airwaves?
Software defined radio sounds very nice... but malware defined radio could be pretty bad. How do we get one without the other, given the insecure OSes and non-security-concious users that we have?
|
|||||||||||