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
• 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.
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).
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… )
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.
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
Could be. Bellow the output from console. That is everything I get.
5611700 bytes read in 299 ms (17.9 MiB/s)
wdt status 00000003
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
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