OpenWrt 21.02 RC1 is in HBD branch

Dear Turris users,

We have been lately working on polishing things for the upcoming OpenWrt 21.02 RC1 as there was a branch off two months ago and OpenWrt finally brings an announcement that this version is out for a broader audience a few hours ago! This version is already available for testing in the HBD (D for Dangerous Dragons :fire: :dragon:) branch.

OpenWrt 21.02 RC1 – future Turris OS 6.0

The latest highlight of this release is that OpenWrt 21.02 will have thanks to @japa available to install RIPE Atlas SW Probe, so it means that anyone who has any router running OpenWrt, he/she can install it and use it! Unfortunately, it does not make it into RC1, but it will be part of RC2!

Main highlights for us are LTS Linux kernel 5.4 and Python 3.9.


:white_check_mark: Tested: Turris Omnia, Turris MOX (on the picture)
:x: Not tested: Turris 1.x (missing some packages will be hopefully fixed soon)

If you are interested to try this future release, don’t forget that isis a development branch and recommended to use by advanced users only. For more details about switching branches take a look at our docs.


OpenWrt 21.02 RC1 release notes:

Initial DSA support

  • OpenWrt in this release replaces swconfig by DSA and if you have some router, which runs OpenWrt and there is available sysupgrade, it won’t migrate your configuration about switch ports and VLANs.:warning: It means you will be forced to configure your router from scratch
    (Does not apply for us as we are using DSA already and we don’t have sysupgrade)

  • LuCI support is not there, yet.

WPA3 support included by default

Turris note: We will have support for this in reForis very soon!

ASLR activated

Address Space Layout Randomization (ASLR) support should make it harder to exploit OpenWrt for attackers.

Turris note: We have it enabled since Turris OS 5.0.

Packages updates

  • Updated toolchain:
    • musl libc 1.1.24
    • glibc 2.33
    • gcc 8.4.0
    • binutils 2.35.1
  • Updated Linux kernel
    • 5.4.111 for all targets
  • Network userland:
    • hostapd 2020-06-08, dnsmasq 2.84, dropbear 2020.81
  • System userland:
    • busybox 1.33.0

Increased min. HW specs

  • At least 8 MB of flash
  • At least 64 MB of RAM

Taken from official announcement.


Nice… is the 5.4 kernel bringing efficiency improvements? On Intel architectures this was the case but not sure about ARM platforms.

Well, a newer kernel is not always about bringing a better performance which results in efficiency improvements. However, it is a huge step going from kernel LTS 4.14 to 5.4, so there is and security matters as well. For example, if we would be speaking about fixing DSA roaming fix, then enabled HW buffer management for Turris Omnia by default, and so on!

Generally speaking, there are new drivers, including DVB tuners, fixes, and polished current ones, then new stuff like upstreamed Turris MOX like there is .dts, etc.

Even right now, we have some branch where we have OpenWrt daily snapshots with enabled testing kernel LTS 5.10 and that’s going to be huge, because there is initial Turris Omnia support for LEDs in kernel thanks to our kernel developers!


Is there a reason why Btrfs compression (e.g. mount -t btrfs -o compress=zstd) is not set for the root partition, or for the default /srv partition? Compression level could also be tuned with kernel >= 5.1.

Yes good point. Btrfs has really improved with kernels 5.x.

It also brings in kernel with container support, and while TOS already has this for LXC containers, this will likely result in docker packages being made available to install.

docker natively (not running it inside lxc) maybe be possible soon.

1 Like

Thats some great news but I am a bit scared to switch to dragons yet! I think I will wait until it reaches HBK that I am using lets say in the production right now. But DSA port fix would be awesome to test straight away since I am longing for that fix to use different configuration. But anyway… Great news thanks for the info!
EDIT: I couldn’t resist:
root@ap:~# pkgupdate
INFO:Target Turris OS: 6.0
line not found
line not found
inconsistent: Package suricata-pakon requires package suricata-bin that is not available.
Will leave my AP on HBD branch and wait until its fixed. Will see how this DSA fix is working after it manages to update at some point.

Thank you for your question, @salty! I started to wonder why we are not using Btrfs compression, and I asked it in our team, and it seems that we can not use Btrfs compression for now as the old U-boot version does not support it. Hopefully, in the future we might enable it.

Yes, Suricata and as well pakon are not present in HBD. I need to admit that this is a little bit challenging, indeed. Because the current version of Suricata, which we ship in all versions of Turris OS, does not support Python 3 and we can not update it as a newer version of Suricata requires Rust, and this one is not present in OpenWrt. There is some pending attempt in pull request, but I’d say it has a long way to be merged. Not from us, though.

Of course, we can patch it, but right now, we have different issues, which requires our attention now.


I prefer Suricata and pakon over this DSA fix. I think I will switch back to HBK and wait.

There was a quiet radio silence about the HBD branch and upcoming OpenWrt 21.02. So, let’s change it. :wink: A few days ago, OpenWrt released another RC version. Changes can be found here:

Already in HBD. And I need to add that Pakon together with the Suricata are now present. :wink:


Any news on this development as RC4 is already available?
Has the DSA/ARP-bug been solved in the TOS v6 branche? I’d really love to use the full switch jack-capacity and retire my dedicated switch without reverting to TOS v3.x…

Any news on this development as RC4 is already available?

All RC versions of OpenWrt 21.02 were present in the HBD branch even w/o the announcement.
Right now, you can find in the HBD branch the latest RC4, which was compiled and briefly tested on Turris MOX and Turris Omnia.

You can try it, and you will see. :wink:


Stable is out!


Is there any rollout date already scheduled ?
How about support for Turris 1x ? Is it safe to try on Turris 1.0 ? Will it boot ?
Which image of medkit from HBD repositer is right TOS 6 ?
Is there support for [AsiaRF AW7915-NP1 / 802.11ax / WiFi6] in TOS 6 already included ?
How about debian LXC containers on TOS 6 will it work or not ?

1 Like

Agree that it would be nice to get an idea of the schedule HBL > HBK > HBT etc. Personally I would happily give it a go from HBK onwards… maybe HBL if I feel brave enough :slight_smile:

Is there any rollout date already scheduled ?

Only some internal dates. Nothing to share yet.
Right now, we will release Turris OS 5.2.7 and then, most likely Turris OS 5.3. There is no need to hurry. As I said in other threads here on the forum, we need to migrate users from Turris OS 3.x first because of changes done in OpenWrt 21.02.

How about support for Turris 1x ? Is it safe to try on Turris 1.0 ? Will it boot ?

You can try it, of course, but as said in the OP. It is still not tested.

Which image of medkit from HBD repositer is right TOS 6 ?

Well, HBD, right? But it will be downgraded to HBS during the Updater tab. So before reaching it, you need to do switch-branch hbd.

Is there support for [AsiaRF AW7915-NP1 / 802.11ax / WiFi6] in TOS 6 already included ?

Yes, this card is supported there, and the driver will be preinstalled.

How about debian LXC containers on TOS 6 will it work or not ?

Are you asking about Turris 1.x (powerpc platform) or Turris Omnia/Turris MOX (mvebu, arm)?
If you are asking about the later one, then why it should not work.