FCC Clarifies the Ask for Wi-Fi Routers

As we explained recently, the FCC is asking for input on regulations for home routers with built-in Wi-Fi. Chief Engineer Julie Knapp has written a blog post clarifying his concerns about radio compliance and stressing his desire to allow hackers to improve home router code:

As I wrote last month, this proceeding has taken on a significance beyond the Commission’s original intent. One of our key goals is to protect against harmful interference by calling on manufacturers to secure their devices against third party software modifications that would take a device out of its RF compliance. Yet, as the record shows, there is concern that our proposed rules could have the unintended consequence of causing manufacturers to “lock down” their devices and prevent all software modifications, including those impacting security vulnerabilities and other changes on which users rely.

This statement, while reasonable on its face, isn’t going to satisfy the complainers, who insist that no part of the router code, not even the part that relates to regulatory compliance, should be locked down:

Not even the small and specialized portion of the firmware that is related to radio operation should be locked down.

As I wrote, the design of Wi-Fi chips doesn’t permit the FCC to get what it wants the 150 people who complained to the FCC about the scope of its inquiry to get what they want without a hardware redesign.

The FCC isn’t imposing rules at this point, it’s just asking questions. Knapp’s blog post suggests that the FCC doesn’t have any specific answer to the question of how to ensure regulatory compliance as long as there’s some system in place that should at least get close to ensuring compliance in a broad number of situations. Knapp is not the kind of guy who insists on 100% compliance as long as he can get a close approximation; at a recent Silicon Flatirons talk, he explained that a lot of FCC regulations rely on “rough cut justice” that uses an easy-to-measure proxy for the ideal kind of test.

While my previous blog post described one way of securing the power levels, there are others. The code that controls the radio can be contained in a not-easy-to-modify flash memory, and it could enforce power limits. That code could also do some geo-sensing to ensure the country code matches the locale in which the router is placed. There could also be some application code that checks the programmed power levels and reports modifications that take the device out of compliance, and potentially even notices if an external antenna has been changed.

Or the folks who manage open source router projects could simply attest that their code complies and submit boxes to the FCC. Any of those things will work, and all of them will work pretty well.

The issue that most people don’t appreciate here is that Wi-Fi chips don’t have any features built-in (other than DFS-II compliance, which senses military radar signals and avoids them as best as it can) to ensure compliance, so compliance is effectively an honor system.

The other issue that isn’t widely appreciated is that there’s no money in developing home router code at this point, so the only way to make home routers better is through open source projects sponsored by the firms with a legitimate interest in good home routers, which would be major ISPs and network equipment vendors. Consumers, except for computer freaks, simply want the cheapest router they can get, as do the ISPs who buy in bulk on behalf of their customers. Home router deals are extremely cutthroat, specifications are vague, and acceptance tests are superficial and arbitrary.

So everyone will benefit from better open source router code, even if its regulatory compliance procedure is less than rigorous. If router code doesn’t live up to expectations – which could happen if developers serve a narrow set of interests or go down ratholes trying to optimize for bad protocols as some have suggested – then all bets are off and we can revisit regulatory compliance.

Let’s see what the open source developers can produce if they’re given a little support.

 

  • One of my personal concerns is that the vendors have responded in the past by locking down setting the parameters for US use via “binary blobs” of firmware.

    I live in Canada, with subtly different rules. Not being a lawyer and a ham at the same time, I can’t tell if I’m in compliance. If I’m not, it’s legally my fault.

    I’d really like to check my country setting and know that the compliance-critical settings are correct (;-))

    • Is that the case even for routers you buy in Canada? I’ve never seen that in US routers, but it’s certainly possible.

      • The one I use now was ordered by my ISP from the manufacturer with Canadian settings. Neither they nor I can tell if it’s set correctly (;-))

        Previously the ISP only provided a cable modem, and I did set the country from US to Canada on my privately-purchased wi-fi router.

        • They should have an acceptance test that measures power output. Some very small ISPs might not be able to do that, but when I was building home routers for big US ISPs they tested this sort of thing.

          • A somewhat smaller and more agile ISP notes (in email, today) they use an app on Android to sanity-check the routers they buy: conspicuously wrong power levels and frequency sets can be caught in a smoke-test. My current ISP is large, a monopoly and startingly non-technical.