Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] iGuardian "enterprise-grade" home router

Richard Pieri wrote:
> How do you go about updating the OS?
> With an embedded OS you back up your settings, restart the device in a
> special run mode, write out an image to local storage, restart in the
> normal run mode, and restore your settings. Some update mechanisms
> perform the settings backup and restore automatically; some don't. If
> something goes wrong then you have a brick.
> With a "live" OS you run a tool to install updated programs, typically
> using some kind of package management system. Restarting is rarely
> required.

I guess maybe you need to update your notion of how a modern embedded
system works. There are still embedded devices being produced that work
the way you describe, but more commonly now, thanks to inexpensive flash
storage, they operate more like a regular system with a hard drive.

OpenWRT supports optware package management, for example. You should be
able to update packages on the fly, without a device reboot. (I've
installed packages this way on my routers running Tomato USB.)

I run Ubuntu systems off of small thumb drives, which go through
identical updating procedures as full systems, and there is no technical
reason why a router appliance can't follow this model.

Devices like Ubiquiti Networks' EdgeMAX, that runs a Debian derivative,
from a software perspective probably behave closer to full systems than
embedded devices, even though they are built on low power appliance

Even in the case where the device firmware is treated as one big blob,
lots of devices now feature a small bootloader partition that never gets
overwritten by updates, making them virtually "unbrickable." An update
gets downloaded to and written to a separate partition, then sets a flag
and schedules or triggers a reboot. On reboot the bootloader sees the
flag and runs the OS from the new partition. If that fails to start you
can manually reboot and interact with the bootloader to switch back to
the old firmware, which is still present.

(There are dozens of variations on the protected bootloader concept, and
not all work as described above. For example, it's quite common for
Android devices to have a boot loader, a recovery partition (minimal OS
for doing backups and reloading OS images), and an OS partition. Each
can be separately reflashed.)

Personally, I'd rather have a router/firewall appliance in which the
firmware can't be altered without a physical switch being flipped on the
device. That way you have full control over when the firmware gets
altered, and you know with certainty that you return to a known state
after reboots. (For this to be most effective, your router should also
have no local storage and settings storage that is similarly hardware
protected from modification.)


Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /