Turris OS 5.1.9 is released!

Pepe · February 18, 2021, 9:09pm

Dear Turris users,

We are proud to inform you that we released Turris OS 5.1.9 to everyone! This release is based on the top of today’s released OpenWrt 19.07.7 with our patches and feeds.

What does it bring to you?

Fixed security vulnerability in sudo known as Baron Samedit (CVE-2021-3156)
Fixed security vulnerabilities in wolfSSL (CVE-2020-36177 and CVE-2021-3336)
Fixed security vulnerabilities in OpenSSL (CVE-2021-23841, CVE-2021-23840, CVE-2021-23839)
Updated several packages such as kernel, ksmbd, htop, python-paho-mqtt, zerotier, mosquitto, and many more.
Removed empty feed of OpenWisp, so using CLI can throw you a harmless warning, but nothing to worry about actually.

We suggest to update to this version as soon as possible if you are using delayed updates or approvals. Those who are using automatic updates will be updated to this version soon, and they don’t need to do almost anything except rebooting the device to apply kernel update.

Do you found some regression in this update? Please let us know about it and reach our technical support department by following the guide for Getting help.

Pepe · February 18, 2021, 9:21pm

Pepe · February 18, 2021, 9:21pm

dkomrska · February 18, 2021, 9:37pm

Omnia, upgrade from 5.1.8, no issues.

Thanks for the update!

scott323 · February 19, 2021, 1:28am

Turris Omnia 1GB, 5.1.8 -> 5.1.9 flawless, thanks.

ssdnvv · February 19, 2021, 10:40am

Update worked smooth for 1 Turris Omnia 1GB and 1 MOX (PA(SDIO)B) configured as dump AP as well as for 1 Turris Omnia 2GB configured as LTE-Router.
The following issue applies to v.5.1.9, 5.1.8 and maybe earlier versions, I encountered it with 5.1.8 (as I only upgraded my TO from 3.x to 5.1.8):

and

seem to be related, this workaround solved my problems:

So there seems to be an issue with the DSA-implementation (as it only hits when using lanx.y to define VLANs per port, but not when using eth2.y) that is reproduceable in the current versions. Maybe the developers should have a look at this.

johkra · February 20, 2021, 8:48am

Mh, I can’t connect to Wifi after updating to 5.1.9. Wifi works fine after rollback to 5.1.8.

Looking at logs, it seems the wlan interface goes down shortly after connecting, but I couldn’t see any pointers towards why in the logs. Extract:

Feb 20 08:06:58 turris netifd: Network device 'wlan0' link is up
Feb 20 08:07:01 turris crond[7576]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Feb 20 08:07:01 turris hostapd: wlan0: STA <mac> IEEE 802.11: authenticated
Feb 20 08:07:01 turris hostapd: wlan0: STA <mac> IEEE 802.11: associated (aid 1)
Feb 20 08:07:02 turris netifd: Network device 'wlan0' link is down
Feb 20 09:07:02 turris kernel: [   88.850720] br-lan: port 7(wlan0) entered disabled state
Feb 20 09:07:02 turris kernel: [   88.910096] device wlan0 left promiscuous mode
Feb 20 09:07:02 turris kernel: [   88.914571] br-lan: port 7(wlan0) entered disabled state
Feb 20 08:07:02 turris hostapd: Configuration file: /var/run/hostapd-phy0.conf
Feb 20 09:07:03 turris kernel: [   90.510122] ath10k_pci 0000:02:00.0: pdev param 0 not supported by firmware
Feb 20 09:07:03 turris kernel: [   90.531231] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Feb 20 09:07:03 turris kernel: [   90.539394] br-lan: port 7(wlan0) entered blocking state
Feb 20 09:07:03 turris kernel: [   90.544724] br-lan: port 7(wlan0) entered disabled state
Feb 20 09:07:03 turris kernel: [   90.550215] device wlan0 entered promiscuous mode
Feb 20 08:07:03 turris hostapd: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Feb 20 08:07:03 turris hostapd: wlan0: interface state COUNTRY_UPDATE->HT_SCAN
Feb 20 08:07:04 turris hostapd: wlan0: interface state HT_SCAN->DFS
Feb 20 08:07:04 turris hostapd: wlan0: DFS-CAC-START freq=5660 chan=132 sec_chan=1, width=0, seg0=0, seg1=0, cac_time=60s
Feb 20 08:07:05 turris hostapd: wlan1: STA <mac> IEEE 802.11: authenticated
Feb 20 08:07:06 turris hostapd: wlan1: STA <mac> IEEE 802.11: associated (aid 1)
Feb 20 08:07:06 turris netifd: Network device 'wlan1' link is down
Feb 20 08:07:06 turris netifd: bridge 'br-lan' link is down
Feb 20 08:07:06 turris netifd: Interface 'lan' has link connectivity loss
Feb 20 09:07:06 turris kernel: [   93.240439] br-lan: port 6(wlan1) entered disabled state
Feb 20 09:07:06 turris kernel: [   93.273367] device wlan1 left promiscuous mode
Feb 20 09:07:06 turris kernel: [   93.277842] br-lan: port 6(wlan1) entered disabled state
Feb 20 08:08:01 turris crond[7957]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Feb 20 08:08:04 turris hostapd: wlan0: DFS-CAC-COMPLETED success=1 freq=5660 ht_enabled=1 chan_offset=1 chan_width=2 cf1=5670 cf2=0
Feb 20 08:08:04 turris hostapd: Using interface wlan0 with hwaddr <mac> and ssid "<ssid>"
Feb 20 09:08:04 turris kernel: [  151.351066] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Feb 20 09:08:04 turris kernel: [  151.357525] br-lan: port 7(wlan0) entered blocking state
Feb 20 09:08:04 turris kernel: [  151.362850] br-lan: port 7(wlan0) entered forwarding state
Feb 20 08:08:04 turris netifd: bridge 'br-lan' link is up
Feb 20 08:08:04 turris netifd: Interface 'lan' has link connectivity
Feb 20 08:08:04 turris hostapd: wlan0: interface state DFS->ENABLED
Feb 20 08:08:04 turris hostapd: wlan0: AP-ENABLED
Feb 20 08:08:04 turris netifd: Network device 'wlan0' link is up
Feb 20 08:08:16 turris hostapd: wlan0: STA <mac> IEEE 802.11: authenticated
Feb 20 08:08:16 turris hostapd: wlan0: STA <mac> IEEE 802.11: associated (aid 1)
Feb 20 08:08:16 turris netifd: Network device 'wlan0' link is down

Do you have any suggestions on how to get more information on the reason of the device going down after association? I don’t mind testing newer firmware versions or factory resetting if this helps debugging.

Tom · February 20, 2021, 8:59am

Omnia 2020, upgrade from 5.1.8 -> 5.1.9, with R11e-2HPnD and R11e-5HacT wifi modules and ssd, no issues, looks very stable. Thanks!

Pepe · February 20, 2021, 12:00pm

Can you please tell us something more about your Wi-Fi configuration and which drivers for ath10k are you using? From your log, I see that it is a few minutes after rebooting. You can try to change channels if it helps, but diagnostics would be helpful.

johkra · February 20, 2021, 1:17pm

I think I’m using the default drivers, although I also tested Candela drivers. After rollback to 5.1.8 and update to 5.1.9 I have kmod-ath10k and and ath10k-firmware-qca988x installed.

The config is N-40MHz at 5 GHz at a fixed channel (I tried changing channel during testing) and N-20MHz at 2.4 GHz at a fixed channel. Both use WPA2-PSK/3-SAE Mixed mode.

Writing this and re-reading the WPA3 section at https://openwrt.org/releases/19.07/notes-19.07.0#wpa3_support, I found the issue:

I had wpad-wolfssl installed. After I removed wpad-wolfssl and installed hostapd-openssl instead, Wifi works again. Given that wolfssl was updated, maybe wpad-wolfssl also needs changes?

My problem is solved.

Cabal · February 20, 2021, 4:01pm

After update my Aeon Z-Stick works.
I had to rollback 5.1.8 and 5.1.9 RC, but 5.1.9 final works.

elodg · February 22, 2021, 7:50pm

Was using wpad-wolfssl in a nice 160MHz, WPA3, optional 802.11w setup in 5.1.8. In 5.1.9 this does not work anymore. Went back to wpad and stock ath10k drivers/firmware and now only 80 MHz, WPA2 works on a WLE1216V5-20. Reported it to tech support.

morthond · February 21, 2021, 3:58pm

With Turris OS 5.1.9 - Reforis (version 0.9.5) infinite loops when I try to login via ipad/safari to do updates

Hi! This is my first post - i could be in the wrong place or missing stuff…, doing my best to report a problem that I ran into.

This started when I first got my Turris omnis - was rev 3x or so - the Omnia 2020 came from amazon a little over a week ago. I had upgraded to 5.something(5.1.3 maybe?) and got reforis happy with hints from the forum (ssh’d in and opkg install’s reforis packages). Latest automatic update took reforis back to a loopy login that never does anything on my ipad (just reloads the same page with some spinning circles and an admin menu that I can’t click at all) over and over forever). I tried the same old forum commands with an ssh session and nothing changed.

It looks just like this on my iPad:

Now for the info that was supposed to be gathered up:

About info:

Serial number. 60129563417.
Turris OS version. 5.1.9
Turris OS branch. hbs
Kernel version. 4.14.221

No hardware changes.

I’m gathering logs to help find this problem. Download to my ipad didn’t download at all… i’ll reply to this post with my laptop with more info (hopefully an upload of the gathered data).

morthond · February 21, 2021, 4:42pm

I tried reforis with my laptop (Mac book pro/safari) and it logged in perfectly fine and was completely happy. So this seems related to my iPad and ReForis working together well at all.

I don’t know how to upload the compressed log files that were generated - just a button here in the forums for uploading images. I’d try to upload the text of the log files that were specified in the getting help - but they are very long and don’t have any error messages that help find this problem (no reforis error messages at all). I’ve looked around for logs for ReForis and failed to find any. They sure are hiding good.

The one message in /var/log/messages that shows up about 20 times overall (every 15 minutes or so from Feb 21st 8:45am till 15:00) looks like this (I don’t think this will help… but it’s the only reforis message at all):

Feb 21 15:00:01 turris crond[32050]: (root) CMD (/usr/bin/notifier)
Feb 21 15:00:01 turris crond[32054]: (root) CMD (/bin/sh -c "source /lib/functions/sentinel.sh; allowed_to_run "nikola" && exec sentinel-nikola --     random-sleep")
Feb 21 15:00:01 turris crond[32052]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Feb 21 15:00:01 turris crond[32051]: (root) CMD (netmetr --autostart --dwlhist --rwait 1800 &)
Feb 21 15:00:01 turris crond[32055]: (root) CMD (/usr/bin/get-api-crl)
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT (Not agreed with EULA.)
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT ()
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT (EULA could be found at /usr/share/sentinel-eula/ and you can)
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT (agree with it either in ReForis data collect tab or using)
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT (uci config:)
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT (uci set sentinel.main.agreed_with_eula_version=1 && uci commit)
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT ()
Feb 21 15:00:01 turris crond[32049]: (root) CMDOUT (EULA version may increase in time. See documentation for more details.)
Feb 21 15:00:02 turris crond[32045]: (root) CMDOUT (There is no message to send.)
Feb 21 15:01:01 turris crond[32276]: (root) CMD (/usr/bin/rainbow_button_sync.sh)

I tried the uci config and icu commands from messages - don’t seem to do anything… but I’m not sure at all. I tried my iPad again after and nothing changed.

If there is something else I can upload - please point me to it and I’ll be glad to add the extra info.

I hope this is enough info to maybe find this problem. Thanks for any help

Pepe · February 21, 2021, 4:47pm

Unfortunately, we are aware that this is happening, right @Aleksan4eg? I think it could help to try to switch to the HBL branch to have a new reForis version to see if things improve and let us know. You can also wait a little bit more until a new reForis version reaches HBK or HBT, which should be in a few days.

Aleksan4eg · February 22, 2021, 10:42am

Yes, we are aware of this issue and I believe that in HBL it persists. We will fix this issue ASAP. Thanks for reporting!

cassianoleal · February 22, 2021, 1:14pm

I had the same issue. Glad I found your post, thanks!

Definitely needs a solution for users of wpad-wolfss.

yorik · February 24, 2021, 11:58am

Looks like there is there is bug in all 5.* versions, at least for Omnia: router drops packets regularly. See Omnia drops a lot of packets over ethernet for details.

I had to rollback to 4.0.5 to make it stable.

szogi · February 24, 2021, 1:12pm

After upgraded to Turris OS version 5.1.9 (kernel version 4.14.221) wifi now and then crashing:

[28991.206617] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28991.309011] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28991.411401] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28991.513791] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28991.616191] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28991.718583] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28991.820984] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28991.923374] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28992.025766] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28992.128168] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[28994.188213] ieee80211 phy0: Hardware restart was requested
[28995.563055] ath10k_pci 0000:02:00.0: device successfully recovered

[38714.339684] ath10k_warn: 25 callbacks suppressed
[38714.339690] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38714.442079] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38714.544534] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38714.646866] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38714.749261] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38714.851653] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38714.954053] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38715.056451] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38715.158840] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38715.261230] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[38717.386218] ieee80211 phy0: Hardware restart was requested
[38718.757800] ath10k_pci 0000:02:00.0: device successfully recovered

Mannshoch · February 25, 2021, 9:33pm

Does the automatically switch between SFP and Ethernet WAN again?