DEADLINE - 8 Sep 2015 - FCC Comment Period for third-party firmware

richb-hanover

Distinguished
Dec 21, 2013
34
1
18,540
As you may know, the FCC has issued a Proposed Rule that affects us all. Although it started out as a good idea, the current proposal would (in part) make it impossible to install third-party firmware such as OpenWrt, DD-WRT, Tomato, Gargoyle, etc. on a home router.

WHAT YOU CAN DO:

  • ■Learn more about the problem. The Save Wifi page at LibrePlanet has lots of good information.
    ■Submit a comment to the FCC. Click the green SUBMIT A FORMAL COMMENT button on the FCC comment page
    ■Spread the word to your friends, and other forums/blogs. (The millions of the responses about Net Neutrality spawned by John Oliver changed FCC Policy. We can, too.)
    ■Finally, come back here and post your comment in the forum so that others know what you've said!
Tips for effective comments:

  • ■Tell how this rule would affect you. What would it prevent you from doing? Why is that important?
    ■Anyone can comment, but US citizen's opinions have the most weight with the FCC
    ■Use facts, not invective. No cussin'
The deadline for comments is short - Tuesday, 8 September 2015. Plost comments now - this weekend - before you get too busy.

PS: I submitted my comment and also posted it to http://richb-hanover.com/comment-to-the-fcc-re-consumer-router-firmware/
 
Locking non-allowed RF channels and power settings do not necessarily mean a ban of third-party firmware: the RF chipset has its own proprietary firmware running the software radio and it would be entirely possible for Broadcom, Qualcom and other WiFi chipset manufacturers to implement the RF locks in their RF chips to prevent the SoC firmware from setting those up. How many RF chipsets' firmware have been successfully hacked? None that I know of.

Implement the locks in the RF chips, something like having the RF chips lock to the first region configuration request they receive, and there won't be any need to lock the SoC firmware. It won't stop devices from moving across borders but then again, neither would banning third-party firmware anyway.
 

Yes, but... I don't think that's what the FCC's proposing - to require that the locks go in the RF chips. The rule says (paragraph 20 in the FCC URL above), in part,

...To minimize the potential for unauthorized modification to the software that controls the RF parameters of the device, grantees would have to implement well-defined measures to ensure that certified equipment is not capable of operating with RF-controlling software for which it has not been approved. All manufacturers of devices that have software-based control of RF parameters would have to provide specific information about the software capabilities of their devices...

I don't think the FCC intended to have bad consequences, but my reading of the rules would make it very hard for a vendor of current consumer routers to comply without locking everything down. (Because margins for this kind of gear are so thin, I don't envision manufacturers paying anything extra for a locked down RF chip...)
 
All the FCC is requiring is that manufacturers prove that they implemented adequate locks. If the RF chipset manufacturers implement those locks via OTP region codes, then the downstream hardware manufacturers no longer need to prove anything since their firmware cannot override the RF firmware's locks once they have been programmed.

Even if the firmware-locked RF chips cost a few pennies extra, hardware manufacturers end up saving time and effort by not having to seek the FCC's approval for each firmware revision.

As for how to enforce device programming, the simplest way would be to start the RF chips in full lock-down by default where the only available API is region setting until a region is set and that region would get set during production testing to whatever region the unit is destined to. This way, no region lock = no radio.