OpenWrt 19.07.0 does not work on Turris Omnia

After an afternoon loss. I can say with security that OpenWrt 19.07.0 does not work on Turris Omnia.

After normal upgrade, using web interface and without keep settings. Unable to access by web interface or using SSH.

After connect serial console and use "installation" "method 1", including "reset u-boot", as specified here: https://openwrt.org/toh/turris/turris_omnia. I get same result, unable to access by web interface or using SSH.

The same steps with OpenWrt 18.06 ("installation" "method 1", including "reset u-boot") and all is working as before.

In the forum there are some threads indicating that other TO users successfully deployed Release Candidates from the 19.07 branch but then there also reports from others struggling with the transition.

It may actually depend on the hardware revision of the TO since the latest revision CZ11NIC23 ships from factory with a new u-boot version

I have an Omnia latest revision and of course I cannot install any version of OpenWRT. In my humble opinion it should disappear from the list of supported devices. It wasn't born with OpenWRT in mind.

If it does not work for you, it does not mean it does not work for others.

I followed the step-by-step guide, with three different versions of OpenWRT, from the first stable at 19.07 rc2 to snapshots. If you can do, it prove it in a video and explain how to do it. I'm not totally stupid.

1 Like

Huh. That U-Boot version thing is fascinating. I wonder if that's why some people have issues. I remember manually updating mine...

Unless i missed it but the flash instructions do not seem to mention to download the uboot-turris-omnia-spl.kwb from the OpenWrt repo and get it installed in the respected MTD partition.

Which may solve the issue for the CZ11NIC23 board revision that ships with the updated u-boot version.

Yet, it is not even clear whether the OP's node is of that board revision.

@anon45274024, I understand my Turris Omnia is the "original" because I bought it during Indiegogo campaign.

@lucenera, I've been using OpenWrt for years in my Turris Omnia. since before it was officially supported, at first cloning and building from the GitHub repository of the user (I do not remember his name) that created the first version that after was merged in the OpenWrt official GIT. And right now it is working with OpenWrt 18.06.

@Pepe, If it works for some but not for others, there must be some reason. The right thing would be a note with the requirements, required revision, etc. As is done with other router models.

@neheb, Do you have the "original" Turris Omnia and it works with OpenWrt 19.07.0? Can you tell me some documentation of how to update u-boot?

1 Like

That would probably be the CZ11NIC23 board then. Unfortunately it seems that the board revision is not available via userland query, unless being inferred from hardware registers.

To find the exact revision of Turris Omnia you can look on markings on PCB. In front of board on right side just behind LEDs there is code CZ11NIC**.


That said

It should not be necessary to update u-boot for the CZ11NIC23 board. There is currently no documentation per se but the procedure been recent discussed here [1]


The best way to get to the bottom of it is perhaps via UART console, which seems you have at your disposal

Is the node starting correctly after the upgrade and all related servers up, e..g. DHCP, SSHD,HTTP?


[1] https://forum.turris.cz/t/how-to-flash-a-new-u-boot-on-turris-omnia/11826/17

Just remembered Openssl never finishes generating uhttpd.key on Turris Omnia this being an issue and might be happening here as well

Yesterday I did several tests, but from what I remember:

  • Making a netstat -l all services seems up.
  • From PC to Turris Omnia I get ping (Now I don't remember backwards, Turris Omnia to PC).
  • SSH from PC to Turris Omnia, it request password but reject it always.
  • SSH from Turris Omnia to PC, do not works it don't request password, nothing.
  • Trying to acces by web interface I think I remember that the message was "Connection rejected"

Maybe you could try a fresh test and report back?

Which is good since it would imply basic connectivity (DHCP, routing) is working.


I could be wrong but that smells of the entropy issue mentioned above in generating the keys for SSH and HTTP.

1 Like

This can be related with the impossibility of access by web interface. I can try to upgrade by web interface keeping settings, to already have the certificate generated.

Now I don't have time. But this afternoon I will try to get time to try with this new information. Thanks @anon45274024 .

Not sure whether that method retains the openssl keys/certs from the 18.06.x instance generated for SSH and HTTP or whether they get wiped and generated new.

With the sysupgrade to 19.07 the OpenSSL version increments from 1.0.2 to 1.1.1, and latter having different (entropy) prerequisites for key generation.

Aside from the workaround in the other thread it might be worth considering:

  • backup keys/certs for SSH/HTTP from the 18.0.6.x instance
  • insert the backed-up keys/certs into the sysupgrade image, if that is feasible and/or not violating some checksum check of the image

It's up to you to steer the topic in the right direction.
If you don't want to talk about omnia, you can flag postings that go in this direction.
You can also clearly state "Guys, I'm through with the omnia, I don't want to talk about omnia, I want to talk about a replacement."

1 Like

first of all thank you @anon45274024. It seems that the trouble was entropy, after upgrade from web interface with the option "keep settings" all is working. But the web interface is extremely slowly (any ideas?).

For the rest, I can see this in dmesg:

[   11.554083] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[   11.561326] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 1th superblock
[   11.569220] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[   11.576506] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 2th superblock
[   11.584265] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[   11.591503] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 1th superblock
[   11.599185] F2FS-fs (mmcblk0p1): Magic Mismatch, valid(0xf2f52010) - read(0x0)
[   11.606436] F2FS-fs (mmcblk0p1): Can't find valid F2FS filesystem in 2th superblock

And this:

[   13.096862] ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x3c.
[   13.105165] pci 0000:00:02.0: enabling device (0140 -> 0142)
[   13.111080] ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[   13.344913] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/fwcfg-pci-0000:02:00.0.txt failed with error -2
[   13.355506] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.461310] firmware ath10k!fwcfg-pci-0000:02:00.0.txt: firmware_loading_store: map pages failed
[   13.470261] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:02:00.0.bin failed with error -2
[   13.481004] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.491541] firmware ath10k!pre-cal-pci-0000:02:00.0.bin: firmware_loading_store: map pages failed
[   13.500701] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/cal-pci-0000:02:00.0.bin failed with error -2
[   13.511092] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.521282] firmware ath10k!cal-pci-0000:02:00.0.bin: firmware_loading_store: map pages failed
[   13.530080] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/ct-firmware-5.bin failed with error -2
[   13.541075] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.551216] firmware ath10k!QCA988X!hw2.0!ct-firmware-5.bin: firmware_loading_store: map pages failed
[   13.560560] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/ct-firmware-2.bin failed with error -2
[   13.571555] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.581677] firmware ath10k!QCA988X!hw2.0!ct-firmware-2.bin: firmware_loading_store: map pages failed
[   13.591035] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-6.bin failed with error -2
[   13.601769] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.611906] firmware ath10k!QCA988X!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed
[   13.620998] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-5.bin failed with error -2
[   13.631732] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.641826] firmware ath10k!QCA988X!hw2.0!firmware-5.bin: firmware_loading_store: map pages failed
[   13.650921] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-4.bin failed with error -2
[   13.661654] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.671748] firmware ath10k!QCA988X!hw2.0!firmware-4.bin: firmware_loading_store: map pages failed
[   13.680839] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/firmware-3.bin failed with error -2
[   13.691572] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.701700] firmware ath10k!QCA988X!hw2.0!firmware-3.bin: firmware_loading_store: map pages failed
[   13.711513] ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
[   13.720776] ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[   13.730122] ath10k_pci 0000:02:00.0: firmware ver 10.1-ct-8x-__fW-022-b0e1b7cd api 2 features wmi-10.x,has-wmi-mgmt-tx,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 1e527180
[   13.782144] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[   13.792618] ath10k_pci 0000:02:00.0: Falling back to user helper
[   13.803001] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[   13.815202] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[   14.729472] ath10k_pci 0000:02:00.0: 10.1 wmi init: vdevs: 16  peers: 127  tid: 256
[   14.746600] ath10k_pci 0000:02:00.0: wmi print 'P 128 V 8 T 410'
[   14.752707] ath10k_pci 0000:02:00.0: wmi print 'msdu-desc: 1424  sw-crypt: 0 ct-sta: 0'
[   14.760732] ath10k_pci 0000:02:00.0: wmi print 'alloc rem: 20904 iram: 26056'
[   14.826611] ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 2 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
[   14.839121] ath10k_pci 0000:02:00.0: NOTE:  Firmware DBGLOG output disabled in debug_mask: 0x10000000

And in the logread:

Sun Jan 12 20:48:01 2020 user.notice SQM: Starting SQM script: piece_of_cake.qos on eth2, in: 95000 Kbps, out: 95000 Kbps
Sun Jan 12 20:48:01 2020 user.notice SQM: Using generic sqm_start_default function.
Sun Jan 12 20:48:02 2020 user.notice SQM: ERROR: cmd_wrapper: ip: FAILURE (2): /sbin/ip link add name ifb4eth2 type ifb
Sun Jan 12 20:48:02 2020 user.notice SQM: ERROR: cmd_wrapper: ip: LAST ERROR: ip: RTNETLINK answers: File exists
Sun Jan 12 20:48:02 2020 user.notice SQM: piece_of_cake.qos was started on eth2 successfully

But as I say all seems to work. The VLAN troubles continue, I need investigate more about wpa3 and iPhone. And probably I will need open another thread about bird2.

Unless the filesystem of the mmcblk0p1 partition is indeed F2FS (Flash-Friendly File System) it can be neglected. For some reason the check happens automatically for eMMC devices even if a different file system is actually deployed.


There could be different causes, e.g. LAN vs WLAN. Cannot find it but also recall something about sluggish reverse DNS lookups and changing the DNS resolver sorted that.

1 Like

https://wiki.debian.org/InstallingDebianOn/TurrisOmnia#Bootloader_update

1 Like

What are those troubles? Trunk ports (tagged) for CPU upstream port eth2 can be done with

config interface 'wan'
	option ifname 'eth2.x'

Where X = VLAN ID

And similar trunk ports on the switch's downstream ports lan0-4, e.g.

ifname 'lan4.x'