8 ms·

Try Turris Omnia, the open source router

84 points by madspindel 5y ago

pabs3 5y ago
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 https://fedoraproject.org/wiki/Changes/RetireARMv7
- ginko 5y ago
  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..
  - pabs3 5y ago
    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).
    - pantalaimon 5y ago
      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.
      - pabs3 5y ago
        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.
    - somat 5y ago
      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 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 in 2013...
    - ginko 5y ago
      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 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2
      - yrro 5y ago
        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).
        Deukhoofd 5y ago
        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.
        yrro 5y ago
        I think you mean glibc 2.34: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html 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-Test-Macros.html#index-_005fTIME_005fBITS 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-compliant-by-default/ 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"... ;)
        Deukhoofd 5y ago
        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.
- mkj 5y ago
  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-time64-symbol-not-found/113211/5 https://forum.openwrt.org/t/error-with-libc-so-gettimeofday-... That Fedora page doesn't mention anything about time?
  - pabs3 5y ago
    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.
    - pantalaimon 5y ago
      Fedora and OpenWRT have very different use cases
      - pabs3 5y ago
        Fedora is a general distro, suitable for all use-cases. For example the Fedora IoT spin has a similar use-case to OpenWRT.
        pantalaimon 5y ago
        Does Fedora IoT fit into 16 MiB Flash?
- yjftsjthsd-h 5y ago
  In 16 years, will the hardware still be working anyways? That's longer than any other network device I've ever used has lived.
  - johnklos 5y ago
    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.
  - cassianoleal 5y ago
    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.
    - pantalaimon 5y ago
      Why would it write to internal flash at all? The flash on my OpenWRT router is mounted read-only.
      - cassianoleal 5y ago
        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.
    - pabs3 5y ago
      You can plugin new storage to the internal mSATA slot if needed.
- darkwater 5y ago
  15 years of life for a home router is pretty good anyway, no?
- johnklos 5y ago
  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.
- LargoLasskhyfv 5y 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.
pizza234 5y ago
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.
- bonzini 5y ago
  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.
- zokier 5y ago
  > 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.
deleted 5y ago
[deleted]
mkup 5y ago
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-time/1828/145 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).
- jaster 5y ago
  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.
  - mkup 5y ago
    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.
3np 5y ago
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.
1MachineElf 5y ago
Up until now, I thought OpenWRT and OPNSense were the only robust options out there. Glad to know about this featureful open source router.
- camtarn 5y ago
  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?
  - cassianoleal 5y ago
    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
    - camtarn 5y ago
      Hm, I really like all the snapshotting features! And the M.2 slot and hackable hardware are definitely a plus.
    - pabs3 5y ago
      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.
darkwater 5y ago
WHat would be the best gear to extend the wifi range Iif I ever buy a Turris Omnia? Big house, lots of concrete walls.
- cassianoleal 5y ago
  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.
  - darkwater 5y ago
    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.
    - cassianoleal 5y ago
      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.
camtarn 5y ago
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.
teleforce 5y ago
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 https://wiki.banana-pi.org/Main_Page [2]https://www.androidpimp.com/embedded/banana-pi-bpi-r3-router-board/ https://www.androidpimp.com/embedded/banana-pi-bpi-r3-router... [3]https://news.ycombinator.com/item?id=30085303 https://news.ycombinator.com/item?id=30085303
zamadatix 5y ago
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.
- teleforce 5y ago
  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.
  - zamadatix 5y ago
    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.

84 points by madspindel 5y ago

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 https://fedoraproject.org/wiki/Changes/RetireARMv7

ginko 5y ago
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..
- pabs3 5y ago
  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).
  - pantalaimon 5y ago
    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.
    - pabs3 5y ago
      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.
  - somat 5y ago
    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 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 in 2013...
  - ginko 5y ago
    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 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2
    - yrro 5y ago
      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).
      - Deukhoofd 5y ago
        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.
        yrro 5y ago
        I think you mean glibc 2.34: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html 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-Test-Macros.html#index-_005fTIME_005fBITS 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-compliant-by-default/ 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"... ;)
        Deukhoofd 5y ago
        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.
mkj 5y ago
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-time64-symbol-not-found/113211/5 https://forum.openwrt.org/t/error-with-libc-so-gettimeofday-... That Fedora page doesn't mention anything about time?
- pabs3 5y ago
  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.
  - pantalaimon 5y ago
    Fedora and OpenWRT have very different use cases
    - pabs3 5y ago
      Fedora is a general distro, suitable for all use-cases. For example the Fedora IoT spin has a similar use-case to OpenWRT.
      - pantalaimon 5y ago
        Does Fedora IoT fit into 16 MiB Flash?
yjftsjthsd-h 5y ago
In 16 years, will the hardware still be working anyways? That's longer than any other network device I've ever used has lived.
- johnklos 5y ago
  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.
- cassianoleal 5y ago
  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.
  - pantalaimon 5y ago
    Why would it write to internal flash at all? The flash on my OpenWRT router is mounted read-only.
    - cassianoleal 5y ago
      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.
  - pabs3 5y ago
    You can plugin new storage to the internal mSATA slot if needed.
darkwater 5y ago
15 years of life for a home router is pretty good anyway, no?
johnklos 5y ago
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.
LargoLasskhyfv 5y 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.

pizza234 5y ago

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.

bonzini 5y ago
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.
zokier 5y ago
> 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.

deleted 5y ago

[deleted]

mkup 5y ago

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-time/1828/145 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).

jaster 5y ago
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.
- mkup 5y ago
  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.

3np 5y ago

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.

1MachineElf 5y ago

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

camtarn 5y ago
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?
- cassianoleal 5y ago
  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
  - camtarn 5y ago
    Hm, I really like all the snapshotting features! And the M.2 slot and hackable hardware are definitely a plus.
  - pabs3 5y ago
    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.

darkwater 5y ago

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

cassianoleal 5y ago
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.
- darkwater 5y ago
  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.
  - cassianoleal 5y ago
    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.

camtarn 5y ago

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.

teleforce 5y ago

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 https://wiki.banana-pi.org/Main_Page [2]https://www.androidpimp.com/embedded/banana-pi-bpi-r3-router-board/ https://www.androidpimp.com/embedded/banana-pi-bpi-r3-router... [3]https://news.ycombinator.com/item?id=30085303 https://news.ycombinator.com/item?id=30085303

zamadatix 5y ago

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.

teleforce 5y ago
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.
- zamadatix 5y ago
  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.