Thanks for the keyword U-Boot, I knew I read it somewhere.
wrong
Still it is missing in official documentation and should be added.
Thanks for the keyword U-Boot, I knew I read it somewhere.
Still it is missing in official documentation and should be added.
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.
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.
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.
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.
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
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
Anyway, @mvasilek is working on this one!
I was simply reporting, not complaining.