Easter vote when Turris OS 6.0 will be in HBK

This vote is just for easter fun and winner(s) obtain real good chocolate (personal handover during next Night with Turris event or similar further public Turris meeting in Prague).

  • 15.4. 2022 (Dangerous Friday)
  • 16.4 or 17.4. 2022 (Easter weekend)
  • 18.4. 2022 (Easter Day)
  • 19.4 - 22.4. 2022 (week after Easter)

0 voters

This topic is not intended to ridicule anyone or disparage someone’s work. If will be created section “Humor ”, please for moving this topic into them.

And now, we are waiting for winners!

I don’t want to disappoint anyone, but don’t expect that Turris OS 6.0 will be released on any proposed date in this vote. It is going to be delayed since we would like to try newer kernel LTS (even newer than 5.10) version to verify if DSA issues are resolved or not.


TOS 6 with kernel 5.10 is my dream same as TOS 5 with kernel 4.19.

Are these performance or functionality issues?

It does not make sense to bother anymore with 4.19. Why would you do that in the first place? Recently branched OpenWrt 22.03 has LTS versions 5.4 and 5.10. For all of our devices, there is being used kernel 5.10 and you can have kernel 5.10 if you want. It has been in the HBD branch for some time already.

Mostly functionality issues than performance one. Right now, we can not ensure that the migration from Turris OS 5.0 to Turris OS 6.0 will be smooth, and in some configurations, you most likely end up with no Internet access. What I have been told is that it would require to backport almost entirely DSA tree with recent fixes and improvements. That would be very demanding and time-consuming. That’s why we want to switch to kernel 5.15 for OpenWrt 21.02 in our distribution and see if it is better.


First, thanks a lot for that information

Is this related to more advanced configurations with (extensive) VLANs or does this also affect the bog standard default configuration? Just asking because I made the jump from TOS4 to TOS early and did not regret it, and am ready for switching to TOS6 now (but want to avoid my users complaining too much :wink: ).


And, it seems there is something in the DSA that does not like some IPv6 packets and drops them.

1 Like

Thanks for the information.

Good, that would probably not affect me :wink: (I try to be frugal with VLANs, otherwise it is far too easy for me to configure a contraption I am unable to understand).

That is likely a bigger issue, with quite a lot of my traffic using IPv6 already (and all seamlessly due to TOS/OpenWrt’s default competent IPv6 config and an ISP that uses full DualStack).

I almost broke my keyboard before I realized it wasn’t a problem in the office LAN, but in Omnia itself…

1 Like

Is this DSA issue specific to the TO’s hardware or to Turris OS?

1 Like

Yes i wanted to ask the same question. I can’t see any obvious issues on the OpenWRT forums, although they have released their 21.xx version a while ago…
[edit] actually there are some bug reports with packet loss on IPv6 but relating to specific cases with off-loading enabled (-j FLOWOFFLOAD in ip6tables)…

1 Like

Have you considered just skipping 21.02 altogether go for 22.03-based version much closer to OpenWRT 22.03 upstream release? How much work is migration to nftables (which I guess would be the most demanding change)? I have (so far uglily) modified sentinel-dynfw-client to sync with nftables set, is that something wort refining into a pull request?

1 Like

SOmething like this? Omnia + TOS 6.0 (HBL): Switch configuration broken (#336) · Issues · Turris / Turris OS / Turris Build · GitLab

On OG crowdfunded omnia with latest NOR fw etc., the switch is broken in the sense that all traffic from lan ports to cpu ports gets broadcasted to each other lan port as well. You will not notice that until you watch traffic or experience resulting performance issues - the packets (destined for a different MAC) just get dropped.

1 Like

It could also be this issue with the creation of multiple bridges, possibly related to missing VLANs. Based on the linked issues, it seems that this issue also exists with (some?) OpenWrt devices. It would be interesting whether/why that issue is more problematic with Turris devices.

1 Like

Interesting, thanks for pointers… I am keen to allocate some time to try and reproduce these issues on my MOX HBL. I have a homelab in preparation and proper network controls will be of paramount importance once I get that online… not feeling like reverting back to TOS5 either.

1 Like

If adding VLANs mitigates the issue I’d be much in favor of that workaround in order to get TOS 6 finally shipped. It’s soon to be eight months since OpenWrt 21.02 was released with lots of interesting updates.

1 Like

Is this related issue?

OpenWrt 22.03 was just recently tagged as its the first RC version, and there are still some things remaining for fw4 for nftables. No, it is not ready and pushing the development version to users who wants to be safe and they don’t want to have issues since they want to use the stable branch. No, that’s not an option. We could wait (if I remember correctly their last release took almost 1/2y to be released from RC versions), but we will need to prepare migration for nftables as you said, and that will take time even if they are some transition layers. But that’s not only this thing, but they are also other things which need to be taken care of. It is not simple as you might think. Still, it would not solve our migration network issues, which we have currently.


I think the proposal was not to push the current OpenWrt main branch to Turris users but to rather evaluate skipping 21.02 in favor of a 22.03-based TOS release close to the release date of 22.03.

Regarding the network issue itself, it would be of interest whether adding a VLAN could serve as a workaround in order to move forward (with whatever version).