Email Delivery

Receive new posts as email.

Email address

Syndicate this site

RSS | Atom


About This Site
Contact Us
Privacy Policy


November 2010
Sun Mon Tues Wed Thurs Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Stories by Category

Basics :: Basics
Casting :: Casting Listen In Podcasts Videocasts
Culture :: Culture Hacking
Deals :: Deals
Future :: Future
Hardware :: Hardware Adapters Appliances Chips Consumer Electronics Gaming Home Entertainment Music Photography Video Gadgets Mesh Monitoring and Testing PDAs Phones Smartphones
Industry :: Industry Conferences Financial Free Health Legal Research Vendor analysis
International :: International
Media :: Media Locally cached Streaming
Metro-Scale Networks :: Metro-Scale Networks Community Networking Municipal
Network Types :: Network Types Broadband Wireless Cellular 2.5G and 3G 4G Power Line Satellite
News :: News Mainstream Media
Politics :: Politics Regulation Sock Puppets
Schedules :: Schedules
Security :: Security 802.1X
Site Specific :: Site Specific Administrative Detail April Fool's Blogging Book review Cluelessness Guest Commentary History Humor Self-Promotion Unique Wee-Fi Who's Hot Today?
Software :: Software Open Source
Spectrum :: Spectrum 60 GHz
Standards :: Standards 802.11a 802.11ac 802.11ad 802.11e 802.11g 802.11n 802.20 Bluetooth MIMO UWB WiGig WiMAX ZigBee
Transportation and Lodging :: Transportation and Lodging Air Travel Aquatic Commuting Hotels Rails
Unclassified :: Unclassified
Vertical Markets :: Vertical Markets Academia Enterprise WLAN Switches Home Hot Spot Aggregators Hot Spot Advertising Road Warrior Roaming Libraries Location Medical Public Safety Residential Rural SOHO Small-Medium Sized Business Universities Utilities wISP
Voice :: Voice


November 2010 | October 2010 | September 2010 | August 2010 | July 2010 | June 2010 | May 2010 | April 2010 | March 2010 | February 2010 | January 2010 | December 2009 | November 2009 | October 2009 | September 2009 | August 2009 | July 2009 | June 2009 | May 2009 | April 2009 | March 2009 | February 2009 | January 2009 | December 2008 | November 2008 | October 2008 | September 2008 | August 2008 | July 2008 | June 2008 | May 2008 | April 2008 | March 2008 | February 2008 | January 2008 | December 2007 | November 2007 | October 2007 | September 2007 | August 2007 | July 2007 | June 2007 | May 2007 | April 2007 | March 2007 | February 2007 | January 2007 | December 2006 | November 2006 | October 2006 | September 2006 | August 2006 | July 2006 | June 2006 | May 2006 | April 2006 | March 2006 | February 2006 | January 2006 | December 2005 | November 2005 | October 2005 | September 2005 | August 2005 | July 2005 | June 2005 | May 2005 | April 2005 | March 2005 | February 2005 | January 2005 | December 2004 | November 2004 | October 2004 | September 2004 | August 2004 | July 2004 | June 2004 | May 2004 | April 2004 | March 2004 | February 2004 | January 2004 | December 2003 | November 2003 | October 2003 | September 2003 | August 2003 | July 2003 | June 2003 | May 2003 | April 2003 | March 2003 | February 2003 | January 2003 | December 2002 | November 2002 | October 2002 | September 2002 | August 2002 | July 2002 | June 2002 | May 2002 | April 2002 | March 2002 | February 2002 | January 2002 | December 2001 | November 2001 | October 2001 | September 2001 | August 2001 | July 2001 | June 2001 | May 2001 | April 2001 |

Recent Entries

In-Flight Wi-Fi and In-Flight Bombs
Can WPA Protect against Firesheep on Same Network?
Southwest Sets In-Flight Wi-Fi at $5
Eye-Fi Adds a View for Web Access
Firesheep Makes Sidejacking Easy
Wi-Fi Direct Certification Starts
Decaf on the Starbucks Digital Network
Google Did Snag Passwords
WiMax and LTE Not Technically 4G by ITU Standards
AT&T Wi-Fi Connections Keep High Growth with Free Service

Site Philosophy

This site operates as an independent editorial operation. Advertising, sponsorships, and other non-editorial materials represent the opinions and messages of their respective origins, and not of the site operator. Part of the FM Tech advertising network.


Entire site and all contents except otherwise noted © Copyright 2001-2010 by Glenn Fleishman. Some images ©2006 Jupiterimages Corporation. All rights reserved. Please contact us for reprint rights. Linking is, of course, free and encouraged.

Powered by
Movable Type

« Skyhook Partners with GPS Chip Giant for Wi-Fi Location | Main | NTT DoCoMo Closes on 5 Gbps in 4G Research »

February 8, 2007

Progress on Linux Support for Contemporary Wi-Fi

Linux, *BSD, and other Unix variants have lagged in Wi-Fi support due to chip vendor's stated concerns about access to the low-level radio functions on their chips: But a meeting last month in London, the Linux Wireless Summit, apparently has helped move development along. reports that the meeting included Linux kernel developers, and representatives from Broadcom, Devicescape, Intel, MontaVista, and Nokia. The summit is part of an effort to standardize parts of Linux for reduced maintenance and complexity, as well as greater functionality.

The summit's organizer is quoted and paraphrased as stating that the FCC will only certify Wi-Fi devices that have a closed-source component for handling low-level radio settings, such as frequency choice and power levels. I don't know that there's actual evidence as to this fact, and would love to see. That would be an extra-regulatory step for the FCC, as there is no defined required for releasing radios that cannot be modified; the onus is typically on the purchaser who modifies hardware conforming to regulatory limits, and suffering the penalties if they fail to conform.

For instance, worldwide 802.11a equipment can use the 4.9 GHz band in some countries; it's limited to public safety purposes in the US and military uses elsewhere. Using 4.9 GHz in some parts of the world could get you thrown into jail for a long, long time.

It's interesting that these considerations are now being made openly. A couple of years ago, I was provided with some of this reasoning from sources I won't identify, but told that the concerns about the FCC and other regulators couldn't be discussed publicly.

You can read some of this history in a January 2005 post that starts off discussing an Economist article criticizing Atheros and Broadcom.


Actually I think that the device can not be type accepted by the FCC if the end user can modify the frequency since it is essentially a commercial radio, the same antimodification rules that apply to the commercially available FRS, GMRS or even CB radios would apply here, unlicensed end users must be restricted from controlling the frequency and power of a type accepted radio device. There is a lot of precedent for this and it is nothing new at all.

I'm all for open source but they do have a point, they can't release the information to non-licensees of the FCC or they lose the type acceptance they need to sell the devices. An easy way to deal with this might be having someone who is writing the wireless driver be licensed as a GROL (radiotelephone operator) by the FCC, but they would still be creating an opportunity for violation of FCC regs by opensourcing the code to control the power and frequency of the transmitter which might still be a problem. Arguably as long as the end user did NOT modify the code they would be legal but the FCC needs to issue an opinion on this.
This really is an issue for the FCC to address one way or the other, but good luck getting a timely response from them.

I think I'm reasonably qualified to make these statements as an FCC licensed amateur radio operator who is required to know these things in order to operate a radio. Any ham or FCC Licensee would probably give the same answer, it's common knowledge in the radio community and goes for all kinds of commercial radios, not just wifi. Try not to take it as a slight against open source but a universal regulatory onus :)
73 de KB3NGB
rabid open source user/evangelist

[Editor's note: These are interesting statements, and I don't deny your qualifications. But it seems like the FCC's application of these sets of rules should be documented in some fashion, perhaps in FCC orders or written into the rules. I have never been shown or found the specifics that would tie the antimodification rules with Part 15 licensing. If it's an accepted thing, then the FCC would be documenting it in some fashion because they document EVERYTHING, even typical application of typical rules.-gf]

This story ( is one of many incidents where the FCC has made arrests for the operation of non type accepted equipment on bands which require type acceptance.

Once the radio is modified by a non licensed technician it loses the type acceptance. It refers to a ham radio (does not require type acceptance because it is intended for licensed amateur use) that can be easily modified to operate on bands that require type acceptance.

Note the use of the phrase "easily modified" and how the FCC clearly states that equipment for use on type acceptance required applications must not be able to be easily modified by non licensees.

The example is dealing with hardware modifications but the same standard would apply to software as well -- it must not be "easily modified", and that includes by a reasonably technical user from the view of the FCC. The penalties, as you can see, are very harsh for violating these provisions as well. There are numerous other stories of this kind of arrest being made, on the FRS, GMRS, CB, ham and undoubtedly the parts of the spectrum occupied by wifi cards.
Even as a ham it is hard to get equipment to modify type accepted radios to work on our bands when we legally can!

This is actually an interest of mine, I have had to go out of my way to acquire equipment and software to modify radios I own which I legally can modify (motorolas and GE radios), because of the concern that non licensees could unknowingly cause harmful interference by making unauthorized modifications to commercial radio equipment.]

I hate to be a killjoy but unfortunately they are correct in their assertion that this is a legal issue properly decided by the FCC.
noah derose

I agree that they should issue a formal opinion on this issue, but they don't exactly move rapidly on much at the FCC.

[Editor's Note: They move slowly, but this issue has been discussed for several years, ever since the first SDR-like chips appeared. Which is a bit disingenuous, too, because the chips aren't really SDR in most cases, as I understand it; just much more flexible in the baseband than previous generations of chips. -gf]

For many old prism cards, the channels (frequencies) were a bitmap in the firmware.

And users had access to the firmware update programs.

Though there should be a line between users and developers - just because source is available doesn't mean it would be easy to change.

If they really need a closed source component, they could create a register-offset, content list file where they put the rest of the uploadable firmware although it wouldn't be for a foreign processor. Then the driver would load the magic FCC approved bytes to the right places to limit the power and frequency and get on with the connection.

Such would also be architecture independent (though endianness could be an issue if it isn't just bytes).