Turris OS 6.0.4 is in the testing branch

Dear Turris users,

We prepared another release Turris OS 6.0.4. In this release, there are three new packages.

  • One package contains Wi-Fi firmware for AsiaRF AW7916-NPD, otherwise it was required to download firmware manually and put it to the correct folder. Another two packages (backend and frontend) are related to LibreSpeed.

There are a few improvements as some of you noticed that Lighttpd is not starting due to rrdtool, that’s fixed in this release and also we looked into crashing Sentinel FWLogs and as well this update brings many security updates.

Here is the changelog for this release:


💥 Breaking Changes
  • Dropped packages for old ISDN4Linux

🚀 New Features
  • Added 10k passwords from Turris Sentinel to common passwords
  • Added packages for LibreSpeed
  • Added firmware package for AsiaRF AW7916-NPD
  • Enabled Multi-Gen LRU (MLGRU)

🐛 Bug Fixes
  • Fixed network diagnostics module
  • Fixed lighttpd module for rrdtool
  • Fixed inaccessible router through hostname when a client didn't send its hostname
  • Fixed crashing Sentinel FWLogs

📌 Updates
  • Christmas updated to be working with recent LEDs change
  • Linux kernel updated to 5.15.80 and 5.10.156
  • PHP7 updated to 7.4.33
  • PHP8 updated to version 8.0.25
  • OpenSSL updated to 1.1.1s
  • wolfSSL updated to 5.5.3 (CVE 2022-42905)
  • SQLite3 updated to 3.40.0

This version is, for now, in the testing branch (HBT). Please refer to the documentation on how you can try this release before it is out for everyone. If you find any bugs, don’t hesitate to reach us.

4 Likes

Does this mean TurrisOS allows to host one’s own on-line speedtest? If so could we please change the following default value from:

line 63 from :

	overheadCompensationFactor: 1.06, //can be changed to compensatie for transport overhead. (see doc.md for some other values)

to
overheadCompensationFactor: 1.00
as there is zero justification to artificially inflate the speedtest results by 6%…

Here is the text from doc.md:

overheadCompensationFactor: compensation for HTTP and network overhead. Default value assumes typical MTUs used over the Internet. You might want to change this if you're using this in your internal network with different MTUs, or if you're using IPv6 instead of IPv4.
Default: 1.06 probably a decent estimate for all overhead. This was measured empirically by comparing the measured speed and the speed reported by my the network adapter.
1048576/925000: old default value. This is probably too high.
1.0513: HTTP+TCP+IPv6+ETH, over the Internet (empirically tested, not calculated)
1.0369: Alternative value for HTTP+TCP+IPv4+ETH, over the Internet (empirically tested, not calculated)
1.081: Yet another alternative value for over the Internet (empirically tested, not calculated)
1514 / 1460: TCP+IPv4+ETH, ignoring HTTP overhead
1514 / 1440: TCP+IPv6+ETH, ignoring HTTP overhead
1: ignore overheads. This measures the speed at which you actually download and upload files rather than the raw connection speed

As it is clear this is a heuristic tailored to the developers own internet access link that does not even generalize over the differences between IPv4 and IPv6 (ignoring IPv6 extension headers), this value should respectfully default to 1.0, if a user wants to have their speedtest return values differently from the “veridically” measured payload goodput, the user needs to make sure anyways that the “correction-factor” actually corrects for something…
The goal here is IMHO laudable: to estimate the gross rate from the measured goodput, but that is a hard problem and simple pro-rating with a fixed factor falls short of achieving the actual goal here.

I am happy to elaborate on more details should that be desired, but pretty please do not deploy this with the default 1.06 fudging factor… (or if you did already make a patch for the next version setting this back to 1.0).

MOX classic, HBK branch, .5 GB, 2x WiFi, simple config, all seems OK, except USB3 - see

1 Like

Update ok: Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, morce.

Firewall logs sending seems to be fixed now! (if this can be called a fix… )

Another RC build is out. There is an updated changelog and cronie package update from version 1.5.7 to 1.6.1.

We are mostly interested in the librespeed client CLI which doesn’t apply this overhead compensation factor. The librespeed-go package which contains the default overhead compensation factor value you mention was submitted by an OpenWrt developer independent from us, so if you want to discuss this, a better place would be in OpenWrt packages or upstream in librespeed-go.

Ah, good then. Thanks for taking the time to respond.

I just placed our 3rd collective purchase order, which includes 9 AW7916-NPD-cards, so there are 7 more useres out there testing it soon :slight_smile:

1 Like

Hmm, I’m still having the LED issue I posted about here.

Omnia 2GB (Indiegogo) with two same wifi 6 cards. Today after auto-restart 5GHz wifi stopped working. Both cards are visible in reforis or LuCi, but 5GHz wifi is not working. Restart didn´t helped, there was no time to investigate it further.

LED still don´t remember brigthness. thanks this I have noticed problem with 5GHz wifi

lspci command seems to return that everything is ok both 6.0.3 and 6.0.4

root@turris:~# lspci
00:01.0 PCI bridge: Marvell Technology Group Ltd. 88F6820 [Armada 385] ARM SoC (rev 04)
00:02.0 PCI bridge: Marvell Technology Group Ltd. 88F6820 [Armada 385] ARM SoC (rev 04)
00:03.0 PCI bridge: Marvell Technology Group Ltd. 88F6820 [Armada 385] ARM SoC (rev 04)
01:00.0 Unclassified device [0002]: MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter
02:00.0 Unclassified device [0002]: MEDIATEK Corp. MT7915E 802.11ax PCI Express Wireless Network Adapter
03:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 01)

Rollback to 6.0.3 helped with this wifi problem, so I will stay definitely on HBS for now.

Hi! I have a problem with OOM-killer with kernel 5.15.80. Turris might want to hold 6.0.4 for HBS.
I solved it by reverting to 6.0.3 (5.15.78).

More details if you want them:

Just upgraded turrix1 from previous 6.0.4 rc - kernel 5.10.156-> 5.10.158-2 and nothing works - no WAN/LAN/WLAN network. Boot process seems OK - LED go 5->1

We didn’t release new RC version since last week. It’s scheduled to be released this week. I think you are talking about our HBK branch, where there could be occasional bugs.

Could be. Bellow the output from console. That is everything I get.

BOOT NAND
reading zImage
5611700 bytes read in 299 ms (17.9 MiB/s)
wdt status 00000003
reading fdt
13486 bytes read in 13 ms (1012.7 KiB/s)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 02100000 ...
   Image Name:   Linux-5.10.158
   Created:      2022-12-12  14:20:02 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    5611636 Bytes = 5.4 MiB
   Load Address: 00c00000
   Entry Point:  00c00290
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 03ff9000, end 03fff4ad ... OK
WARNING: could not find compatible node fsl-usb2-dr

Yep, I know, what’s going on. Will be fixed in a new HBK build, thanks for reporting!

1 Like

Great. Hope nobody else has the same luck.
Now to manually rollback the kernel …

Edit: was not so bad

1 Like

Shouldn’t a drop a of a feature not be at least a minor version instead of a patch version? For my understanding major can change a lot and break things, minor can add new features (and maybe break things), but patches are always save and are intended to repair things instead of harming something. Or am i wrong? Software versioning - Wikipedia

And no…i am not using ISDN anymore :smiley:

Turris OS 6.0.4 RC3 is out! :wink:

  • Added Snowflake
  • Wi-Fis are now working
  • Updated Linux, golang, cronie
    and many more…
4 Likes

Applied RC3 of OS 6.0.4

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

(*) for my simple case is rainbow working - heartbeat during day, off during night :wink:
(%) except SDIO WiFi.
(+) USB 3 flash not recognized