Turris OS 4.0.5 is released out!

[Pepe]

Dear Turris users,

We are proud to announce that we just released Turris OS 4.0.5 for all of our three routers - Turris 1.x, Turris Omnia and Turris MOX.

This release is based on OpenWrt 18.06.6 and it includes the latest development version of ReForis, multiple CVE fixes, package updates and added Atlas SW Probe.

Changelog:

• Based on the latest OpenWrt 18.06.6
• kernel: update to version 4.14.162
• python3: update to version 3.6.10
• nextcloud: update to version 16.0.7
• mariadb: update to version 10.4.11
• foris: fix for three-level name timezones
• wget: fix CVE-2019-5953
• unbound: update to version 1.9.6
• php7: update to version 7.2.26
  Fixes: CVE-2019-11044, CVE-2019-11045, CVE-2019-11046, CVE-2019-11047, CVE-2019-11050
• nano: update to version 4.7
• openssl: update to version 1.0.2u
• bird: update to version 1.6.8
• reforis: update to the latest development version, adds openvpn-plugin
• ffmpeg: update to version 4.0.5
  Fixes: CVE-2019-12730, CVE-2019-17539, CVE-2019-17542
• e2fsprogs: fix CVE-2019-5094
• christmas: removed from default installation

You should be updated to this version automatically from the previous version and if you are using approvals you can check Updater tab to approve the update.

We appreciate any feedback for this release.

[mnd999]

haveged still seems to be using a lot of CPU on my Omnia

Mark

[choseecz]

In the package https://repo.turris.cz/hbs/omnia/packages/core/kmod-i2c-mux_4.14.162-1-0a66bb0316b4402bf65555c64ceed313_arm_cortex-a9_vfpv3.ipk is still missing module i2c-mux.ko

[tac2]

Mox A D sfp - smooth upgrade.
Well done turris team!

[jork]

smooth update on MOX, but it is really unstable device …

[snarfel]

Have been getting errors on my MOX via what I presume is the automatic updates process enabled, seems to be stuck on 4.0.3:

Updater failed:

[string “transaction”]:328: [string “backend”]:485: Stage 1 unpack failed: tar: corrupted data

Any way to manually trigger getting updates from the web console?
tar: short read

[weelupek]

I have not recieved the update on my Turris 1.0. Automatic updates enabled. Do I need to do anything ?

[rplevka]

same issue, v1.1.
tried manually with pkgupdate but no dice

# cat /etc/opkg/distfeeds.conf 
src/gz turris_base https://repo.turris.cz/turris/packages//base
src/gz turris_hardware https://repo.turris.cz/turris/packages//hardware
src/gz turris_lucics https://repo.turris.cz/turris/packages//lucics
src/gz turris_management https://repo.turris.cz/turris/packages//management
src/gz turris_node https://repo.turris.cz/turris/packages//node
src/gz turris_openwisp https://repo.turris.cz/turris/packages//openwisp
src/gz turris_packages https://repo.turris.cz/turris/packages//packages
src/gz turris_php https://repo.turris.cz/turris/packages//php
src/gz turris_printing https://repo.turris.cz/turris/packages//printing
src/gz turris_routing https://repo.turris.cz/turris/packages//routing
src/gz turris_sidn https://repo.turris.cz/turris/packages//sidn
src/gz turris_telephony https://repo.turris.cz/turris/packages//telephony
src/gz turris_turrispackages https://repo.turris.cz/turris/packages//turrispackages

# curl -sL https://repo.turris.cz/turris/packages//base | grep -o ">turris-version.*ipk"
>turris-version_3.11.13_mpc85xx.ipk

Do we use wrong repo or it wasn’t updated?

[Pepe]

For the first time I hear that someone complain that i2c-mux.ko is missing and it should mean that it does not work, but it works even when the package is empty. We have it explicitly enabled in the kernel. You can take a look in this commit:

omnia: Make I2C mux integral part of kernel (ba91a158) · Commits · Turris /...

But a better solution is to check it on the device to see if the kernel configuration is enabled/marked as module or not set by running this command:

zcat /proc/config.gz | grep I2C

Turris OS 6.x output:

root@turris:~# zcat /proc/config.gz | grep I2C_MUX
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_GPIO=m
# CONFIG_I2C_MUX_GPMUX is not set
# CONFIG_I2C_MUX_LTC4306 is not set
CONFIG_I2C_MUX_PCA9541=y
CONFIG_I2C_MUX_PCA954x=y
# CONFIG_I2C_MUX_PINCTRL is not set
# CONFIG_I2C_MUX_REG is not set
# CONFIG_I2C_MUX_MLXCPLD is not set

In this concrete case, you can take a look at messages file and by using command grep, you can check for anything related to i2c. I see these rows:

root@turris:~# cat /var/log/messages | grep i2c
Jan 21 21:59:46 turris kernel: [    4.701991] i2c /dev entries driver
Jan 21 21:59:46 turris kernel: [    4.706266] i2c i2c-0: Added multiplexed i2c bus 1
Jan 21 21:59:46 turris kernel: [    4.711150] i2c i2c-0: Added multiplexed i2c bus 2
Jan 21 21:59:46 turris kernel: [    4.716047] i2c i2c-0: Added multiplexed i2c bus 3
Jan 21 21:59:46 turris kernel: [    4.720919] i2c i2c-0: Added multiplexed i2c bus 4
Jan 21 21:59:46 turris kernel: [    4.725859] i2c i2c-0: Added multiplexed i2c bus 5
Jan 21 21:59:46 turris kernel: [    4.730733] i2c i2c-0: Added multiplexed i2c bus 6
Jan 21 21:59:46 turris kernel: [    4.735620] i2c i2c-0: Added multiplexed i2c bus 7
Jan 21 21:59:46 turris kernel: [    4.755797] i2c i2c-0: Added multiplexed i2c bus 8

You might be asking why the package is there and why it is empty in some cases.

• If the kernel config option is marked as module (most of them as loadable kernel modules), then there is exist kmod package which will install kernel object.

In this case, you can use commands like lsmod, modinfo and so on.

For example on Turris 1.1 with installed kmod-dvb-usb-az6007 and when being used:

root@turris:~# zcat /proc/config.gz | grep AZ6007
CONFIG_DVB_USB_AZ6007=m
root@turris:~# modinfo dvb_usb_az6007
module:		/lib/modules/4.4.210-f90a52a6230ecb072f657fce5aebd444-0/dvb-usb-az6007.ko
license:	GPL
depends:	dvb_usb_v2,cypress_firmware,usbcore,rc-core,dvb-core

And when the package kmod-dvb-usb-az6007 is not installed on Turris Omnia:

root@turris:~# zcat /proc/config.gz | grep AZ6007
CONFIG_DVB_USB_AZ6007=m
root@turris:~# modinfo dvb_usb_az6007
cannot find module - dvb_usb_az6007

• If the kernel config option is marked as Y (explicitly stated), then the package exist here as well, but it is empty. We are talking here about .ipk which has size 1,0 kB and this is fine for us for cases if happens that the kernel option is not explicitly enabled. This make us sure that features, which relay on i2c for example Atsha chip stays enabled and working.

[Pepe]

@weelupek, @rplevka: We are still working on automatic migration from Turris OS 3.x to Turris OS 4.x/5.x for Turris 1.x and Turris Omnia routers.

If you would like to have Turris OS 4.x on Turris 1.x routers, you need to follow instructions, which were mention in Turris OS 4.0.3 thread. If you have Turris Omnia routers and would like to start from scratch, you just need to follow instructions mentioned in documentation for a re-flash router.

I wouldn’t suggest restoring the configuration from 3.x as some things (mostly name of interfaces) for Turris Omnia router were changed and it may not be compatible. Doing diff checks for files and then applying is a better choice.

What I said with the previous version, I mean the Turris OS 4.0.3 version. It is always recommended to update from a previous system version to the latest one.

[rplevka]

ah right, that clears things up. I’ll better wait. Thanks for all your efforts!

[anon50890781]

@snarfel

Any way to manually trigger getting updates from the web console?

You mean web UI or ssh cli? From the latter pkgupdate and if that produces errors it could be run with option

-e, --stderr-level=LEVEL   What level of messages to send to stderr
                             (DISABLE/ERROR/WARN/INFO/DBG).

for a more verbose output to assist with debugging.

[hello_friend]

Is there possibility to downgrade from Turris 4.x to 3.x? I tried it with a medkit and LAN interface does not come up (my desktop connected to Turris). If I use medkit from hbs folder (on gitlab) there is no problem at all.

I have Turris Omnia 2019 version.

Any help would be appreciated.

[anon50890781]

@hello_friend

I have Turris Omnia 2019 version
possibility to downgrade from Turris 4.x to 3.x

That hardware revision ships from factory with a new u-boot version that may not be compatible with TOS3.x. Revering to the older u-boot version might provide a solution but is not without hazard.

Though entirely being your business, but if you do not mind asking what is the motivation to downgrade, also considering that TOS3.x is almost at the end of its life cycle?

[hello_friend]

Thanks for the response.

If you look at presentation of Turris 4.x you can found:
“Omnia has no SFP support and just one CPU port in switch”

I know it has SFP support but not as good as in version 3.x.

Yet another thing. My fellow worker owns Turris Omnia as well but he is able to login on https://project.turris.cz/ because of registration code you are able to get on version 3 only.
I want to manage email notification about uplink connectivity lost and I was told you can do it only through the webpage I provided above. It is a neat feature.

One more thing. I would like to try Ludus which has not been possible on version 4.x so far.

If you think of all the issues It looks like Turris 4.x is alpha version comparing to Turris 3.x.

[anon50890781]

@hello_friend

If you look at presentation of Turris 4.x you can found:
“Omnia has no SFP support and just one CPU port in switch”

Support for SFP on the TO platform:

• is implemented in TOS4.x
• automatic switching WAN ↔ SFP is activated with the new u-boot version that ships from factory with with the TO board revision CZ11NIC23
• automatic switching WAN ↔ SFP is currently not enabled on the other TO board revisions but can be switched manually nonetheless

@cynerd

SFP wasn’t “supported” only quite early in the development process od 4.0. The automatic SFP and metalic switch is not supported. You have to switch it manually by relinking devicetree link in /boot . This is fixed on Omnia 2019 already by new uboot

The second CPU port is also activated in these branches

@anon50890781

layout glossary

[a] as currently implemented for HBD [1] & HBL [2] and is subject to change by the TOS developers

---

@hello_friend

I know it has SFP support but not as good as in version 3.x.

What exactly is not as good?

---

Anyway, I am not really certain whether it will remedy the issue you encountered with TOS3x. but if you want to give a it a go with the old u-boot you might want to read

How to flash a new u-boot on Turris Omnia

just be aware of the potential hazard (bricking the node and requiring UART serial to recover)

[hello_friend]

I think I am happy following your response. You look like a knowledgeable person (based on replies not only here but somewhere else).

Just a last question. If newer u-boot is present comparing to Omnia 2019 version will I get newer one through updates?

Thanks a lot. I really appreciate it.

[anon50890781]

@hello_friend

Just a last question. If newer u-boot is present comparing to Omnia 2019 version will I get newer one through updates?

Reckon that is explained in

How to flash a new u-boot on Turris Omnia

[choseecz]

Thank you very much for the explanation.

I’m trying to find a reason why my TV tuner doesn’t work.
So why is the following output on Turris OS 4.0.5 (Omnia):

root@turris:~# zcat /proc/config.gz | grep EM28
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_EM28XX_V4L2=m
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=m
CONFIG_VIDEO_EM28XX_RC=m

When I only found em28xx.ko in the repository, but I can’t find em28xx_dvb.ko.

[hello_friend]

I think if it doesn’t work properly at all (not because of the version) i suggest you to create a separate post for it.