On Tue, 9 Dec 2014, Dave Taht wrote:
Well, I have heard this regulation as yet another excuse from several vendors for not opening their firmware.
That doesn't surprise me. Radio vendors used similar excuses for charging people thousands of dollars for radio programming software and cables. The better ones had a jumper (or 0-ohm resister) that could be removed to allow programming.
http://wiki.prplfoundation.org/wiki/Complying_with_FCC_rules_on_5ghz_wifi I DO care a lot about planes not crashing due to someone streaming netflix in the flight path.
Well, I'll say the same thing here that I've said about wifi and phones on airliners. If the system is really that simple to cause crashes with, then why are the terrorists planting bombs instead of just shipping a few packages that contain phones that turn on during flight and cause the planes to start falling out of the sky?
It's just not that hard to build your own equipment to operate on these frequencies nowdays. For $200 you can now by a software defined radio board that will transmit from 10MHz to 6 GHz, spend a bit of money to build an amplifier and you can do FAR more damage to a radar than an access point will.
Also remember, this is weather radar, not the radar that tracks the aircraft.Also remember that APs operating on these frequencies will be pretty easy to track down if they do cause grief. It would be better to have this sort of thing taken care of by cracking down on offenders than by trying to police the devices.
After all, there's nothing that can prevent someone from buying an AP in europe, putting it in their luggage and plugging it in in the US. all the firmware lockdown in the world isn't going to prevent this. In fact, making it hard to change the country code means that when hardware does move around the world, it IS going to be operating on the wrong frequencies, because the user has no way to change it.
If you can't tell, this topic and how it's mis-interpreted by so many people, some deliberatly, really annoys me. :-)
David Lang
On Tue, Dec 9, 2014 at 12:14 PM, David Lang <[email protected]> wrote:We really need to find out what the new FCC requirements are. People have been claiming that the FCC requires all sorts of lockdowns that they don't actually require for decades (when I first got into Ham Radio, we were hearing that any radio able to operate on the business bands had to be locked down to prevent the owner from changing it's frequency. It wasn't true) If they are saying that the RF portion can't be modified in a Software Defined Radio, that would be somewhat reasonable, saying that the software implementing the 802.11(whatever) protocol on that RF portion must be locked down is less so, and saying that the main OS on the router must be locked down is completely unreasonable. I would be surprised if they required that the OS can't be changed. As for the implementation of the 802.11(whatever) protocol, I would be surprised if they required this to be locked down, but not dumbfounded now that I've finished the rant, reading the statement quoted on that wiki page:Applications for certification of U-NII devices in the 5.15-5.35 GHz and the 5.47-5.85 GHz bands must include a high level operational description of the security procedures that control the radio frequency operating parameters and ensure that unauthorized modifications cannot be made.All that it is talking about is the radio frequency parameters. The followup/clarification is again talking about the RF parameters. Remember, when the FCC is talking about a 'device', they are talking about the radio, not the entire computer that has a radio as part of it. According to the background, they are worried about interference with radar, so this could mean that the firmware needs to have a mechansim to detect the radar and not transmit on that frequency, but this is only a few channels. You could still have an opensource, non locked down firmware that just didn't give you the option of using those channels, and a signed firmware that did. This does not require secure boot or any of the other lockdown methods that are being talked about on that page. I hope these are not the "official" openwrt recommendations (and if they are, why are they not on an openwrt page?) David Lang On Tue, 9 Dec 2014, Eric Schultz wrote:Dave, Thanks for the quick response and I appreciate your passion. No one here wants Secure Boot or DRM at all. I personally find the idea abhorrent and no one at prpl wants it. The difficulty is figuring out how companies can comply with the regulation in a way that doesn't require hardware be locked down. I wish I could avoid ever thinking of this topic but unfortunately, if companies don't find a solution that fulfills the FCC's requirements, they're going to go with DRM. I want to see if we can give manufacturers a solution that avoids DRM entirely. I'd be happy to learn more about the make-wifi-fast effort and to see how we can facilitate it's success. Thanks a ton, Eric On Tue, Dec 9, 2014 at 11:49 AM, Dave Taht <[email protected]> wrote:On Tue, Dec 9, 2014 at 9:11 AM, Eric Schultz <[email protected]> wrote:All, I work for the prpl Foundation, an open source foundation organized by a number of companies, most related to MIPS. One project we work with externally is the OpenWrt project. Recently one of our members mentioned a new FCC requirement (described at http://wiki.prplfoundation.org/wiki/Complying_with_FCC_rules_on_5ghz_wifi) which requires wifi hardware devices to restrict modifications in ways that were not previously required. Some of the suggestions the company had internally for complying would be to use features like Secure Boot and other types of DRM-like mechanisms to prevent routers from being modified. This obviously would be quite bad for the OpenWrt ecosystemIt would be bad for everyone. Worse, since the research contingent making progress on keeping wifi working in the first place in the face of enormous growth, is centered around the ath9k chipset, additional rules and regulations centered around DRM are likely to choke off further development of then new ideas and techniques needed to keep it working.so we agreed as a group to try to provide hardware companies with a way of complying without harming the community.My view is mildly more extreme - the 2.4 and 5.8 ghz spectrum currently allocated to wifi is the *public's* spectrum. I am deeply concerned about further intrusions on it by things like this: https://www.qualcomm.com/products/lte/unlicensed and we need more spectrum, not less, in order to keep wifi for everyone, working.I'm looking to find individuals (and other companies!) interested in working with myself and the foundation, companies, the OpenWrt communityand eventually regulators to provide guidance to hardware companies on how to best comply with these rules.I intend to continue ignoring them to what extent I can. Regrettably this situation is contributing to community members being unable to apply new queue management techniques to new standards like 802.11ac, and seems to be the source of all the proprietary ac firmware. I think a first step would merely to be for a big maker to publicly release their 802.11ac firmware and let the chips fall where they may.If you're interested in getting involved or just would like to know more, please get in touch with me. We want to make sure that routers are hackable and we could use all the help we can get.+10. I would like to see prpl participating in the make-wifi-fast effort, also. http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdfThanks and I look forward to working with you, Eric -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org [email protected] cell: 920-539-0404 skype: ericschultzwi @EricPrpl _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel-- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks-- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org [email protected] cell: 920-539-0404 skype: ericschultzwi @EricPrpl _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
