Turris OS 6.2.3 is out!

Dear Turris users,

We have just released Turris OS 6.2.3 This is mainly a bugfix release - nothing really exciting, except of some bugs being fixed and your router being up to date and more secure.

:bug: Bug Fixes

  • Fixed reForis LAN page when fetching DHCPv6 lease returns an unexpected value
  • Fixed Syncthing dashboard entry design to be more in line with other entries
  • Fixed Turris 1.x rainbow config migration from Turris OS 5

:pushpin: Updates

  • Sentinel Proxy updated to 2.1.0
  • Knot Resolver updated to 5.6.0 (security update)
  • git updated to 2.34.6 (security update)
  • Linux kernel updated to 5.15.90 and 5.10.164

We appreciate any feedback regarding this release.

10 Likes

TO 2016, HBS branch, 2 GB, 2x WiFi, HaaS, RIPE Atlas, Sentinel, lxc, simple config, all seems OK. (*)

MOX classic, HBK branch, .5 GB, 2x WiFi, simple config, all seems OK. (*)(%)(+)

(*) for my simple case is rainbow working
(%) except SDIO WiFi
(+) USB3 is working

  • Linux kernel updated to 5.15.90 and 5.10.164

Previous changelogs in the docs mentioned 5.15.x kernel update for Turris 1.x, was that rolled back to 5.10.x?

Do I get it right that Turris 1.x was rolled back to 5.10.x kernel?

If so, it might be a good idea to mention that in the docs changelog linked above and new releases forum posts as well, not just bury it inside a single previous release forum post. I just spent unproductive 30 minutes searching for why my kernel was “stuck” on 5.10, almost firing off a support email :wink:

Just something like “Linux kernel updated to 5.15.90 and 5.10.164 (Turris 1.x only)” would be much clearer and avoid any confusion.

EDIT: Found the post mentioning it. Sad eyes. Guess we Turris 1.x beggars can’t be choosers :wink:

Otherwise, 6.2.3 seems to work fine on my Bluey. Did a full medkit reinstall from scratch, since for some reason Bluey got stuck in some loop and I had to factory reset to the original 3.x OS, with the normal 3->5 update stalling, but the medkit way worked a charm…

Thanks!

USB3 still not working. Module A not listing USB storage which worked fine until TOS 6.

USB storage verified in PC:
Bus 004 Device 002: ID 0bda:9210 Realtek Semiconductor Corp. NVME&SATA
T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=10000 MxCh= 0
D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=0bda ProdID=9210 Rev=20.01
S: Manufacturer=USB3.1
S: Product=NVME&SATA
S: SerialNumber=012345679102
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

MOX (A+C) - USB3 still NOT working.

Rolled back to 5.4.4 where the USB3 HDD works just fine.
On 5.4.4:

# cat /sys/kernel/debug/usb/devices
T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=0bc2 ProdID=3322 Rev= 1.00
S:  Manufacturer=Seagate
S:  Product=Expansion Desk
S:  SerialNumber=NAAAF32S
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:  If#= 0 Alt= 1 #EPs= 4 Cls=08(stor.) Sub=06 Prot=62 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms

# lsusb -vt
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M

Turris Omnia 2020 (TOS v6.2.2) → (TOS v6.2.3)

Everything works fine so far (Linux containers, mSATA mount, DDNS, WiFi etc)

Reforis is broken. Something python related. Luci works fine. Can post a screenshot if you want.

Definitely please share a screenshot (or, even better, copy the error text and paste it formatted as code here).

1 Like

MOX A+D 6.2.2 → 6.2.3 no issues

Thank you team!

Turris team, you folks are doing an AWESOME jobl LOVE my Omnia. Keep up the GREAT work. THANK YOU! :hugs:

My original unmodified crowdfunded Turris Omnia is not happy. Over the past three days it’s been dropping WAN, LAN and/or WiFi. Web login would succeed, but then be unable to render any pages.

A manual reset (cycling power) restores temporary sanity.

My Omnia is configured with the defaults, with threat detection options enabled. The only thing I’ve added is a 256GB NTFS USB drive as a CIFS NAS.

My Omnia has been so reliable that I’ve completely forgotten all my router-fu, so my main plan is simply to await future updates.

Is there anything I can do to help things along?

I have simillar issue. Two times happen that some clients were disconnected from wifi and was not able to connect - some authorization issue. I had to reset Omnia. And yesterday, all clients were disconnected. And when I logged in to check logs, I’ve found that Omnia just restarted. I don’t know why.

I’d blame the threat detection. In my network it found zillions of errors and overloaded the system RAM (which can have various funny consequences). Try turning the threat detection off.

1 Like

I’ve disabled threat detection, though it had been running well since updating to TOS 5 HBS.

Turris OS 6.2 (don’t know the exact release) came with some fixes for the threat detection. One of them is fixing its inability to create Reforis notifications. So after being fixed, the threat detection plugin starts generating Reforis notifications for each identified threat. If your home network looks similar to mine, that means thousands of notifications per minute. This is a load for which reforis definitely hasn’t been built, so it ends up eating all RAM and triggering the OOM killer which kills random processes on the router.

I updated from 6.2.2 to 6.2.3 but the WAN interface does not come up any longer after the upgrade. I connect to the ISP with an SFP
(1G SFP Wideband BiDi LX 10 km, ᵀˣ1310 / ᴿˣ1460-1580 nm, DDM, LC-Simplex, Singlemode).

The only workaround I found so far is to revert back to the snapshot prior the update, i.e. 6.2.2. After the reboot and running 6.2.2 the connectivity to the WAN still didn’t work at first, but could be reestablished by removing the SFP module and reinserting it again (without shutting down the router in between).

I tried once more to upgrade but was able to reproduce the issue, as well as the reverting procedure.

Do you have any hints what the issue might be and who this could be solved?

I also just updated from 5.3.11 to 6.2.3 and have the “same” issue like @schoenbi
SFP WAN is not comming up, but if i remove and connect again the fiberwire, it suddenly recognizes a connection:

Feb  7 20:26:25 turris kernel: [    9.865282] sfp sfp: Host maximum power 3.0W
Feb  7 20:26:25 turris kernel: [   10.198065] sfp sfp: module TP-LINK          TL-SM321B        rev 1.1  sn 35702202030045   dc 170223  
Feb  7 20:26:25 turris kernel: [   10.207424] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Feb  7 20:26:25 turris kernel: [   15.043825] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode

<<<<<< disconnect wire and reattach >>>>>>>

Feb  7 20:32:26 turris kernel: [  385.706015] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
Feb  7 20:32:26 turris kernel: [  385.714091] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Feb  7 19:32:26 turris netifd: Network device 'eth2' link is up
Feb  7 19:32:26 turris netifd: Interface 'wan' has link connectivity 
Feb  7 19:32:26 turris netifd: Interface 'wan' is setting up now
Feb  7 19:32:26 turris netifd: wan (8774): udhcpc: started, v1.33.2
Feb  7 19:32:26 turris netifd: wan (8774): udhcpc: sending discover
Feb  7 19:32:28 turris netifd: wan (8774): udhcpc: sending discover
Feb  7 19:32:28 turris netifd: wan (8774): udhcpc: sending select for xxxxxxx
Feb  7 19:32:28 turris netifd: wan (8774): udhcpc: lease of xxxxxxxx obtained, lease time 4000
Feb  7 19:32:28 turris netifd: Interface 'wan6' is enabled
Feb  7 19:32:28 turris netifd: Network alias 'eth2' link is up
Feb  7 19:32:28 turris netifd: Interface 'wan6' has link connectivity 
Feb  7 19:32:28 turris netifd: Interface 'wan6' is setting up now
Feb  7 19:32:28 turris netifd: Interface 'wan' is now up
Feb  7 19:32:28 turris firewall: Reloading firewall due to ifup of wan (eth2)
Feb  7 19:32:30 turris netifd: Interface 'wan6' is now up
Feb  7 20:32:30 turris dnsmasq-dhcp[5239]: read /etc/ethers - 0 addresses

I can remember in the early days there had been that SFP enable bug (set it as eth2…), i can’t remember what had to be changed nor if that had to be in place still in 5.3.11. I found in 6.0.0 some comments about a SFP bugfix for 5.15. But i am just guessing here.
Any inputs?

I also created a ticket a week ago, but didn’t heard back anything yet. It is quite “thrilling” to know that network will not be back after an power outage… :smiley:

This topic was automatically closed after 20 days. New replies are no longer allowed.