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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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].
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.
51 comments
[ 2.8 ms ] story [ 104 ms ] threadhttps://fedoraproject.org/wiki/Changes/RetireARMv7
https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2
in 2013...
https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2
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"... ;)
> unless OpenWRT and other distros end up fixing that issue.
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.
That Fedora page doesn't mention anything about time?
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.
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.
Luckily there are popping up various sbcs with pcie these days, so you potentially could get more stable setup with those.
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).
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.
Availability has been scarce since the Intel NIC shortage started but they can still be snagged from time to time.
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:
Edit: formattingIf you're unable to run cables, a mesh WiFi solution might be your best bet.
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.
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
If the R3 releases and solid support actually arrives on these adapters it could be VERY interesting.