Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
This brings two questions I suppose:
- can this lead to a really free Atheros driver for Linux?
- what is the status of the devicescape stack merge, which was meant to improve things?
Really free Atheros driver for Linux
Posted Nov 15, 2006 16:42 UTC (Wed) by corbet (editor, #1)
2) See this note for some current info on Devicescape. It remains a slow process.
Posted Nov 15, 2006 18:33 UTC (Wed) by proski (subscriber, #104)
Basically, the job of a wireless driver should be to send and receive 802.11 packets. Presenting this to the userspace should be done by the 802.11 stack.
The networking in Linux is implemented through network devices. A single network device is typically one physical device connected to one subnet on one medium with one packet queue. Note the inherent overload of functions - the same interface represents hardware, a subnet, a medium and a network queue.
An advanced 802.11 device can act as one physical device on one medium (radio channel) with multiple subnets (virtual APs and WDS connections). The packet queue is common on the physical, but users may want to regulate it on the subnet level as well.
The question is basically how we want to map this to the traditional network device paradigm. I understand that d80211 associates the physical device and the network queue to the master interface and the medium to the "wiphy", whatever it is.
It's desirable to have one interface representing the common part of the wireless device. If we move everything to wiphy, we lose control over the queue because it's done on the network interface level. If we move everything to the master device, we won't lose anything. However, Johannes seems to dislike having a network interface without the ability to send or receive packets. Unfortunately, the alternative is a major surgery of the networking to decouple queue management from the network devices.
Posted Nov 15, 2006 18:41 UTC (Wed) by corbet (editor, #1)
Posted Nov 15, 2006 19:30 UTC (Wed) by N0NB (guest, #3407)
What regulatory action that could be taken against the authors of a free
driver that allows adjustment of the radio outside of its approved
parameters is an interesting question. I'm guessing that to the FCC it
would be no different than the CB shop that modifies radios for operation
beyond the approved 40 channels and their power and modulation limits.
Or, the importers that sell "CB" radios at truckstops that can be
trivially "modified" to illegal operation.
Unlike the Amateur Radio Service where licensees are allowed and
encouraged to modify their equipment for operation on the amateur radio
bands, every other radio service is disallowed from similar modifications.
The FCC has held both providers and end users liable for violation of its
rules. I'd advise the OpenBSD Atheros authors to tread carefully.
Posted Nov 15, 2006 20:58 UTC (Wed) by leoc (subscriber, #39773)
Posted Nov 16, 2006 12:37 UTC (Thu) by N0NB (guest, #3407)
Like most everyone, I am cheering for fully free drivers. I just don't want someone finding themselves in court defending themselves out of ignorance for writing a driver that is considered to be in violation of federal and perhaps international radio regulations. Forewarned is forearmed.
Posted Nov 16, 2006 0:04 UTC (Thu) by drag (subscriber, #31333)
In his efforts to understand how the ipw3945 driver controls the firmware, Damien found that the binary daemon was simple to bypass, offering no real control. "I was able to make the daemon think it was in another regulatory domain," he explained, "just by adding a few lines of code into the GPL'd part of the driver." The binary-only daemon is described as necessary due to FCC regulations, causing Damien to retort, "I think Intel (and Atheros) use FCC rules as a pretext to hide intellectual property in the binary-only portions of their drivers." He went on to explain that the Intel regulatory daemon, as well as the Atheros HAL, implement a number of complex algorithms, including automatic calibration of the radio power based on temperature variations, and dynamic tuning of the radio sensitivity based on received signal strength. "These algorithms go far beyond the simple enforcement of regulatory compliance," he added, "and can really make the difference by extending the operating range of the adapter, improving throughput in various environmental conditions, and reducing power consumption. That is why vendors want to keep these algorithms secret.
Posted Nov 16, 2006 4:17 UTC (Thu) by proski (subscriber, #104)
Technical restrictions are no substitute to law, morale and common sense. They can protect honest people from honest mistakes, but closing the source goes far beyond common sense. It's a typical case of security through obscurity with an additional effect of hobbling free software.
Posted Nov 16, 2006 15:51 UTC (Thu) by pizza (subscriber, #46)
I've been saying this all along, and it's only been reinforced with my dealings with wireless chipset companies . They're far more worried about their "Intellectual Property" being exposed (or rather, worried that someone else will claim they mis-appropriated IP, and get sued..)
The MadWiFi HAL does far, far more than restrict RF-level operation; if that's all it did it would be downright tiny. And as others have said, you can always lie about the country information and generally wreak havoc with your 15mW transmitter.
 My day job is writing 802.11 drivers.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds