Feedback about Turris OS 3.x/4.x release

The 3.x branch is the only one that allows you to take full advantage of the Turris Omnia hardware. I hope it will be supported much longer. At least until the branch 4.x, 5.x, x.x.x has the same functions and the same support. Now the 4.x branch, although stable as a system, is totally limited. It is limited in all those functions for which you buy an Omnia: support limited to SFP due to OpenWRT kernel (cursed), data collection that works by executing commands from the command line (maybe) and then where is the simplicity of Foris or reForis? And Honeypot? Those are the things you choose Turris for. It’s okay that those functions are all to finish, complete, revise. This is not a criticism. It is a wish and I hope that the future versions of the Turris OS may be worthy of the name. I understand the desire to join the OpenWRT project, I understand the changes deriving from over a five years of development, but you also understand the frustration of a simple user, who despite everything exists. I would have left the 4.x version in a long beta phase. I make you my warmest good luck.
Google Photos
It’s nice thanks to OS 3.11.x

4 Likes

I started to consider to upgrade from 3.x to 4.x due to some annoying bugs in 3.x, but looks like it’s better to stay with it for now. Could you describe what doesn’t work with SFP in 4.x?

Thanks for the post!

Hi, I wrote this post of course as an outlet. But not against the work of the Turris team or for the project in itself, but for the project in my opinion. In fact, if I understood correctly, their story starts with the idea of ​​improving the network situation to the domestic level, which is the crux of global network security due to several factors: not all users are hackers; not all producers are attentive to the product, but almost always exclusively to profit; there is little perception and awareness of the immense flaws of a network that was born without having the idea of ​​a threat in the head. Thus was born the Turris project, which is a way to combine a product that can be used by the average user, which can contribute to a direct or indirect joint research (through the data collection, honeypot, the collaborative firewall and finally the recent Ludus project, always addressed to the 3.x version of Turris OS). Everything is realized through an open source hardware, which with the MOX acquires a modularity character and an open software, whose main limitation is to always be a little behind the base that it uses and that is OpenWRT. That said, the Turris product model buyer is a conscious person, even if not a hacker, who may want to contribute to research in the field of network security, which wants a product that is customizable and more efficient by others on the market combined with the simplicity of use and automatic updates, which is one of the fundamental advantages on OpenWRT, which is all manual. At least that’s what is sponsored and touted. And I could agree until the 3.x branch of Turris OS production. In fact, not wanting to go into the matter of the hardware issue, I can say that in the end, that is, coming to the user, Turris OS 4.x is a nice leap back from previous versions. In fact, although based on more modern kernels, although with a more current structure (it is based on OpenWRT 18.06.x, which comes at the end of its life, with the imminent release of version 19.x), it lacks all those things that make the Turris (which is MOX or Omnia, which should then be the spearhead, the complete all-in-one product) the Apple opensource of routers, a product that combines a discrete hardware power (it is no longer discreet) to an excellent software that knows how to exploit every little aspect.
Considering that all data collection and firewall projects are experimental and not supported by guides in my opinion exhaustive or by graphic interfaces (due to total lack or adequacy) and the SFP part being abandoned in half, disappointment and frustration are born. Everything that was true until version 3.x is now lost. And I don’t know what the direction is, since now OS 4.x is the stable branch (here be snails) and MOX and the latest revision of Omnia (like mine, the metal one) are provided with OS 4.x from birth . Ultimately the overall product (bad luck wants it right now that I purchased it) is something lacking, missing, uncertain, as well as for any path of change. But since in the end I am the user and not the team, I don’t know how beneficial it is to stay suspended in something that we decide and we always accept.
Fortunately on Omnia you can also go back to the 3.x branch and have pretty much everything you buy a Turris for (sin for MOX, which only supports 4.x). SFP does not work on 4.x, because it is incompatible with the mainstream linux kernel driver. There will be no intervention by the team, but each user will be able to provide as best he can (this is what I understood from GitLab), but I don’t feel like spending money on something I don’t know if it will work or not, may or may not be compatible . As for advertising there is capacity, but then in fact they make me understand that everything is questionable, the guarantees are zero almost on everything. I was given the example of a usb device that could be incompatible and therefore also the USB ports would be a resource in half. But with SFP it is different, because often, as in my case, the module is provided by an operator and it is not possible to replace it.
To sum it all up, for now I would not recommend a product of this kind. At least until things continue like this and there is no strong intervention on OpenWRT as in the past to allow maximum benefit from the hardware. I was a happy user of Linksys WRT3200ACM, which is a first class citizen of OpenWRT (except that it expired due to the lack of interest of Linksys / Belkin, which did not force Marvell to release the wifi card driver code), still today however widely usable and with bandwidth performance, even higher than it has ever been able to achieve with Omnia.
Since I am still forced to use a transceiver to use my SFP fiber connection, I will aim at another fully supported product, which is already born without SFP cage and which immediately leaves the user to his own skills, but also promises excellent performance.

1 Like

I think that even 3.x is a disaster: it isn’t stable nor usable by non-hackers. If not for SFP and direct fiber connection, I’d through it away.

Currently I have following issues with 3.11.9:

  • it’s running out of disk (/tmp/log) every ~20 days.
  • it doesn’t respond to IPv4 DHCP DISCOVERY requests for some devices
  • it can’t correctly close SSL connections (kill socat), so the app isn’t usable as router runs out of file handlers.

I tried to update to v4.0.1 due to Reboot loop after upgrade to 3.11.9 and other bugs and SFP didn’t work for me too.
So I’ve rolled back to 3.11.8.

Yes, now the only thing that works is 3.11.8. I read about the bootloop caused by 3.11.9. I made connection sfp -> transceiver -> wan and installed 4.0.1. Because from what I understand the SFP modules that are not compatible will never work again in future versions of Turris OS and I can’t stay tied to 3.11.8, although OS 4 is still strongly lacking in many features.

1 Like

If SFP won’t be supported in 4.x then it’s time to find better router. I’m not going to stack transceivers on top of a router.

I heard that MikroTik are quite good, probably something like CRS106-1C-5S or CRS112-8P-4S-IN should cover my needs and should be future prof enough for next 10 years. Any suggestions?

It really depends on what you have to do with it. Those Mikrotik look to me like switches while Omnia is a router. I do not know.
If you are looking for an excellent all-in-one router/firewall, modular and open this is what I think offers the best market to date. It costs less than Omnia and provides hardware that really supports Gigabit. That is AMD 64-bit multi-core processors and several Gigabytes of RAM. There is plenty of choice. 100% OpenWRT compatible.

My minimum requirements: 2 SFP, 4 eth, border router and firewall, DHCP + DNS server, full IPv6 support and being able to route 1Gbit/s including through NAT for IPv4. I guess it’s better to have separate WiFi devices, but I haven’t thought that through.
Also I want something reliable, I already spent way too much time on debugging Omnia.

Looks like TekLager has no SFP, so won’t work for me.

What? You have just one uncompatible SFP module, which was working, now it isn’t and you are saying aloud - It doesn’t work at all and you just push away others that it doesn’t work and we don’t care. Which is not true. Please don’t spread misunderstanding or things, which are not true. Otherwise I’m going to close this thread.

My colleague already told you everything:


and also we had an discussion with you on our Gitlab, where we tried to help you as much as we can.

SFP on Turris Omnia works and I was testing it personally and there are tests in the factory for that.
If you have black Turris Omnia all you need is to switch DTS to use SFP (which is compatible) as it doesn’t work automatically. It was said in the same thread and if you have a silver case, there is automatic switch between SFP and metalic.

Poškozování, obviňování, nedorozumění, pravda, argumenty, zavírání vlákna. To jsme to dopracovali.

Harm, blame, misunderstanding, true, argument, close thread. That’s what we’ve done.

I never said that SFP will never work on Omnia again. I said those modules that are incompatible on 4.x will still not be compatible.
Who buys should know that there is no guarantee on the operation. What works does, what does not work does not. Maybe one day it will start working again or it will stop. There’s nothing wrong. I think the sponsorship form is wrong, because it seems that all the sponsored things really and surely work. And I don’t give a damn about my broken SFP module.
I would also have other things to say and not shout. Honeypot mini-honeypot data collection bootloop on 3.11.9 etc etc.

1 Like

Is there a list of compatible modules? Considering using a direct connect link to a small managed switch sitting before the router.

I am sure and I hope that the same attention paid to responding promptly to everything that is said to be the same in the work on hardware and software. I wrote to the assistance and was only answered 3 weeks later and I’m one of the lucky ones. On the forum I read that it gets worse. Then Omnia seems a little forgotten, because now there is MOX, which seems to me a weakened version of Omnia and eventually even more expensive, because wanting to have everything that Omnia has, the price is significantly greater. I’m sure the team won’t be offended, I’m sure the team knows I can’t distract or encourage anyone. If a project is valid it will continue, otherwise it will end. Fortunately, a user’s experience cannot change things.

Pepe,

are there any doc how to enable SFP on 4.0+? I tried to upgrade my Omnia to 4.0 and SFP stopped working, so I downgraded back to 3. From my point of view as a client, if my SFP module was working with v3, it should continue working on v4. If I need to do some specific configuration for that, it’s fine, but the guide should be near upgrade doc.

I’m using very common TP-LINK TL-SM321B 1000Base-BX WDM Bi-Directional, which one do you use for the tests? Are there a list of supported ones?

Thanks!

It is not mentioned in the documentation but in the forums, from the ssh cli (cannot be done via Foris or LuCI)

ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot

Thanks!
I’ll try that over weekend.

However it does not mean that it works, because in my case passing from 3.x to 4.x also activating the SFP port, however I cannot use my module, but I had to bypass it with a transceiver. Due to changes in the driver that manages the port, if I understand correctly. So I, as a customer, was expecting it to work, but the expectation is not expected.

Which module due you have?

I think it would be a good idea to put list of SFP modules somewhere and mark which one work and which one doesn’t.

1 Like

Mine is provided by the operator and has a MAC address that serves as an authorization in the ISP’s VLAN. Replacing it would require reprogramming and is too expensive. Mine is from the TIM fiber.