Way to have turris.omnia run like stock LEDE?

  1. yes. it does, and it is. if you wanted a router just like every other commodity router, you shouldn’t have bought an omnia.

  2. why? what is it you think you’re going to gain? the omnia is powerful enough to handle all the “background” tasks and still route your data. shutting extra services down isn’t going to suddenly double your throughput.

  3. that’s certainly your prerogative, but what do you think you’ll gain by doing so? the omnia was built to support openwrt from the ground up, not have it shoehorned in and not as well supported by a company that would much rather you run their crippled stock firmware.

the omnia is a powerful home/soho router for power users who know and understand what they want in a home router product (but don’t feel like shelling out the money for a cisco/juniper/etc). it isn’t some cheap linksys/netgear/belkin junk.

Hi, I would like to give my view on why I want LEDE.

I want newer software versions for kernel & packages.
For example we cannot use BBR TCP due to low kernel version.

Also, I would like to have the ability to compile my own LEDE so I can try patches, for example, sch_cake algorithm.
Turris should have been only a package addon for OpenWRT/LEDE.

Thus, you wouldn’t need to focus on kernel or other packages but only on your own software / hardware.
If irrelevant packages caused problems on Turris OS, you could step in and help LEDE per case.

1 Like

Old software is some what currently problem as during OpenWRT vs Lede charade we waited and tracked OpenWRT. Lede was rapidly developing at the time and because that is what should be Openwrt now it’s problematic now to merge Lede to our tree. That takes time and we are some what working on it in next branch.

There is nothing holding you from patching Turris OS tree. You can compile it almost the same way as Lede. And if you think that you created something good you can send us patches. (https://www.turris.cz/doc/en/howto/turris_os_build)

Turris can’t be just package addon as Lede/OpenWRT has different release cycle and different release method.

We would like to be able to focus only on important things, but as Lede/OpenWRT developers don’t care too much about long term updates we have to do that work instead of them.

I am not able to patch turris Os to bring it up to speed with LEDE…
But if you contributed patches to lede/openwrt so it can support omnia, everyone would be happy.

Those who wish to follow turris os are free to follow, those who want more up to date packages with a risk are free to follow LEDE. :slight_smile:

Sorry but we are currently spread thin as it is. It’s most improbable that we will have time to send any support patches to Lede. And although we would benefit from some changes being in Lede, most of our changes couldn’t ever made it to Lede as it is against of its policy. Most notably we care less about size and more about features so every our package is more or less not optimized for small routers. Turris is just more powerful platform and we cope with different problems than Lede does. We have common base, same goals, but different rules that we apply.

1 Like

First of all I want to thank all of you for your replies so far…good to see the folks I share common hardware with stepping in to lend support and insight…

& To put it briefly, I find that the turris omnia is routing my traffic/packets in ways that induce extra unwanted latency.(have not encountered this issue on other routers). not sure if it has to do with the Omnia’s resolver/ unbound/kresd/dnsmasq or txqueuelen? or something else… Latency/connection stability has been my main issue on the T.Omnia, and Currently still persists.

Just as a note, the omnia’s TCP congestion algorithm will only affect connections that actually terminate on the omnia, so it will not help computers on the internal network. And BBR will only work as advertised n combination with the sch_fq qdisc, so make sure to always configure the correct combination if you want to get BBR working as intended.

https://forum.turris.cz/t/how-to-use-the-cake-queue-management-system-on-the-turris-omnia/3103/1
has instructions on getting sch_cake working on the omnia without needing lede.

I am not sure whether your intuition about how to offer a relatively stable distribution to customers is quite correct. I can fully understand that turris developers want to update things at their own pace, LEDE for all its beauty (and I am using it on my main router) has been a wild ride with massive behavioral changes that have not been communicated to users in a prominent enough fashion for making it the basis of a semi-commercial" disytribution like turris, IMHO.

That said, it certainly would/will be nice to use the omnia hardware to run stock LEDE for more adventurous types, but I am not sure whether asking the developers that have their hands full making the current turrisOS stable to do the upstreaming/integration work is really that productive or friendly…

Best Regards

  • i simply want my Omnia to route my traffic as “fast as possible” and somewhere along the line from the modem to the t.omnia the packets/data seem to get “hung up” and reach their destination slower than usual.

  • On stock firmware (turris OS 3.2) ive seen it process packets a little faster than these consumer routers such as r7000,r8000,ac1900.(makes a Big difference in the applications i use) also on stock firmware and up i seem to encounter packets being dropped every few minutes. then after updating out of turris OS 3.2 i haven’t seen the router process the packets as quickly as something in the software/firmware may have been changed. last week i reset to factory firmware to test it again and found 3.2 to be more “snappier” when processing data/packets like i mentioned above.

  • Fortunately* after update 3.7 i have not encountered packets being dropped just YET (after a 24hrs of use) for whatever reason, although the latency still persists.(the extra latency i reference has nothing to do with my network/modem/tap, as these latency issues are only when omnia is used as router)

BTW, have you performed the “mtr on the omnia” and the disable WIFI tests yet? And have you considered that maybe your omnia has flaky hardware? I bring this up as other user do not seem to be able to replicate your observations and that often is an indicator of physical damage?

Best Regards

what about my LXC image? I want to use there BBR. Not in the whole router.
I have already installed cake but I would like to play with latest cake.

Providing hw patches in LEDE would have helped both projects in long term…

Well if traffic terminates in a container, sure BBR might be useful, but again, make sure to use sch_fq other wise BBR is not complete…

What do you expect from the latest cake? It is not that LEDE currently distributes the develeopmental cobalt branch, so you would need to build things yourself, but I assume you could also build a turrisOS version with a patched in cake… (or if you can install gcc and git on the omnia you couls simply compile your own local module).

Might be true, I sympathize, but at least the developers of one project told us politely that they unfortunately lack the required time ATM. My understanding of the turris developers position is not a firm “never” but really more of a it would be nice if we would find time…

Best Regards

are you serious? before i supported you via indiegogo, i asked in the comment section and i only bought the device because someone on your team answered, that there will be upstream hardware support for the device.
also, i really thought that guys from CZ.NIC would support upstream…

my device is sitting here, offline, waiting for LEDE/OpenWrt support :frowning:

we maybe wanted to use it for Free Wifi Mesh networks like Freifunk, which use their own firmware based on LEDE/OpenWrt - so here you have the use case that you can’t silence with “Turris OS is just better”

1 Like

Please see the whole picture in this topic. I wasn’t saying that we will never be sending any patches to upstream. I stated that mainstream support would be beneficial for us too. But also that before we are able to do anything about it we have to catch up lede first with Turris OS. Please understand that we shipped 8 thousands routers with Turris OS so that is our primary concern. It’s clear now that Lede is the future but wasn’t a year ago and division in OpenWRT community wasn’t helping us much. So please read my whole post. In digest, currently we have to catch Lede with Turris OS and until that is done we are spread so thin that we just can’t work on it. That doesn’t mean that we won’t ever do it. It’s just that it won’t be tomorrow. And as we are open source, help from community is always welcome. But barking on the tree won’t make it grow faster.

4 Likes

What I don’t get, is if LEDE support is absolutely needed right now by someone, why don’t you buy a router that has LEDE support right now? Anyone who buys a product based on what you might be able to do with it in the future is being foolish, there are no guarantees in life.

Complaining about features that weren’t already present is just foolish. They’ve been promising flying cars for decades, I don’t whine about my current vehicle not being able to fly because it can’t.

1 Like

ok, looking forward - but it seems “the community” has it almost working already, missing RGB LEDs, SFP support and working sysupgrade only, as far as i understand it.
so maybe you don’t have to contribute this upstream anymore.

and would even be cool to run dd-wrt on it :slight_smile:

no it won’t be - dd-wrt is quite hard to compile and not a community controlled project :stuck_out_tongue:

Why? There are already plenty of commodity routers available that can easily run dd-wrt. Why not just use one of those?