Turris OS 6.5.0 is released!

amit · January 24, 2024, 12:36pm

My Turris Omnia router got auto-updated last night from 6.4.4-hbs. Since the update, openvpn client does not work properly. It drops all traffic. I’ve been using the same configuration with openvpn for multiple years now - I even tested the same vpn connection on another device and that works well.

viktor · January 24, 2024, 12:56pm

I also have the original Omnia with no modifications and I evaluated the update as 50:50. It’s strange that some people get away with it and others don’t.

Stemar · January 24, 2024, 1:41pm

I upgraded the ancient Turris 1.0 from the original cz.nic 1CZK campaign. It was an automatic upgrade and subsequent reboot, with no optional firmware upgrade, no manual intervention. After the reboot, all LAN ports remained in a strange state. From the inside view everything seemed fine, ethtool detected the connected links, even tcpdump could listen to the br-lan traffic. But in reality Turris was not sending any packets over the br-lan interface, no connection could be established. The WAN port (PPPoE to VDSL modem) worked normally. Neither a reboot nor a roll-back to the previous version (via Schnapps) changed anything.
The problem disappeared after installing the optional firmware upgrade via Reforis-Package management and subsequent reboot. Since then Turris is working normally again.

mionica · January 24, 2024, 2:24pm

Yes, should be safe. Do the following:

open a ssh to the router and start top in it
in reforis, Package Management > Packages: check Latest Firmware and, under it, all 3 items; hit Save
keep an eye on top; you should see shortly a process called mtd using ~20% of the CPU; in that window, wait until it goes away (and wait 30s after that - it should run twice)
once it’s done, quit top (press ‘q’)

At this stage, you can be in one of 2 situations:

everything’s good; or,
flash is broken.

To make sure everything will be allright, in that ssh window, run nor-update:

if everything was already good, you should see this:

Verifying /dev/mtd0 against uboot ...
a3a04aa6143fe437e00b96fbcc8cd20f - /dev/mtd0
a3a04aa6143fe437e00b96fbcc8cd20f - uboot
Success
Verifying /dev/mtd1 against rescue ...
550b8eb1766f9348fe928ebcbbd3aa49 - /dev/mtd1
550b8eb1766f9348fe928ebcbbd3aa49 - rescue
Success

If the flash was broken however, it will be fixed by the second run.
At this point, you can safely reboot.

Technical explanation: ithe reason the flash could be barfed the first time is an error in the nor-update script, which causes u-boot to be corrupted shortly after being updated.
However, even if corrupted, on the second run, nor-update will detect the new u-boot, update the fw_env settings as it should have in the first place, and flash u-boot without courrupting it immediately afterwards, as it had done in the first place.
Of course, if you don’t have an /etc/fw_env.config and/or your router came with a recent-enough u-boot, it will work first time.

DIKKEHENK · January 24, 2024, 2:41pm

thxs!
Should one remove any USB drives?

Edit nope. Yahoo! btw, the cpu activity here lasted longer than 30 sec’s almost 45. FYI
and now U-Boot 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)

Oh, Also did this with a MOX classic, all fine.

mionica · January 24, 2024, 3:03pm

the cpu activity here lasted longer than 30 sec’s almost 45

That’s fine. I suggested you waited for 30s after you no longer saw any mtd process running, just in case you were eager and hit q before the 2nd mtd run started :>
The 2 mtd runs should be a quick one - a few seconds - for uboot, and about 8 times as long for the other (the rescue system). Didn’t bother timing those, nor do I know the order they’re called in - that’s why I advised running top (anyway, a few 10s of seconds sounds about right)

Anyway, let’s get back on-topic. I think everything that was to be said about the NOR update, already was.

iron-maiden · January 24, 2024, 3:19pm

Congratulations. I must admit that you were very brave!

DIKKEHENK · January 24, 2024, 3:28pm

Sweating here! Since i do not have a second one standby and no serial cable with some linux thing standby…but mionica’s how to do is very clear for brave nOOb’s Also, like my omina very much, so better to bring it totaly up-to-date.
No trouble with Wifi cards & config, also openVPN no issues on both MOX and Omnia.
Now i have to find out what the actual advantage is And if this nOOb can do it, anyone can!

tac2 · January 24, 2024, 5:10pm

MOX A+D Vlan conf 6.4.4 > 6.5.0

Smooth run

Thank you team!

pete · January 24, 2024, 6:18pm

super work, thanks for your awesome detective work. Now my IGG Omnia is on latest u-boot and I did not have to mess with a serial cable.

edit: my fw_env.config looks like this even after the update:

/dev/mtd0 0xC0000 0x10000 0x40000

not sure if this is an issue, but the router boots and works fine.

also, fw_printenv returns: Warning: Bad CRC, using default environment

jada4p · January 24, 2024, 7:01pm

Encouraged by @DIKKEHENK (and lengthy guide of @mionica - thanks a lot!) I actualised firmware as well… After some time and reboot all seems to work.

BTW, how can I find U-boot version? Command strings /dev/mtdblock1 | grep “U-Boot 20” which used to say it, doesn’t say anything.

michalko58 · January 24, 2024, 7:03pm

Thanks, this helped.

But I found another problem. Wireguard site-2-site stopped working for some reason. I am unable to ping the other site.
I don’t know if the second Omnia was restarted or not after the yesterdays update…

DIKKEHENK · January 24, 2024, 7:04pm

This should do the trick with omnia ?

strings /dev/mtd0 | grep U-Boot

this is the result here

jada4p · January 24, 2024, 7:08pm

Thanks, works, it’s U-boot 2022.10 now.

mionica · January 24, 2024, 7:55pm

Edit: I had originally provided the wrong contents of fw_env.config (they worked with fw_printenv, but not with fw_setenv). Fixed.

echo /dev/mtd2 0x0 0x10000 0x10000 > /etc/fw_env.config
(you only need to do this once, after your first booted with the new uboot.

If this is not enough to fix it (in the case that the environment block is actually invalid), the only way to fix it would be to enter uboot cmdline via serial, and run saveenv there - and after that it should work.
There isn’t much of a way of avoiding that - I could give you the contents of most (but not all) variables in the default environment, but some of those are router-specific (router serial number, a few ethernet MAC addresses).

Anyway. That error is purely cosmetic, unless you really want to change the way the router boots; and if you’re so motivated, then I’m pretty sure you have, or are willing to get something like this - note, I’m not endorsing that particular one in any way; any 3.3V USB-“TTL” serial cable with individual wires will do - what you don’t want, is the ones that have a single monolithic 6-pin F header, like this one).
Cable manufacturer, length, or chip type (I’ve used so far FTD232*, PL32*, CH34*) really don’t matter - only the voltage.
!!! NOTE THAT A 3.3V CABLE IS NOT SUITABLE FOR TURRIS MOX !!! - 3v3 only works on Omnia, and it can fry your Mox if attempted!
Btw, a 3.3V host like the Omnia will absolutely work with a 2.5V serial cable, and probably with a 1.8V cable too (worst case is, you fry the cable - the router should be safe); what you must avoid like the plague, is having a cable using higher-than-the-router voltage (for example, don’t event think about using a 5V cable on either the Mox or the Omnia). Details here.

pete · January 24, 2024, 8:00pm

Thanks for the info!

It still throws the Bad CRC error, even after I changed the env config as per your instructions.

I’ll leave it for now, since I’m using the default config anyway…

jada4p · January 25, 2024, 10:08am

On my MOX (classic, HBK branch, .5 GB, 2x WiFi, simple config) I tried to update firmware etc using reForis. Unfortunately without success, but, with luck, MOX is working

Current status: OS 6.5.0, HBK, U-boot 2022.07, factory 6.3.2

TurrisOS 6.5.0, Turris Mox

Thu Jan 25 10:12:29 CET 2024
SN: 56639897919
turris-version: 6.5.0
branch: hbk

root@MOXjp:~# strings /dev/mtdblock1 | grep “U-Boot 20”
U-Boot 2022.07 (Aug 15 2022 - 12:25:08 +0000)

root@MOXjp:~# schnapps factory-version
6.3.2

On reForis → Package Management → Packages I checked “Latest firmware”, and both “U-boot and rescue image” & “Factory image”.

Later I run pkgupdate via CLI, while logging it into file. It ended with error(s), neither firmware, nor factory image were changed.

Listing of pkgupdate

pkgupdate start: 20240125-101803
turris-version: 6.5.0 branch: hbk SN: 56639897919
INFO:Target Turris OS: 6.5.0
INFO:Queue install of firmware-updater/turrispackages/1.0-4
Press return to continue, CTRL+C to abort
INFO:Downloading packages
INFO:Executing preupdate hook: 05_schnapps.sh
Snapshot number 405 created
INFO:Unpacking download packages
INFO:Checking for file collisions between packages
INFO:Running pre-install and pre-rm scripts and merging packages to root file system
INFO:Removing packages and leftover files
INFO:Running post-install and post-rm scripts
INFO:Running postinst of firmware-updater
Verifying /dev/mtd0 against secure-firmware.bin …
e12a263c63bd9860cff844763e81e56b - /dev/mtd0
e12a263c63bd9860cff844763e81e56b - secure-firmware.bin
Success
Verifying /dev/mtd1 against uboot …
bd802eb0ec60fd89f983ac3cd4860fba - /dev/mtd1
bd802eb0ec60fd89f983ac3cd4860fba - uboot
Success
Verifying /dev/mtd3 against rescue …
39f02d9fb36b4258bac37924bcdf570c - /dev/mtd3
39f02d9fb36b4258bac37924bcdf570c - rescue
Success
uci: Entry not found
INFO:Cleaning up control files
INFO:Executing postupdate hook: 20_update_alternatives.sh
INFO:Executing postupdate hook: 95_schnapps.sh
INFO:Executing postupdate hook: 96_firmware_updater
Verifying /dev/mtd0 against secure-firmware.bin …
e12a263c63bd9860cff844763e81e56b - /dev/mtd0
e12a263c63bd9860cff844763e81e56b - secure-firmware.bin
Success
Verifying /dev/mtd1 against uboot …
bd802eb0ec60fd89f983ac3cd4860fba - /dev/mtd1
bd802eb0ec60fd89f983ac3cd4860fba - uboot
Success
Verifying /dev/mtd3 against rescue …
39f02d9fb36b4258bac37924bcdf570c - /dev/mtd3
39f02d9fb36b4258bac37924bcdf570c - rescue
Success
uci: Entry not found
INFO:Executing postupdate hook: 99_approvals_cleanup
INFO:Executing postupdate hook: cleanup_rc_d.sh
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Can’t find anything to flash to ‘dtb’ partition
Snapshot number 406 created
Can’t find anything to flash to ‘dtb’ partition
pkgupdate end: 20240125-101854

DIKKEHENK · January 25, 2024, 11:16am

I have after the updater here the same U boot for mox, so maybe that is the latest?

jada4p · January 25, 2024, 11:20am

It may be so. Don’t know how to check.

Edit: according to Releases · Turris / MOX boot-builder · GitLab is last released version Turris MOX secure firmware - v2022.06.11

viktor · January 25, 2024, 1:23pm

I have the same version. The U-Boot update went without complications (from version 2021.09.07), but the factory image update broke my schnapps.