Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Networking Government Open Source United States

ESR On Why the FCC Shouldn't Lock Down Device Firmware (ibiblio.org) 144

An anonymous reader writes: We've discussed some proposed FCC rules that could restrict modification of wireless routers in such a way that open source firmware would become banned. Eric S. Raymond has published the comment he sent to the FCC about this. He argues, "The present state of router and wireless-access-point firmware is nothing short of a disaster with grave national-security implications. ... The effect of locking down router and WiFi firmware as these rules contemplate would be to lock irreparably in place the bugs and security vulnerabilities we now have. To those like myself who know or can guess the true extent of those vulnerabilities, this is a terrifying possibility. I believe there is only one way to avoid a debacle: mandated device upgradeability and mandated open-source licensing for device firmware so that the security and reliability problems can be swarmed over by all the volunteer hands we can recruit. This is an approach proven to work by the Internet ubiquity and high reliability of the Linux operating system."
This discussion has been archived. No new comments can be posted.

ESR On Why the FCC Shouldn't Lock Down Device Firmware

Comments Filter:
  • by ZorinLynx ( 31751 ) on Thursday October 08, 2015 @08:46AM (#50685617) Homepage

    If they're going to mandate locking down, lock down the WiFi radio, as that's the part that uses the radio waves. The WiFi radio can be a "black box" with it own firmware, much like on cellular phones, where the cellular radio is a similar black box.

    This keeps the FCC happy, because people won't be able to violate FCC rules, and it keeps users happy because they can keep running custom software. The WiFi firmware isn't typically something you want to mess with anyway.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      If they're going to mandate locking down, lock down the WiFi radio, as that's the part that uses the radio waves. The WiFi radio can be a "black box" with it own firmware, much like on cellular phones, where the cellular radio is a similar black box.

      This keeps the FCC happy, because people won't be able to violate FCC rules, and it keeps users happy because they can keep running custom software. The WiFi firmware isn't typically something you want to mess with anyway.

      How else could they ensure that the NSA's backdoors continue to function?

    • by davecb ( 6526 ) <davecb@spamcop.net> on Thursday October 08, 2015 @08:57AM (#50685703) Homepage Journal
      That can be done in some phones, but the normal approach in embedded systems like home routers is to build and run the entire system from a single system-on-a-chip and it's eprom. The latter is sometime part of the chip. That make separation physically impossible with existing products, and means future products would have to switch to a new hardware architecture with no extra profit from the change.
      • by Bengie ( 1121981 )
        One of their main concerns is an out of spec antenna power. There is nothing stopping a SoC from having a hardware limit on the power output. There is also nothing stopping someone from hooking up an AMP and relaying the signal a much higher power. Of course anyone trying to disrupt wireless signals can easily do so. What the FCC wants to stop is the ability for the home user to change their router to run out of spec. some opensource projects open up the ability for the end user to select much higher signal
        • by davecb ( 6526 )
          That's very true of ham radio with kilowatt power levels, but this *seems* to be a problem with use of frequencies used by weather radars...
    • by NotInHere ( 3654617 ) on Thursday October 08, 2015 @08:57AM (#50685705)

      WiFi routers aren't like mobile phones with separate application processor and baseband. Instead, they only have one chip, mostly due to more cost involved in having two chips. Thats why this new rule is so bad: it doesn't mandate that there is a part that has to remain free, so the vendors do what companies always do, take the cheapest solution (this isn't wrong by itself), and lock down the only processor which does both application and baseband.

      The FCC should either mandate that there is a second, fully flashable part of the chip, or simply solve the problem itself, and this is installing proper tracking down hardware at airports where WiFi devices could interfere the wheather radar. Then they could find, stop, and make accountable for, those who abuse the freedom of their WiFi devices. As this costs money, they rather chose to limit freedom, and still remain vulnerable like before. Those who want to attack airports still can get illegal devices.

      • Comment removed based on user account deletion
      • When they outlaw X, only criminals (and government agencies) will have X.
      • WiFi routers aren't like mobile phones with separate application processor and baseband. Instead, they only have one chip,

        some phones have only one chip, and some wifi routers have multiple chips. I have examples here both of wifi routers with the wifi separate and with the wifi integrated.

        Only the very cheapest routers can only be implemented with a SoC. Lots of the more expensive ones already aren't.

    • by _xeno_ ( 155264 ) on Thursday October 08, 2015 @08:58AM (#50685711) Homepage Journal

      If they're going to mandate locking down, lock down the WiFi radio, as that's the part that uses the radio waves. The WiFi radio can be a "black box" with it own firmware, much like on cellular phones, where the cellular radio is a similar black box.

      As I understand it, that is what the FCC wants to mandate. The problem is that in order to keep costs down, a lot of the wifi hardware in the routers doesn't have separate radio firmware, everything is controlled by a single system-on-chip, sort of like those old "winmodems [wikipedia.org]" that didn't contain any firmware and instead offloaded everything to the CPU via their Windows driver.

      So the FCC's rules locking down the radio firmware turn out to mean that manufacturers would have to lock down the entire software stack, not because that's what the FCC really wants, but because in order to save costs the radio firmware is instead done as part of the "main" firmware.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        It's really worse than this. Locking down radio firmware is also *really bad*. It opens up vulnerabilities that can't be fixed and others bugs. I'm one of the people working on fixing these problems and it's a *huge* issue. There are a lot of 802.11n USB N wifi cards that don't work right for instance- scratch that. Didn't work right. In order to fix the problem we needed access to the sources for the firmware that ran on the device itself. Fortunately we had that. However this *same* thing applies to route

        • "The FCC is trying to skirt around doing its job of tracking down violators and fining them."

          How? It's difficult enough regulating imported electronics just for safety, and a lot of hardware doesn't even have a brand on it.

    • Assuming no changes were made to the FCC's rules, and if a router manufacturer were to do this.... that is, they lock down the radio portion of their router so it can't possibly be modified by the end user, but still leave the firmware of their router otherwise ordinarily modifiable as it is currently, would the manufacturer still be in violation of the current rule proposal?
      • by davecb ( 6526 )
        Mark-t writes

        Assuming no changes were made to the FCC's rules, and if a router manufacture [...] lock down the radio portion of their router so it can't possibly be modified by the end user, but still leave the firmware of their router otherwise ordinarily modifiable as it is currently, would the manufacturer still be in violation of the current rule proposal?

        Presumably, but the current problem is the opposite one!

        Right now, many vendors prefer to interpret the rules to allow them to ship binary blobs for the radio bits. Much of that is GPL or BSD, and in the process the vendors are neither honouring the GPL nor even allowing the original authors of the software contribute fixes.

        They would need a business justification or an FCC mandate to cooperate in that way: in one of the proposals, we ask that the FCC mandate published source, professional

        • of requiring firmware to be modifiable by external developers. Firmware isn't software. With software we have to jump through a lot of hoops to make sure that the programmer can't do any physical damage and that he or she has a relatively clean and sane way to program the machine. Firmware is much lower level and it's where we hide all sorts of nasty stuff. In many cases it is virtually impossible to write the firmware if you aren't sitting next to the guy who designed the hardware (sometimes it's the same

          • by sconeu ( 64226 )

            Then don't use GPL code as your firmware.

            • If they've made any modifications to the kernel (for example) then they should make that source available--but they aren't required to give you a way to re-compile that source and load it onto the hardware. And they are perfectly free to use binary blobs for the low-level bits that talk to the hardware, there's no GPL violation there--that's a proprietary executable that runs on top of the kernel.

          • Firmware isn't software.

            Bullshit. If it can be downloaded and reflashed to the device, it's software.

            If you don't like that fact, then get your shit right the first time and burn it on a mask ROM!

            • but it's not software in any sense of the understanding of the vast majority of software engineers that read slashdot--specifically because they've been sheltered from extremely low-level hardware details by various layers of firmware for their entire lives.

              x86 micro-code can be changed via flash, as can the low-level software that controls your microwaves, does that need to be programmable by random C++ hackers?

              • x86 micro-code can be changed via flash, as can the low-level software that controls your microwaves, does that need to be programmable by random C++ hackers?

                There are two possibilities:

                1. If it should be able to be changed via flash, then yes, it needs to be programmable by the user!
                2. If it should not be programmable by the user, then it should not be able to be changed via flash!

                The point is, either the functionality is fixed for the life of the item, or it should be modifiable (i.e., repairable) by the owner

                • There are very good reasons to make devices for which the firmware is changeable after manufacturing but only by the manufacturer. The manufacturer does a little bit of encryption and signs the binary blob with their secret key and the hardware refuses to run un-signed binaries (pretty much exactly what people are complaining about here with routers). Sure it can be defeated by people with a lot of time on their hands, but you can also re-write your mask ROM with enough effort.

                  Software people have an incred

                  • There are very good reasons to make devices for which the firmware is changeable after manufacturing but only by the manufacturer.

                    Name one that doesn't boil down to either (a) "the user is too stupid to know what he wants to do with his own property, so he needs the manufacturer to be his nanny" or (b) "the user might use his own property in a way that displeases The Powers That Be, and must be stopped."

                  • by Smerta ( 1855348 )
                    Re-programming an on-chip "ROM" that is really flash memory - e.g., many microcontroller bootroms / bootloaders, I get that. But if you're talking about "re-writing" the **mask ROM** - how exactly would your typical hacker do that? I'm being sincere, I'm not trying to be argumentative. (BTW, I'm familiar w/ de-capping, FIB, etc., but that is really outside the capability of 99.999% of hacker's budgets and expertise, surely you're not talking about that.)
                    • You misunderstood me: if you (as the designer/manufacturer) don't want the user to change the firmware, then use a mask ROM instead of an EEPROM (or whatever) so that he physically can't.

                      As a (wholly intended!) side effect it means that you (again, the manufacturer) can't change it after the fact either, which means it'll have to be perfect the first time.

                      In other words, the only potentially-valid reason to make it hard for the user (i.e., the owner) to modify his property is that it's built well enough tha

                    • is beyond the capability of 99.999% of all customers. If that's the standard then you just proved my point for me.

                    • There's no way to 100% block a sufficiently motivated and skilled individual--and you don't need to. We do some due diligence to make it hard for the vast majority of people to modify the software and we call it a day. Your definition of "physically can't" is based on your personal level of skill and motivation and you are [naively] assuming that pretty much everyone on Earth is the same as you.

                      There are lots of good reasons to prevent the user from modifying their hardware: protecting the user's physical s

          • by davecb ( 6526 )
            Unfortunately, the amount of low-level firmware is small, and the majority of the flashable chip is full of Linux and a GUI. The radio bits are the firmware itself, and the device driver that maps it to the routing software. All the latter bits are where we need to do repair, for both compliance and functionality, not often the firmware. Recently one vendor had a driver that on error would tie up a channel mindlessly until it timed out, which was just a tiny bit of a compliance problem (;-))
            • If the vendor refuses to fix it, then find a different vendor. A vendor could choose to make their router software modifiable by third parties (presumably at extra expense & liability) and if that is a valuable capability then presumably customers will be willing to pay for it.

              We don't allow people to rewrite the low-level software in their microwave, I don't know why we'd allow it for something like a router.

              • by sjames ( 1099 )

                The correct response, rather than locking up the entire OS and driver layer is to handle the low level stuff with a separate processor with it's own flash. The separate processor is almost an absolute requirement since the hardware is unlikely to deal well with a processor delay caused by handling an exception/fault in the OS kernel. The latter is the contentious part. The manufacturer might enjoy saving that dime by having the OS driver verify and load the firmware on init rather than loading it from onboa

                • It leads to the simplest and cheapest hardware, the easiest-to-support software stack (no dealing with customers running third-party firmware) and it meets the FCC requirements. It annoys people who want others to subsidize their desire to fiddle with commodity hardware, but that doesn't really matter because statistically those people don't exist.

                  The "correct response" is for the hacker community to build their own hackable hardware or pay extra to some company that supplies hackable hardware.

                  • by sjames ( 1099 )

                    Support?!? You mean the guy with a thick Indian accent who claims to be "Bob" who talks you through the process to unplug and replug the device? What support?

                    As for what makes it cheapest, that would be leaving it unlocked and terminating warranty if you do anything like re-flashing.

                    As for cheapest to the consumer while being in compliance, a lot of people saved a lot of money by using a re-flashed Linksys rather than the much more expensive (but no better) APs that had the needed features in the OEM softwa

                    • It's not complicated, it's how every industry has ever worked in the history of mankind ever. You just want some special exception where the government forces companies to give you hackable hardware all subsidized by the vast majority of customers who will never hack their hardware.

                    • by sjames ( 1099 )

                      You do realize we're talking about pennies per unit, don't you?

                    • Sounds like you are an expert in hardware design and you have a deep intuitive understanding of the economics of that industry. You'll be able to sell your hackable routers for pennies more per unit than the existing companies--and people will be willing to pay that because you are giving them such a valuable feature (the ability to modify the firmware).

                      Why are you wasting your time with me? Get to work!

                      And, by the way, on what planet can you purchase a separate processor with its own flash chip for "pennie

                    • by sjames ( 1099 )

                      Mostly, they already have the separate processor. They have to because the analog gear won't put up with the jitter caused by the CPU running an OS and userspace. So it's just a matter of having the flash not be co-mingled with the flash that holds the OS. OR, the processor can check the signature of the blob it gets handed before enabling Tx (that one would add no hardware).

                      Now, go fetch me a fab, and a team and I'll get right on that for you.

                      But if you object to those pennies, you should object to the new

              • by davecb ( 6526 )
                There is no market for a more expensive cheap home router, the market is for a cheaper one. It's been a race to the bottom for some time, which is why the IETF, very specifically Dave Taht, is fixing issues like bufferbload and stuck-on transmitters that the vendor's won't touch.
                • but I'm not entitled to one. If the market isn't giving you what you want then you either offer more money or make it yourself, but no one is required to make the product you want for the price you want.

                  The hacker community wants companies to incur extra expense to make hackable hardware and then pass that cost onto the vast majority of customers who have no interest in hacking their hardware. The market's answer is, "Nope".

    • i would prefer that the power that be don't have a black box sitting on my network.I guess it will turn me into a scofflaw, as they try to further restrict my right to control my own devices. If I am causing radio interference it will be easily remedied on the local level. Who needs black boxes and a government telling me i can't run my own devices how i see fit.

    • If they're going to mandate locking down, lock down the WiFi radio, as that's the part that uses the radio waves. The WiFi radio can be a "black box" with it own firmware, much like on cellular phones, where the cellular radio is a similar black box.

      This keeps the FCC happy, because people won't be able to violate FCC rules, and it keeps users happy because they can keep running custom software. The WiFi firmware isn't typically something you want to mess with anyway.

      And that's what the FCC really wants The problem the FCC is seeing right now is the modified firmware allows access to frequencies that aren't allowed to be used for WiFI in the US. This is more than just channels 12 and 13 on 2.4GHz, but also on the complex 5GHz band.

      The FCC has many complaints already from airports and other entities whose radar is being interfered with by 5GHz WiFi (the band plan is complex enough that channels are "locked out" because they're used by higher priority services like radar).

      And you really can't blame the open firmware guys either - mostly because they don't know any better and they only build one binary that works for all devices worldwide. (the available channels on 5GHz vary per country - depending on the radar in use).

      All the FCC really wants (and they've clarified it in the Notice of Proposed Rulemaking) is the steps wifi manufacturers are taking to prevent people from loading on firmware that does not comply with FCC regulations - i.e., allows transmissions on frequencies they are not allowed to transmit on.

      It can either take place as hardware (filters blocking out the frequencies), or software that cannot be modified by the open firmware (e.g., firmware on wifi chip reads a EEPROM or something and locks out those frequencies).

      The thing it cannot be is rely on "goodwill" or firmware that respects the band plan - i.e., you cannot rely on "blessed" open firmware that only uses the right frequencies (because anyone can modify it to interfere).

      The FCC has all the powers to enforce compliance right now - users of open firmware who are caught creating interference with higher priority services can already be fined, equipment seized and all that stuff (and that would not include just the WiFi router - any WiFi device like PCs can be seized if they attach to that network). That's the heavy handed legal approach they have. However, they don't want to do that, because most users probably don't realize the problem, and the FCC really doesn't want to destroy all that stuff. So instead, the FCC is working with manufacturers to fix the issue at the source.

      The problem lies in the fact that most manufacturers are cheap and will not spend a penny more, so instead of locking out the radio from interfering, they'll lock out the entire firmware.

      The FCC mentions DD-WRT and all that by name because their investigations revealed that when they investigate interference, the offending routers run that firmware (and which doesn't lock out frequencies that they aren't supposed to transmit on).

      • I haven't looked into wi-fi protocols: is is possible for an unmodified laptop/mobile to listen on an illegal channel and respond on that illegal channel?
        Is is possible for an unmodified laptop/mobile to listen on an illegal channel and respond on a legal channel?
        If the answer to both of those questions is "no" I don't see the need to lock down anything. It is one thing to accidentally operate outside of FCC regulations by using an "international" custom firmware on your router - it is another thing entir
      • Back when I used an old linux box as my AP/router, it would always say something about locking the frequencies usable by the wireless card to USA frequencies or some such in the logs. Not sure how it even knew that, maybe from the timezone data, but it did it. Why can't this be standard across all firmwares?
      • by davecb ( 6526 )
        There is a by-country database of allowed/prohibited channels: I (and the IETF committee) would love to know which vendors aren't honouring it.
      • by virve ( 63803 )

        Thanks, tlhIngan. A balanced and sensible, informative post.

        virve

    • by Bengie ( 1121981 )
      Actually, they do want to mess with the firmware. Much of the research on improving wifi is being done by Universities or private individuals modifying the firmware. Of course the amp could be closed source, but the rest of the radio shouldn't be locked down. Eric had an example were a widely popular, but later unsupported wifi router had a bug in the protocol that got trigger regularly after support was done. This bug could cause the router to spam broadcast announcement packets and lock down most of the s
    • On top of the SoC stuff that other people have pointed out, even discrete radios often don't have any permanent firmware storage. Firmware has to be loaded every time the machine boots. Thus the only way to restrict what firmware loads is by restricting the main OS/firmware, or by having the hardware do some kind of signature check which increases the cost of the hardware.
    • Because that causes the same damn problem as he's talking about here?

  • Dave Taht (best known for "bufferbloat") is working on one, as are others.
    To make your own comment, go to https://libreplanet.org/wiki/S... [libreplanet.org]
  • by Anonymous Coward

    Assuming that the routers require signed firmware images (or will in the near future), the law should require that everything needed to load new images into the router by the user should be made available (including any signing keys). Of course there should be safeguards in place to prevent malefactors from using the same information...maybe physical presence should be required for firmware re-loads?

    • by davecb ( 6526 )
      That's worthwhile: please make that comment to the FCC
    • by tippen ( 704534 )

      Assuming that the routers require signed firmware images (or will in the near future), the law should require that everything needed to load new images into the router by the user should be made available (including any signing keys).

      That entirely misses the point of why the FCC is wanting to lock down the firmware...

  • by NostalgiaForInfinity ( 4001831 ) on Thursday October 08, 2015 @09:10AM (#50685779)

    Any computer with a WiFi card can become a "router" and have the ability to exceed FCC power requirements. Furthermore, the violations of FCC policy possible with standard router hardware are pretty limited and innocuous, no matter what you do with the firmware; I can't imagine that they have ever even detected this in the wild.

    Anybody who seriously wants to boost power will just stick a hardware amplifier on their router. A 2W amplifier will cost you about $25, and an 8W amplifier about $60.

    • by davecb ( 6526 )

      Yes, the rulemaking applies to all wi-fi devices, not just COTS home routers, so it will affect wi-fi cards.

      • Please try. What keeps me from rolling my own?

        The whole "problem" is so silly it boggles the mind.

        • by davecb ( 6526 )
          It's reported as interference with safety-critical airport weather radar in another thread on this page
  • by davecb ( 6526 ) <davecb@spamcop.net> on Thursday October 08, 2015 @09:24AM (#50685877) Homepage Journal

    The problem seems to be that some few airport weather radars are interfered with by existing home routers on the same frequency. They supposedly fail to detect the channel is busy doing safety-critical radar stuff, and sit there creating interference.

    However, we can't confirm that. We don't know the brand of router, the specific frequency in question, the number of airports that have the radars or the prevalence of the problem: we just got a proposed mandate that the vendor “describe in detail how the device is protected from flashing and the installation of third-party firmware such as DD-WRT.”

  • Make it a choice (Score:5, Interesting)

    by c ( 8461 ) <beauregardcp@gmail.com> on Thursday October 08, 2015 @09:25AM (#50685893)

    Give them the choice; perpetual security updates or open source. You want to keep your stuff closed source, you make sure it stays secure. You don't want to maintain it indefinitely, you open source it. You're welcome to migrate between those options at your convenience, but those are the only acceptable states.

    Won't happen, of course, but it's got better odds than "force everyone to open source".

    • Give them the choice; perpetual security updates or open source.

      If you want real security, those perpetual security updates ought to have 3rd party audits of the code to ensure that proper security methods are being used.

  • Follow the Money (Score:5, Interesting)

    by Anonymous Coward on Thursday October 08, 2015 @09:26AM (#50685897)

    I want to know who is really lobbying for this and why. I suspect the cell phone carriers who, desparetely clinging to their cell data plan cash cows, are trying to make sure wifi falls into line when their next generation of 'G' comes out and stomps all over it. Wifi access is becoming more and more widespread, to the point I think the carriers are worried about its (mostly free) usage as an alternative to (wildly overpriced) cellular data causing people to abandon cellular companies outright in favor of wifi-only devices. I live in a rural area in the middle of all the green on a map of Pennsylvania and the only place I don't have some sort of wifi coverage is during my 20 mile commute to work.

  • Information (Score:5, Informative)

    by Solandri ( 704621 ) on Thursday October 08, 2015 @09:51AM (#50686089)
    So based on a few vague comments, I managed to track down what the issue is since neither this nor the previous /. article nor the sites opposed to it (who seem to want to portray it as a Big Evil Government conspiracy to take away your freedom) delve into it.

    Several airports use Terminal Doppler Weather Radar [wikipedia.org] for high-resolution maps of storms, rainfall, and most importantly (for airports) microbursts [wikipedia.org]. TDWR operates at frequencies from 5.60 - 5.64 GHz. That's smack dab in the middle of the 5 GHz band used by 802.11a, n, and ac [wikipedia.org]. You'll notice use of those specific frequencies (channels 120, 124, 128) are prohibited in the U.S. and Canada for this reason.

    Based on that, it sounds like the issue is that you can buy a 5 GHz device off the shelf, then hack the firmware to re-enable those frequencies. And the FCC is proposing this action because people have been doing exactly that and the FCC has received reports from the airports of such interference on those frequencies.
    • by davecb ( 6526 )
      Could you join the discussion on bloat@lists.bufferbloat.net: that's the best short description I've heard!
    • by PPH ( 736903 )

      specific frequencies (channels 120, 124, 128) are prohibited in the U.S. and Canada

      So, what do they do in the EU and the rest of the world to mitigate this problem?

      Although it's too late to change now, how did these wizards allocate such a critical frequency band to unlicensed ISM use? What do we pay these clowns for anyway?

      • My understanding is the 5GHz radar is considered pretty stupid and shouldn't have been deployed due to the interference concerns. Most deployments are on other frequencies. The 5GHz deployments are limited and generally in the US. I don't remember the details, but I remember when this was a thing when I was working on WiFi standards. I may have remembered it completely incorrectly.

  • ... this may be due, in part, to the ability to roll MAC addresses on WLAN devices. And the hissy fit that the NSA is throwing over the inability to track this as a unique identifier.

  • Two reasons:
    One, the open-source community will find a way to work around it anyway.
    Two, it'll be about as effective against criminal or terrorist hacking as the lock on a sliding glass door is at keeping out burglars: It'll deter the casual criminal, but it won't even slow down the professionals.
    • We really need an open source open hardware router. Sort of like a raspberry pi but with optimized hardware for routing.
      • All you really need for that is a microcontroller fast enough to not be a bottleneck, and two ethernet interfaces. The rest of the 'router' is just an embedded ethernet switch; you don't need it to be part of the hardware, it can be external. From there a stripped-down version of Linux, NAT routing software, and firewall software, and you're ready to go. It's been a long time since I looked but I believe all the above are downloadable right now.
  • The FCC has a perfectly valid reason to want to 'lock down' the radio portion of wireless routers/APs, just as they did when they blocked scanners from picking up cellphone calls or linear amps from being used on CB channels.

    The issue isn't what the FCC wants locked down, the issue is the manufacturers that choose to make the radio AND the computer firmware user-modifiable. The thing that has spurred innovation and creativity was the ability to load alternate software on the router/APs, NOT the ability to o

  • Should I be allowed to modify[1] my (not even a VW!) car to increase my mileage/horsepower at the expense of polluting the air?

    In fact, given the sorry state of automotive security [wired.com] shouldn't we require automtive firmware engineers to build a reliable code-integrity protection as a condition for meeting their emissions standards?

    [1] No object to read-only access, excepting of course that the code is so awful that you'll surely find a security vulnerability leading to an exploit and then we are back to modifi

  • No access point on this planet has the potential to actually cause any meaningful interference with anything by a simple change in its firmware. Either you have to tinker with the hardware, attach some serious antennas or otherwise boost its rather mediocre power, but nothing you could do to its software alone could possibly create the alleged interference causing device the FCC seems to fear.

    Actually, to create such a thing, all I have to do is modifying the hardware. Something that locking down the softwa

    • by davecb ( 6526 )
      Airport weather radars, which are both stupid and safety-critical, noted in another thread here. Supposedly some vendor was using their reserved channels, possibly by using a hacked DD-WRT
      • Then find out who used it and punish the person using a frequency they should not use. How's this the fault of the maker of the software?

        • by davecb ( 6526 )
          Not at all: in US law, the operator of these devices is responsible, even if the vendor screws up. That also means they need the ability to fix the software, of course...s
  • Linux was a bad example.

    Most of these routers with vulnerabilities run Linux

  • by nbritton ( 823086 ) on Thursday October 08, 2015 @04:07PM (#50689215)

    The last time I checked 900 MHz, 2.4 GHz, and 5 GHz was open to the general public. Why is the FCC even trying to dictate what we can do on these bands?

  • I strongly agree that the FCC should not ban aftermarket firmware and I am involved (albeit in a minor capacity) in OpenWRT development. However, I don't buy ESR's argument about why. He states that "The present state of router and wireless-access-point firmware is nothing short of a disaster with grave national-security implications," and his argument revolves entirely around us needing the ability to fix the situation. Unfortunately, we do have the ability to fix the situation today, with loads of flashab

Avoid strange women and temporary variables.

Working...