l‎ > ‎

9

FCC: We aren’t banning DD-WRT on Wi-Fi routers

Commission eliminates guidance language that called for DD-WRT restriction.

by Jon Brodkin - Nov 12, 2015 6:50 pm UTC

  • Share
  • Tweet
  • Google
  • Reddit
44 South Park Studios

The Federal Communications Commission is trying to convince people that it isn't banning third-party router firmware such as DD-WRT despite issuing guidance that sounded an awful lot like a ban.

Back in March, the FCC issued a Software Security Requirements document that said manufacturers applying for equipment authorizations should "Describe in detail how the device is protected from 'flashing' and the installation of third-party firmware such as DD-WRT." Applicants also had to answer the question, "What prevents third parties from loading non-US versions of the software/firmware on the device?"

Upon receiving criticism, the FCC insisted that there was no ban on software like DD-WRT and OpenWRT, saying instead manufacturers must prevent devices from working outside their allowed frequencies, types of modulation, and power levels so as not to interfere with other systems.

But that guidance still remained on the books, and the easiest way to comply was likely to disable installation of third-party firmware by users altogether. Today, the FCC issued an updated version of the guidance that strips out the DD-WRT reference. Instead, it now says:

Describe, if the device permits third-party software or firmware installation, what mechanisms are provided by the manufacturer to permit integration of such functions while ensuring that the RF parameters of the device cannot be operated outside its authorization for operation in the US. In the description include what controls and/or agreements are in place with providers of third-party functionality to ensure the devices’ underlying RF parameters are unchanged and how the manufacturer verifies the functionality.

FCC Engineering and Technology Chief Julius Knapp also wrote a blog post titled, "Clearing the Air on Wi-Fi Software Updates." The previous guidance raised the question of whether the FCC was "mandating wholesale blocking of Open Source firmware modifications," Knapp wrote.

"We were not, but we agree that the guidance we provide to manufacturers must be crystal-clear to avoid confusion," he wrote. "So, today we released a revision to that guidance to clarify that our instructions were narrowly focused on modifications that would take a device out of compliance."

It's still possible for manufacturers to comply by preventing loading of any third-party firmware, but the new language could reduce the likelihood of that happening.

Separately, the FCC in July proposed a new requirement for device manufacturers 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.”

This also drew criticism during a public comment period that expired this week. The issue "generated thousands of comments from individuals concerned that the proposal would encourage manufacturers to prevent modifications or updates to the software used in devices such as wireless local area networks (e.g., Wi-Fi routers)," Knapp wrote. "Eliciting this kind of feedback is the very reason that we sought comment in an NPRM [notice of proposed rulemaking] and we are pleased to have received the feedback that will inform our decision-making on this matter."

The FCC still has to finalize rules, and Knapp said the commission "welcome[s] continued input from manufacturers, users, technologists, and others."

Expand full story

Promoted Comments

  • HideyoshiJPSmack-Fu Master, in training This arguably puts more on companies like Broadcom to make sure their SoCs don't allow transmission out of spec as opposed to someone like Netgear to prevent you flashing your own firmware, at least in the long-term. I can't say they wouldn't block third party in the short-term until the SoC architecture changes, but the router manufacturers use some open source firmware themselves - I doubt they want to see OpenWRT or DD-WRT disappear.
  • byosysArs Praefectus icrf wrote:Arbelac wrote:They need to realize that this is a binary decision. Either you give access to the hardware, in which case there is nothing you can do (physical access trumps all) or you lock it out completely.

    The re-phrased question is no better than the original statement.
    I agree, this doesn't change anything. The easiest thing for manufacturers to do is still lock out third party firmware. Functionally, what's different in this statement? It doesn't use an example of open source firmware by name as a violator?

    It gives models targeted with better specs (read: targeted more towards people who want/can flash it to a 3rd party firmware) a clear way to be in compliance without locking down the firmware. If they put (as an example) hardware controls to prevent transmissions over the FCC power limit that would suffice regardless of what firmware.

    You're right in that consumer wireless devices are never going to be robust enough to prevent an adept tinkerer with hardware access from breaking transmission power limits but that isn't what this regulation is meant to deal with. It's meant to prevent the easiest/most common method of running the transmitter way out of spec and drowning out everyone else nearby.
  • lint gravySmack-Fu Master, in training This appears to require manufacturers to show that third-party software cannot make their device broadcast at frequencies or power levels or under conditions not permitted in the U.S.

    This is usually accomplished with EEPROMs in the radios themselves -- Linksys or Netgear or whoever orders a run of chips from Broadcom or Qualcomm or whoever, programmed for compliance with the target market for that device. This means they have to ship different physical routers to different countries, and it means that if you buy a router meant to be sold in a different regulatory domain than your own, you can't use the stock firmware.

    And that's all it means, because the way some of these chips are made, the regulatory domain encoded in the wireless chipset doesn't actually restrict the operation of that wireless device -- it is up to the drivers in the firmware to comply, or not.

    If you build stock drivers from source (and here we're usually talking about Linux), they are hard-coded to comply with regulatory domains encoded in the chipset, and some fairly lightweight measures have been taken to prevent tampering with the DB that contains these rules. The long and the short of it is, if you want to use a radio at frequencies and power levels at which it's not suppose to, you have to compile your own drivers.

    Or you can use a firmware which has altered those drivers to, in effect, trust the user. So if I have a router that was meant to be sold in the US but I want to use it in Japan, I can install third-party firmware with this more lenient compliance behavior, and if I say I'm in Japan, it'll go ahead and ignore the regulatory domain in the EEPROM and let me use the frequencies and power levels that are legal in Japan.

    So it's this last that the FCC is looking to change. They're saying to manufacturers, "if you allow third party firmware, prove to us that that firmware cannot override the regulatory domains". Right now they can't do that. The only way they're going to be able to is if they go beyond just encoding the regulatory domain in the EEPROM, and require the chipset to be, in effect, physically incapable of noncompliant behavior.

    This is technically feasible with some areas of compliance but not others. Frequency and power level isn't hard, but other rules like radar detection and not initiating broadcast (i.e. okay to be a client but not an AP on this channel) are areas of logical rather than physical compliance. It is not easy to see how manufacturers are going to be able to provide this assurance while still permitting third-party firmware.
  • cptskippySmack-Fu Master, in training Arbelac wrote:They need to realize that this is a binary decision. Either you give access to the hardware, in which case there is nothing you can do (physical access trumps all) or you lock it out completely.

    The re-phrased question is no better than the original statement.


    Why do you say that? Smartphones make the distinction between the baseband firmware controlling the radios that users can't typically mess with and the ROM that they can alter. Routers these days really aren't that much different from smartphones.
Reader comments 44

You must login or create an account to comment.

Jon Brodkin / Jon is Ars Technica's senior IT reporter, covering the FCC and broadband, telecommunications, wireless technology, and more.

@JBrodkin on Twitter  ← Older Story Newer Story → 

#auto

Subpages (5): 0 1 2 9 i
Comments