Hi, new Omnia operator here, this is mostly an initial feedback post, but you’ll find some TODOs there as I’m migrating off another OpenWRT router and there’s some stuff that isn’t back in place yet.
I ended up getting one from linitx.com so I wouldn’t have to worry about customs. Having some time with it before I got full fibre come in was useful. First thing I saw was that the router was already configured somehow, with DHCP serving 192.168.11.0/24, unknown password on (re?)foris no password on luci and the LUCI password setting page would fail with an unknown error, might be something LinITX did, so I did a settings reset. That moved the router to serving 192.168.1.0/24 and it wouldn’t finish setting up with its WAN port connected to a 192.168.1.0/24 network. I assume the routing set up just can’t handle that situation, might be a bug but then it’s not exactly something you’d see in practice. So at this point I had to wait until fibre went live and cross my fingers that it Just Works ™.
Fast forward to connection day, October 19th (reading the forum, it seems that day turned out to be special in other ways, oh well), I set things up, auto-updater kicked in and bricked LUCI (lib<name I forgot already>.so not loading) and no Wifi cards recognised. Reboot failed, and factory reset ended up in an endless loop, so I downloaded the medkit and run that, which worked nicely. At this point I’d like to give a massive thumbs up for the documentation, while it might need updating a little (LED behaviour for the reset process didn’t match) but was otherwise spot on. Now I had a working router with nice wifi coverage 
Fast forward to configuration:
- some clients didn’t have their wpa_supplicant configured to accept WPA3, so they would try and hop between APs and fail on the Omnia, was quite trivial to fix once I knew where to look
- it ships OpenSSH’s sshd, but this isn’t really communicated so figuring out that you can just ssh-copy-id your keys rather than go through LUCI needed a stab in the dark (well, and a little
ssh -vfirst
) - setting up Knot to forward
consul.to consul servers[0] took me a whole evening when it’s usually a five minute job with dnsmasq - TODO: keeping with Knot, turris.lan resolves to a random member of the network and I can’t see why or how to fix it
- TODO: I’m still confused about the LEDs, especially as any change/reboot will reset LED brightness to where it’s capable of illuminating the whole room (when you’re asked to give this device a break and watch a movie for a bit instead)
- TODO: I’d like wireguard configuration to be considered first class functionality, something that could be done in reforis, I’ll see how the interfaces are set up and replicate my old one eventually, a TODO for this week I guess
- TODO: still not sure UPNP is working either
- TODO: I’m back to running mosquitto on a separate node (thanks consul for making this seamless) until I get to configure it again
Overall the experience has been positive, but it’s clear you’re still expected to be mildly savvy to get some things working. OTOH having the reset button magic and the medkit in place is a lifesaver! If I could have just one request, please document and test some of the above (DNS/wireguard) better.
Thanks for sticking with this overlong post and getting all the way here, if you have any hints as how to handle the TODOs above easily, that would also be appreciated.
[0]. Supposedly fixed as mentioned by DNS (kresd): Delegating a sub-domain of .lan to an external resolver but for me, I still had to go the policy.rules = {}; ppolicy.add(); for _, v in ipairs(rules_copy) do table.insert(policy.rules, v) route, else it wouldn’t do anything for me