Why doesn’t OpenWrt autoupdate?
prpl.works
prpl.works
In short: on a lot of these devices it would be difficult or impossible to have a stable auto update mechanism. This could be due to flash size (16MB is considered large for consumer devices), or due to the state of the kernel modules responsible for hardware (e.g. wireless drivers).
Also there isn't usually a backup to the kernel in flash, so if your auto update is interrupted by a power failure or the user pulling the cord, you will have a bricked device. Good luck explaining the limitations of SPI EEPROM and compressed filesystems to a pissed off user with a brick. After the update you have to reboot, how do you schedule this on a device which is typically invisible to the user? In networks it's extremely difficult for these embedded devices to guess when someone might not be using it.
Having seen my fair share of ancient OpenWrt devices deployed in the field, the industry as a whole definitely needs to focus more on auto updates to resolve security issues.
However as the author points out, the sheer number of chipsets out there, it would be very difficult to accomplish without extensive testing.
I hope that we can all make meaningful progress toward auto updates of critical issues, but there is a long road ahead to that.
Due to size constraints most platforms use a split filesystem consisting of a large read only root filesystem and a smaller overlay for changes. The read only filesystem allows for much better compression ratios but it also means if you attempt to replace an individual package you'll end up with two copies, original in the RO and new in the overlay.
Reflashing an OpenWrt device generally consists of migrating a minimal environment over to a ramdisk, rewriting the kernel and read only portions and then writing a backup of the config files to the overlay. On failure you're likely to be stuck in whatever rescue mode the bootloader provides.
Yup. Which is why auto updates will probably never work well.
What if the user is running some custom software on the device and it doesn't have enough RAM to store the new compressed filesystem? These devices don't have swap.
Routers are a subset of embedded systems, which means lots of different platforms, possibly with vendor included quirks, AND then users who run their own junk on them (ahem).
Given that most manufacturers are loath to even release their uboot source (come on guys, it's a bootloader not missile launch codes) and most of the implementations I've seen are a ham fisted modification of an old revision of uboot; just enough to boot, but dragons exist in the code.
Short of an iPhone for routers moment (yes,the irony of Apple's extremely closed system is not lost on me) where some company creates a router which just revolutionizes the whole industry[1], I don't see it happening on a consumer level unless there is a legislative requirement.
[1] this won't happen because phones are fun and shiny and routers aren't. At least to your average consumer.
Also the internet is awesome. An OpenWrt founder replied to my comment! :D
With a hypervisor in place, you could install an image alongside a working one, then do a warm reboot to start the new image. The user would be presented with a website to confirm that they'd like to keep this new image. If the user doesn't confirm this within a fixed time period, the router would roll back to the old image.
As for the space requirements for keeping two images on the router, I wonder if anything could be done there. For example, I wonder if the new image could be applied as a 'patch' on top of the old one, stored as file diffs rather than as a standalone image. Does that sound workable?
On another note, if I had something with a hypervisor available, I'd run something other than OpenWRT on it. The primary use case of OpenWRT is these small embedded devices where such a hypervisor isn't available.
The website would be presented automatically to the user, similar to how a login page is displayed when you connect to some public WiFi networks.
> "On another note, if I had something with a hypervisor available, I'd run something other than OpenWRT on it. The primary use case of OpenWRT is these small embedded devices where such a hypervisor isn't available."
Yes, it'd almost certainly help with broadening the range of options. Until I realised I was too big I was drawn to the idea of using Xen as I'd like to see OpenMirage running on home router hardware, it seems like a natural fit. A minimal QubesOS image could also be good.
My preferred pfSense platform at both home and the office is a server-grade chassis running ESXi. My router runs in a VM on this server and I use vSwitches to connect the VM to the various ports on the 4-port Intel NIC.
I just built it like this for convenience (I already had the ESXi server) but I later found a side-benefit: if you've set up a DMZ on pfSense, you can easily attach VMs to the DMZ by associating them with the DMZ vSwitch. So, I have some untrusted VMs sitting in my DMZ and trusted VMs sitting on my LAN...all on the same piece of hardware.
I've been running this way since 2013 and it's been flawless and fast. More details here:
http://output.chrissnell.com/post/39550480075/the-jack-of-al...
Personally, I use a "Maxxwave 1106" running BSD I had laying around but it's on the more expensive side. If I was putting something together for myself, I'd get one of the small Atom boards with a couple of onboard Intel NICs.
It's a little bit more complicated to get running since it requires a custom compiled OpenWRT, but it's great to have more memory and disk space than I'll ever need in my router. I used to run on OpenWRT on reflashed consumer routers and I always had to be real careful about what I installed and ran. With the APU I can just install real `bash` and `less` and not have to deal with the crappy busybox emulations.
http://www.firewallhardware.it/en/alix_pfsense_embedded.html
I use a standard BananaPi as NAS and are very satisfied with it. It comes with a SATA interface and 1Gb ethernet.
No idea what your current setup is, but I'd guess that this router is more powerful - and comes with the advantages we discussed here: The hardware is open (you can even get one with exposed connectors/a serial cable to mess with ~everything~), the software is open, you get a 'distribution' with updates by a NIC.
It's worth the money for me, but I understand if you're considering a generic OpenWrt based setup good enough. That's what I'm on right now, what works for me until this box arrives. And for me, an upgrade to 11ac was planned anyway, so this just came up when I was looking at new hardware anyway.
Still a nice toy to play with, especially with all the connectors it offers and I can see this being a hit with iOS fans since it's supposed to be super easy to administer using their custom GUI and video tutorials, so worth the asking price.
We struggled with this since day zero. As a startup, we didn't have the luxury money to build our own boxes with loads of memory. Plus we we wanted to support all OpenWrt devices. Ultimately, we took the logic of auto upgrades (and everything else for that matter, separate story) off the aps directly and now do everything in our platform.
Currently we only support a minimal set of devices - about 15 in total. However building / maintaining the firmwares for all of these, making sure they're up to date etc. is a huge burden.
Upgrading a box for a user poses so many challenges, I can't see why this is actually OpenWrt's responsibility?
What to do about testing? New releases can (do) have bugs. Again, since we're bootstrapped, we don't have a lab so we have separate development modes and test these on customers willing to have the bleeding edge.
The Netflix Syndrome as we call it. What if someone/thing is connected - do we still upgrade? I work late, and before sleep, I usually watch some Netflix. However, our nightly upgrades pushed from our platform were ruining my enjoyment! Shock. We had to introduce a feature to disable auto upgrades if there is a device detected.
What about stragglers? Customers with very outdated firmwares were not only vulnerable but also holding our development back. In the end we upgrade all boxes that are 2 months old between 4am and 5am local time every day. Some people refused to upgrade, they like the status quo, they're used to the gotchas in a particular release.
Ok, OpenWrt is becoming hugely popular but there's still a huge knowledge gap. If people struggle to understand the difference between WiFi and broadband, how can we expect them to understand firmware let alone, why it needs to be updated.
That is exactly what happened when I tried out openwrt a few years ago. Nobody thought it was wise to say that I would need more than the 4M of flash that is in my original "the linux router". I had to use tftp to put ddwrt back on it. That requires a wired connection. Thank god I have plenty of those. People today with their wireless everything would be SOL.
As mentioned above, check out pfSense and OPNsense.
The worst part is that they don't seem to test before pushing these updates. Im back on 3.2.2RC.
Also, I thought it was assumed that letting your ISP control your router is a 'bad idea'; modem, sure, but not the router. Perhaps this just isn't important enough for you to care, but this entire thread is full of people that feel differently.
This is what I am running EG300-WU21U_OWT3.2.22-151006_1056
Kong's build for ddwrt does have command line update
OSMC has done a really nice job of an auto update mechanism and it would be great to have the same functionality for router firmware.
There is also nslug2 and opkg...
Whoa, people still use these in the days of Raspberry Pi's? Oo