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)
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.
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.
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.
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.
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.
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?
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.
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.
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).
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
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.
