Try Turris Omnia, the open source router | Hacker News Reader

Try Turris Omnia, the open source router

opensource.com

84 pointsmadspindel50 comments

I'm happy owner of two Turris Omnias for 2 years (I use them to interconnect my appartments in two distinct cities into the single LAN, via OpenVPN).

I highly recommend this router. A bit pricey, but it is worth every penny.

Ability to install run arbitrary software is incredible (not only from packages, configure/make/make install works too!). I run openvpn (see above), dnscrypt-proxy, aws cli tools (for dynamic DNS updates), influxdb, grafana, microsocks SOCKS5 proxy (for filtering out Windows 10 updates and telemetry traffic, but letting Firefox/FoxyProxy to access the internet), vlmcsd, transmission, ffmpeg (for storing video surveillance data), nextcloud and many other software on my router.

BTRFS-backed snapshots (both for base system and for LXC containers) provide an ability for instant rollback if router is misconfigured or something else (e.g. software update) goes wrong.

Both my Omnias were upgraded with LTE cards for backup connectivity (Quectel EC25-E and Quectel EP06-E). One Omnia has 1Tb mSATA SSD installed instead of stock 5 GHz WiFi card. Another Omnia has two 8Tb USB HDDs attached via external USB 3.0 hub.

Initially there were some WiFi signal quality issues which I solved by wrapping both WiFi cards in an aluminium foil: https://forum.turris.cz/t/wlan-5g-not-starting-most-of-the-t...

Omnia is a kind of hardware which puts user in control (which is an extremely rare quality in the modern world).

Aren't you worried about increasing the attack surface a lot for a machine directly accessible on the Internet?

I'm neither a network nor a security expert, but I would have thought that the router would be better running the minimum essential software only, and that the rest of that stuff would be better on other machine(s) on my local network. Especially since you have a VPN set up.

I run most of this software in LXC containers, which are exposed on the LAN side of the router only (and have separate IP address). If it's necessary to expose some service on the WAN side, then I must configure a WAN-to-LAN port forwarding. It's like running stuff on the Raspberry Pi, but CPU is faster, and there's no actual physical Raspberry Pi involved.

Can you share the SSD model and it's dimensions that you are using with Omnia? I am trying to find one that actually can fit and have enough capacity for mine.

https://www.aliexpress.com/item/1005001682074987.html

Note that this device is currently using a 32-bit ARM processor, so it will likely be affected by the Y2038 issue, unless OpenWRT and other distros end up fixing that issue. In addition support for 32-bit in general and 32-bit ARM in particular in the Linux distro space is waning, for example Fedora is talking about retiring ARMv7 support. Presumably OpenWRT and TurrisOS will retain support for as long as possible though. Other Turris devices (MOX etc) use newer 64-bit processors and aren't affected by those issues.

https://fedoraproject.org/wiki/Changes/RetireARMv7

What does the used architecture have to do with the Y2038 issue? You can use 64 bit integers in a 32-bit system you know..

Most 32-bit architectures are affected by Y2038, because they use 32-bit time_t, which is part of the ABI for an architecture. So if you want 64-bit time_t, you need to either have a new ABI (and recompile the world against it), or introduce new functions using the 64-bit time_t (similar to the transition to 64-bit file sizes).

or use openbsd which made the transition to a 64-bit time_t for all architectures.

https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2

in 2013...

That's just a software issue. OpenBSD has been using 64-bit time_t on all their architectures for almost a decade now:

https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2

It's worth noting that this was possible because OpenBSD are happy to break their ABI in order to improve their operating system. Linux values ABI stability highly, and prefers to introduce new interfaces that applications have to opt into (e.g., as was done with support for 64-bit file offsets on 32-bit architectures).

Linux 5.6+ made time_t 64 bit in kernelspace. musl 1.2+ and glibc 2.32+ made it 64 bit in userspace as well.

I think you mean glibc 2.34: https://sourceware.org/pipermail/libc-alpha/2021-August/1297...

You opt-in by building with -D_TIME_BITS=64: https://www.gnu.org/software/libc/manual/html_node/Feature-T...

An approach not without its problems: https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-co... - but then again software that relies on time_t being 32 bits has been broken on 64-bit architectures for a very long time already, surely?

I suppose I could have written that "GNU/Linux values ABI stability" in my comment, instead of plain "Linux"... ;)

Ah yes you're right, I was going by the Linux 5.6 release notes, which gave 2.32 as version. I personally fully expect TIME_BITS to default to 64 soon, but looking at the 2.35 fixed bugs, they were right in not immediately switching it over. I see at least 2 bugs related to it.

Yes which is why GP said at the top-level comment you initially replied to:

> unless OpenWRT and other distros end up fixing that issue.

OpenWRT uses musl which has 64 bit time_t.

It also compiles the whole system to a single image, so you don’t have the problem with ABI incompatibilities because you typically don’t run random third party binaries.

TurrisOS (OpenWRT based) is more like a normal Linux distro, it uses BTRFS, you can install packages with opkg, even run other distros with LXC.

Dev OpenWRT appears to have already updated to a recent musl which supports time64 syscalls, so it will work fine. https://forum.openwrt.org/t/error-with-libc-so-gettimeofday-...

That Fedora page doesn't mention anything about time?

Fedora is talking about dropping support for all 32-bit ARM CPUs (ARMv7), so it won't run on the Turris Omnia after that. Nothing to do with time_t or Y2038, but I guess that factors into it.

Fedora and OpenWRT have very different use cases

Fedora is a general distro, suitable for all use-cases. For example the Fedora IoT spin has a similar use-case to OpenWRT.

Does Fedora IoT fit into 16 MiB Flash?

In 16 years, will the hardware still be working anyways? That's longer than any other network device I've ever used has lived.

Yes. Sixteen years is not a long time at all. My full time laptop is from 2008, for instance, and I have hardware which has run continuously since the '90s that are still running perfectly fine.

I suspect in 16 years the internal flash will have worn out. I'm not sure the device can boot from external storage but if it does it might still be a decent router then.

Why would it write to internal flash at all? The flash on my OpenWRT router is mounted read-only.

This is TurrisOS, not vanilla OpenWRT. Root is a read-write btrfs volume. You can install packages, you can change whatever you want. You can even run containers on it, although it's highly discouraged precisely to prevent it from wearing out too soon.

In any case, on vanilla OpenWRT the overlay is rw and also gets written to the flash. It sees a lot less activity than on TurrisOS but it exists, otherwise it couldn't persist your config between reboots.

You can plugin new storage to the internal mSATA slot if needed.

15 years of life for a home router is pretty good anyway, no?

There's always BSD for when (mostly commercial) Linux distros decide to end support for perfectly good, modern hardware, and the BSDs already started using 64 bit time on 32 bit architectures ages ago.

Do you really think somebody will still use that at the time? Are you using anything that old now? I mean networked electronic gadgetery, not kitchen appliances.

For a long time, I needed an access point + VPN client, and I've considered the Turris Omnia.

Ultimately though, for this type of job, any SBC with Linux does this job (and more); the differences were:

- USB wifi cards are unstable and unsuited as access points, so for stable connection, SBCs require a separate access point

- one must configure Linux manually, while the Omnia is ready out of the box (but it's relatively easy to configure Linux)

- for the price of the Omnia, one gets a more powerful (and more flexible) SBC

I think generic SBCs can comfortably cover a number of Omnia use cases (and do more). On the other hand, ease of use is obviously a winner for Omnia, were required.

The Turris Mox is also quite interesting. Of course any SBC will do and it's probably harder to run a non-Turris OS on the Mox than on an EspressoBin that has a similar SoC; the advantage however is the very extensible hardware architecture. It has optional PoE support and up to 1G of RAM, and you can also add any mix of extra USB3 ports, network ports, mini-PCIe slots etc.

> USB wifi cards are unstable and unsuited as access points, so for stable connection, SBCs require a separate access point

Luckily there are popping up various sbcs with pcie these days, so you potentially could get more stable setup with those.

We use routers from the FriendlyElec/FriendlyARM NanoPi range - they're pretty much the same deal: custom firmware built on top of OpenWRT. The advantage with the NanoPis is they're tiny, and cheap enough to be almost disposable. When we're building test/measurement hardware, we throw in a NanoPi configured with a phone-home VPN. If the hardware runs into issues or needs modified, the user can just plug in an Ethernet cable and we can get remote access.

The only downside of these is that we've experienced reliability issues with one particular model of the NanoPi, which I suspect might be down to bad solder joints. The Omnia looks a lot more solidly built.

For lower cost and more powerful state-of-the-art open source router please check Banana Pi project [1].

The latest Banana Pi BPI-R3 Router board is running a new MediaTek SoC MT7986 with 2G RAM, 8G eMMC flash, x2 SFP (2.5 GbE), 5 GbE network ports and WiFi 6E [2],[3].

[1]https://wiki.banana-pi.org/Main_Page

[2]https://www.androidpimp.com/embedded/banana-pi-bpi-r3-router...

[3]https://news.ycombinator.com/item?id=30085303

What's really lacking on the open source side is modern hardware, not another box of limited hardware running Open-WRT for $400. E.g. this device is limited to 3 gigabits of switching performance and 3x3 AC Wave 1. Wireless in particular always seems to always be a pain point, there just aren't ever good options.

Please check Banana Pi as in my other comment. The latest R3 version also supports WiFi 6E and price is probably half of the Turris Omnia, around USD$200 or less.

R3 looks interesting but not out yet, main concern is the newer MediaTech Wi-Fi adapters have been having a litany of issues and that's not even in AP mode. I've been chasing one with a client card having horrendous intermittent delays all the way up to kernel 5.16.

If the R3 releases and solid support actually arrives on these adapters it could be VERY interesting.

WHat would be the best gear to extend the wifi range Iif I ever buy a Turris Omnia? Big house, lots of concrete walls.

The best thing to do is to run cables to different rooms and add access points there. I've done that using cheap Gl.iNet devices that I've flashed vanilla OpenWRT and just run them as dumb-ish APs with VLAN support.

If you're unable to run cables, a mesh WiFi solution might be your best bet.

Currently I have a couple of Asus AC1900 that support both (Mesh via wifi only or cable), connected by cable. I'm not that satisfied with them, a few hiccups from time to time and I keep them basically because I got them for free. But this Omnia looks indeed interesting. The drawback of multiple APs is that you have to do multiple, identical configurations for the SSIDs on each one of them.

You do. The good part is that WiFi roaming via 802.11r on OpenWRT is a breeze to configure and has been working flawlessly for me.

While Turris does seem like solid devices by great people, depending on your needs it can also be worthwhile to consider PCEngines APU (pcengines.ch).

Availability has been scarce since the Intel NIC shortage started but they can still be snagged from time to time.

Up until now, I thought OpenWRT and OPNSense were the only robust options out there. Glad to know about this featureful open source router.

Well, this one is built on top of OpenWRT. I guess it depends whether what they've built has added enough utility to be considered different from it?

I own a Turris Omnia. It's been my main router for over 2 years.

I don't use a lot of the stuff they've added on top of vanilla OpenWRT, but there are a few things that make me want to stay and probably buy the next hardware revision when it comes around:

  - The hardware support is great
  - The ability to add M.2 SSD for running LXC containers and generally saving data (logs, etc) without worrying about wearing out the internal flash
  - BTRFS snapshots with a handy CLI to manage them, rollback, etc (also on the web UI if that's your thing)
  - Automatic upgrades
  - Automatic snapshotting before and after upgrades, which is great if an upgrade bricks it. Hasn't happened to me even once but it's good to know it's there.
  - Hardware button can be used to restore latest snapshot or factory
  - When restoring previous snapshot doesn't cut it, restoring factory keeps snapshots around so you can easily get back to your previous configs and fix forward
  - Declarative package management
  - Full access to pretty much everything OpenWRT has to offer anyway - caveat that if you customise certain things you can't use the "official" web UI (reForis) for those. My network config is managed exclusively over LuCI, uci, config files, for instance.
  - Open, hackable hardware

Edit: formatting

Hm, I really like all the snapshotting features! And the M.2 slot and hackable hardware are definitely a plus.

Hmm, I din't think the Omnia had an M.2 slot, I guess you are talking about then next hardware revision. It isn't clear there will be one, considering there is Turris MOX now.

Huh, you're right. It's been a while since I added mine but it's indeed not an M.2, it's an mSATA. Thanks for the correction.

Reply on news.ycombinator.com