from the thumbs-in-the-ears-and-fingers-wiggling dept.
El Reg reports
The open router Linux disto OpenWrt, 15.05 "Chaos Calmer" [named after a cocktail], has hit the intertubes.
One highlight of the release is an update to Version 3.18 of the Linux kernel, and security has been upgraded with ed25519 package signing support, and support for jails and hardened builds.
[The big news, however]--at least according to the project's announcement [permalink]--is a "fully writable filesystem with package management".
This, OpenWrt explains, gives users different options for installation and customisation. Instead of having to use a vendor's application and selection framework, OpenWrt can now be configured using developer-supplied applications.
"OpenWrt is the framework to build an application without having to build a complete firmware", the announcement says, while users get "full customisation [to] ... use the device in ways never envisioned".
That almost sounds like a challenge to America's Federal Communications Commission, which late in August issued a proposed rule-making that would demand Wi-Fi "lock down".
[...] [The device support for Chaos Calmer] has now passed 950 products from 159 vendors, with new devices added from Mediatek, Marvell, Broadcom, Freescale, AllWinner, and Raspberry Pi.
Previous: New FCC Rules Could Ban WiFi Router Firmware Modification
Related Stories
Hackaday sounds the alarm and along with ThinkPenguin, the EFF, FSF, Software Freedom Law Center, Software Freedom Conservancy, OpenWRT, LibreCMC, Qualcomm, and others have created the SaveWiFi campaign (archive.is capture, real link is at this overloaded server) , providing instructions on how to submit a formal complaint to the FCC regarding this proposed rule. The comment period is closing on September 8, 2015.
From Hackaday:
Under the rule proposed by the FCC, devices with radios may be required to prevent modifications to firmware. All devices operating in the 5GHz WiFi spectrum will be forced to implement security features to ensure the radios cannot be modified. While prohibiting the modification of transmitters has been a mainstay of FCC regulation for 80 years, the law of unintended consequences will inevitably show up in full force: because of the incredible integration of electronic devices, this proposed regulation may apply to everything from WiFi routers to cell phones. The proposed regulation would specifically ban router firmwares such as DD-WRT, and may go so far as to include custom firmware on your Android smartphone.
A lot is on the line. The freedom to modify devices you own is a concern, but the proposed rules prohibiting new device firmware would do much more damage. The economic impact would be dire, the security implications would be extreme, and emergency preparedness would be greatly hindered by the proposed restrictions on router firmware. The FCC is taking complaints and suggestions until September 8th.
Leave a comment for the FCC via this link to the Federal Register
The OpenWRT project is turning 20 years old this year. During that time they have adapted to existing hardware products. Now the team has the idea to produce their own, fully supported hardware to run their software on:
It is not [a] new [idea]. We first spoke about this during the OpenWrt Summits in 2017 and also 2018. It became clear start of December 2023 while tinkering with Banana Pi style devices that they are already pretty close to what we wanted to achieve in '17/'18. Banana PIs have grown in popularity within the community. They boot using a self compiled Trusted Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the boards are already fully supported by the upstream Linux kernel. The only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware blobsrunning on separate cores that areindependent of the main SoC running Linuxand the DRAM calibration routines which are executed early during boot.
I contacted three project members (pepe2k, dangole, nbd) on December 6th to outline the overall idea. We went over several design proposals, At the beginning we focused on the most powerful (and expensive) configurations possible but finally ended up with something rather simple and above all,feasible. We would like to propose the following as our "first" community driven HW platform called "OpenWrt One/AP-24.XY".
Together with pepe2k (thx a lot) I discussed this for many hours and we worked out the following project proposal. Instead of going insane with specifications, we decided to include some nice features we believe all OpenWrt supported platforms should have (e.g. being almost unbrickablewith multiple recovery options, hassle-free system console access, on-board RTC with battery backup etc.).
This is our first design, so let's KiSS!
The preliminary hardware specifications are included in the message and it will contain a pair of flash chips for redundancy with the aim to make the router harder to accidentally brick during an update.
Previously:
(2021) The Accident which Made the WRT54G Legendarily Popular
(2018) Reunited with LEDE, OpenWrt Releases Stable 18.06 Version
(2015) OpenWrt Gets Update in Face of FCC's Anti-Flashing Push
(Score: 1, Interesting) by cloud.pt on Monday September 14 2015, @05:35PM
It's the type of challenge I believe would be best suited to take place after regulation/legislation was actually in place, so you can circumvent it with measures like this. The FCC's goal of restricting routers firmware's is obvious, and it won't stop to flashing the thing. Releasing something like this right now, before they even let out the final regulation, is like saying "hey authorities, you banning marijuana in smoked form, I'm just gonna eat it. BAN THIS" (eventually, marijuana is banned in any form and the joke's on the joker)
(Score: 2, Disagree) by Gravis on Monday September 14 2015, @07:46PM
The FCC's goal of restricting routers firmware's is obvious
WRONG, DUMMY! the only interest the FCC had was in restricting how the radio could be manipulated. to cut costs, most of the radio system has been incorporated into the SoC and can be modified to operate outside of regulation power limits. the FCC doesn't give a shit about what firmware you use, they just care that people not be able to exceed a specific broadcasting power limit. SoC manufacturers can fix this "issue" by putting artificial radio restrictions on write once/read many ROM area in the SoC.
(Score: 2, Interesting) by Nerdfest on Monday September 14 2015, @10:34PM
You may want to check around. The EFF and others are very much fighting this as despite what you say, questions have raised at FCC meetings about specifically blocking this sort of thing. From what I've read, this is not FUD, it's an attack on owning your hardware.
(Score: 2) by frojack on Tuesday September 15 2015, @12:02AM
I suggest you keep reading.
The FCC only wants to protect the RADIO portion of the router to keep it withing licensed sectrum and power. It is FUD. and you are spreading it.
No, you are mistaken. I've always had this sig.
(Score: 2) by kurenai.tsubasa on Tuesday September 15 2015, @12:21AM
That's what I had thought at first as well. Preventing software-defined radios from transmitting improperly would be within their purview. This is from March 18 [fcc.gov] so perhaps there have been changes I'd appreciate if you would advise about. (Followed a link from an August 31 Hackaday article [hackaday.com].)
So there's a bunch of stuff open to interpretation until I got to this damning guideline (third-party access controls #2):
What prevents third parties from loading non-US versions of the software/firmware on the device? Describe in detail how the device is protected from “flashing” and the installation of third-party firmware such as DD-WRT.
This seems to be about more than just ensuring software-defined radios operate according to their FCC license.
(Score: 2) by frojack on Tuesday September 15 2015, @01:36AM
Try the ARS article. They had some more insight.
However, if the radio blob is lumped right into the main operating system blob, I can see where some manufacturers might think they have no choice but to lock it all, even though the FCC rule making isn't even finalized yet.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by kurenai.tsubasa on Tuesday September 15 2015, @03:31AM
Ah, ok. Thanks! Relevant response from the FCC as noted in a Techdirt [techdirt.com] article linked from ARS [arstechnica.com]:
"(FCC rules) require that the devices must ensure that under all circumstances they comply with the rules. The majority of the devices have software that is used to control the functionality of the hardware for parameters which can be modified and in turn have an impact on the compliance of devices. Our rules do permit radios to be approved as Software Defined Radios (SDRs) where the compliance is ensured based on having secure software which cannot be modified. The (FCC's) position is that versions of this open source software can be used as long as they do not add the functionality to modify the underlying operating characteristics of the RF parameters. It depends on the manufacturer to provide us the information at the time of application on how such controls are implemented. We are looking for manufacturers of routers to take more responsibility to ensure that the devices cannot be easily modified."
So, there are still some troubles, but it's clear the FCC is willing to listen to concerns. The biggest trouble in my mind is that it will be up to manufacturers to ensure that the software-defined radio blob is separate from the other IP/IPv6/NAT/uPNP/what-have-you functionality. However, will manufacturers have any incentive to create such a separation of concerns? Consumer-grade equipment manufacturers, probably not. I suppose those of us who want more control can get an Intel wireless chip and put it in a server of our own making.
I suppose a workaround could be explicitly treating the original vendor's SDF driver as an opaque blob, which may meet the concerns the FCC voices above. I assume if one can show it's byte-for-byte the same, one would be good! Only nightmare: vendors who will go out of their way to make interacting with that blob a nightmare. So, the peril is not so great, but it's the government and greedy, no not even greedy, but jealous vendors after all.
As both Techdirt and ARS report, the FCC is open to comments. Techdirt directs us here [fcc.gov] to leave such comments.
(Score: 3, Insightful) by frojack on Tuesday September 15 2015, @03:46AM
The biggest trouble in my mind is that it will be up to manufacturers to ensure that the software-defined radio blob is separate from the other IP/IPv6/NAT/uPNP/what-have-you functionality.
Exactly, and I think that might an issue, not only in routers, but also in mobile phones. They seem to have it pretty well under control in phones, or at least everybody doing a phone rom goes out of their way to leave the radio alone, if for no other reason than they need it to work.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by jmorris on Tuesday September 15 2015, @06:40AM
That is the nub of the problem here. Everybody leaves the cell radio alone because a) it is horribly complicated, b) entirely undocumented but mostly c) has to interoperate with the cell towers so jacking with it is mostly pointless.
The WiFi radio on the other hand is an entirely different kettle of fish. While the firmware blob implementing the actual WiFi protocols is beyond the comprehension of 99% of even embedded hackers, tinkering around the edges... especially since the regulatory enforcement is already so neatly split out and even fully parameterized to be able to load per country values, monkeying with it to get a bit more power or move slightly off band into virtually private bandwidth is a lot more attractive, especially since it generally only has to interop with other equipment also under your control. They really get ulcers over the 5Ghz band and it's shared spectrum with airport radar systems in many places.
While I do feel their pain, the long term solution is to stop trying to ban anything that MIGHT be misused. This is the gun control argument's defective thinking infecting other areas of law. Software defined radio changes the old rules. Before, each radio had to be licensed anyway and demanding it couldn't be field converted into a different radio service didn't impose much hardship since it was usually impractical anyway. Now it is software. Requiring totally artificial DRM locks everywhere isn't going to work. The ability to run software defined radio is going to quickly get to a point where all computing will have to be locked down to stamp it out and that will be a tough sell.
Educate the hacking community on the need to stay inside the band plans established per country, make sure everyone actually knows the why; what other services will be impacted by straying outside the established bands. Maybe even get the Ham Radio operators involved, maybe even allow them to hack/experiment under controlled conditions. (Special permits to allow the to operate on frequencies unused in an area at safe power levels and under their licensed ability to ensure all that is actually followed.) Certainly encourage them to help foxhunt rogue transmitters. Then punish those who refuse to follow the law anyway, a few very public examples would suffice. Far better than punishing everyone.
Radios don't cause malicious interferrence, people do. Doesn't sing as a slogan, needs work. :) Suggestions welcome.
(Score: 1, Flamebait) by Nerdfest on Tuesday September 15 2015, @12:25AM
Apparently, manufacturers are releasing updates that lock existing routers, not just new ones, and lawyers at the meetings asked "how are you going to lock out third party firmwares like DD-WRT". With companies like Microsoft and a few others around, this could even be extended to locking you out of installing Linux on your PC. Any legislation that can be abused *will* be abused.
(Score: 2) by frojack on Tuesday September 15 2015, @01:33AM
Is this fud or can someone Name one such manufacturer?
Note that some manufacturers might also lock it just because they can, and they don't want the warranty issues of jail broken routers any more than Apple wants jail broken phones.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Tuesday September 15 2015, @04:22AM
Ummm... the openwrt devs have been working on this release for a long time more than the couple weeks since FCC made its announcement.
The feature list has NOTHING to do with the FCC announcement.
(Score: 1) by cloud.pt on Tuesday September 15 2015, @12:56PM
That I didn't know. Yet there might have been room for some poise on releasing such stuff in light of recent FCC "developments". Maybe delay it for a while so your (apparently long time coming) new features don't get insta-hammered by consumer policy
(Score: 4, Interesting) by albert on Monday September 14 2015, @08:15PM
Unless there is hard-to-replace GPL 3 code, that ed25519 package signing just enabled tivoization [wikipedia.org]. Devices can ship with OpenWrt and you'll be blocked from doing updates because you won't have the key.
(Score: 3, Informative) by darkfeline on Monday September 14 2015, @08:54PM
fully writable filesystem with package management
OpenWRT has always had that. It's a Linux distro after all. I set up an OpenWRT router two years ago, which had a "fully writable filesystem with package management". (Incidentally, just yesterday I updated said router to OpenWRT 14.07 "Barrier Breaker".)
It doesn't look like OpenWRT's new release has anything to do with the FCC stupidity. In fact, rather than OpenWRT responding to the FCC, it feels more like the FCC is responding to OpenWRT's existence. OpenWRT has existed for a long time, providing quality FOSS router firmware to replace preloaded proprietary shit.
All OpenWRT releases are named after cocktails, but what's really great is that they even provide a recipe banner on SSH login:
Join the SDF Public Access UNIX System today!
(Score: 2) by chewbacon on Wednesday September 16 2015, @11:08AM
There are some wifi regulations it respects out of the box, like channel restrictions, that you have to patch to get around. This has sounded more like the FCC will want the wifi firmware locked down, not necessarily the whole device.