OpenWrt 21.02.1 is coming into HBL branch

Thanks for the keyword U-Boot, I knew I read it somewhere.

wrong

Still it is missing in official documentation and should be added.

2 Likes
1 Like

Seems the SDIO-module is not working anymore on TOS 6:

Apr 11 13:40:45 AP_OG1 kernel: [  937.284750] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0xb1 error, result=0x1
Apr 11 13:40:45 AP_OG1 kernel: [  937.291952] mwifiex_sdio mmc0:0001:1: Failed to start the BSS
Apr 11 13:40:45 AP_OG1 kernel: [  937.298028] mwifiex_sdio mmc0:0001:1: Failed to start AP

I’ve created issue: MOX SDIO not working on TOS 6 (HBL) (#33) · Issues · Turris / diagnostics · GitLab.

2 Likes

Please let SDIO in TOS 6 functional again.

could it be it only fails in 2,4 GHz? when I set the sdio card to 5 GHz , the logs read as follows:

[ 13.004599] mwifiex_sdio mmc0:0001:1: WLAN FW is active
[ 13.074854] mwifiex_sdio mmc0:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (16.68.1.p197)
[ 13.083215] mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0 (16.68.1.p197)
[ 19.424922] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x20 error, result=0x1
[ 36.226355] mwifiex_sdio mmc0:0001:1: 11h: issuing DFS Radar check for channel=108
[ 100.593383] mwifiex_sdio mmc0:0001:1: CAC timer finished; No radar detected

Both, actually.

  1. I kept hass.io in a LXC container, which runs docker inside it.
  2. I moved everything else into docker natively on TurrisOS.

I remember i had some networking problems for containers that were not using host networking and I never found time to dig into it. Curious to know if you figured it out.

Do you need logs or something as assistance? It’s happening on both TO and both MOX I am operating on TOS6.

1 Like

I do appreciate such kindness and offering to help, but right now, no. If something changes, we will reach you.

Yes I did figure it out. Actually I used the solution provided here
Not sure though of this is the best solution.

root@turris:~# cat /etc/docker/daemon.json
{
    "dns": ["8.8.8.8", "8.8.4.4"]
}

I have the same, so I guess the problem I’ve having isn’t the same.

Is anyone having problems updating the 6.x branch? I’m stuck on the libwebsockets package.

OK, so updater just got broken for me as well, but different error:

root@turris ~# pkgupdate
INFO:Target Turris OS: 6.0
line not found
line not found
line not found
line not found
line not found
ERROR:
inconsistent: Requested package zoneinfo-poles that is not available.

A post was merged into an existing topic: TurrisOS 6.x pkgupdate stuck on libwebsockets-full vs libwebsockets-openssl

Thanks for reporting. Missing this package was encountered on Saturday’s build. Since you are running the HBL branch, it is suggested to be used by experienced users as there are daily builds. A few occasional bugs might appear. The missing package appeared later that day as I triggered new builds for all routers. It is always a good idea to mention on which router it happens.

Yes, I ‘fixed’ that by adding all zoneinfo-* packages to Uninstall in updater conf.d file. It has the positive effect that all log messages now use a single (UTC) timezone as opposed to mix of UTC and my native (CZ) timezone, so I’m keeping it that way even if it is fixed (though setting router timezone to UTC should fix that as well, of course).

I am a rather experienced user, but to be completely honest, the reason I switched to HBL is mainly because you have removed switch features (VLAN-related config, usage of both CPU ports - even though it’s only port-mapped, not aggregated, and it doesn’t even work correctly right now) that were present in 3.x versions and 6.x is the first version that partially brings them back. Unfortunately, even vanilla OpenWRT is in pretty bad shape for Turris Omnia, so there is really no good choice for me right now, looking forward to see the DSA issues fixed soon.

2 Likes

I deactivated updater for now - I do not see any sense, why python3 or base-files (those are at least the ones that are most often named) need to be updated 2-3 times per day.
I’ll every now and then have a look into the linked issue to see when I can activate it again.

Seems, this is close to be sorted out, so I will activate updater again. Thank you, Turris team :+1: :slight_smile:

I just updated to alpha3, and rainbow is broken.

rainbow all red auto
Failed to open file: No such file or directory

used strace to debug

open("/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/omnia-led:all/color", O_WRONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
writev(2, [{iov_base="Failed to open file: No such fil"..., iov_len=47}, {iov_base=NULL, iov_len=0}], 2Failed to open file: No such file or directory
) = 47

looks like the paths have changed

# ls -R /sys/devices/platform/soc/soc\:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds
/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds:
rgb:indicator-1  rgb:lan-0        rgb:lan-2        rgb:lan-4        rgb:wan          rgb:wlan-2
rgb:indicator-2  rgb:lan-1        rgb:lan-3        rgb:power        rgb:wlan-1       rgb:wlan-3

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:indicator-1:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:indicator-2:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:lan-0:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:lan-1:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:lan-2:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:lan-3:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:lan-4:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:power:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:wan:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:wlan-1:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:wlan-2:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

/sys/devices/platform/soc/soc:internal-regs/f1011000.i2c/i2c-0/i2c-1/1-002b/leds/rgb:wlan-3:
brightness       max_brightness   multi_intensity  trigger
device           multi_index      subsystem        uevent

Well, to be more precise, rainbow does not support the new LED driver, which was upstreamed and is part of the Linux kernel. Currently, LEDs are exposed to userspace, as you correctly found. I admit working rainbow is nice to have, but for the dev branch, you mostly want to have a working Internet connection and other things. This is just a small thing, which is not critical :slight_smile:

Anyway, @mvasilek is working on this one!

3 Likes

I was simply reporting, not complaining. :slight_smile:

2 Likes