No, that’s not normal, but it is happening these days.
TL; DR: to use Turris RTSFP-10G, activate the SFP module via SSH: ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot on older u-boot versions.
former text
I today received my Turris RTSFP-10G and inserted it directly in one of my TO’s SFP cage but nothing happened.
I rebooted and still no connection.
root@AP_EG_1:~# logread | grep sfp
root@AP_EG_1:~#
I then digged a little bit deeper and found that in TOS 4.0b you had to manually activate the SFP module via ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot. I did so and voilà:
root@AP_EG_1:~# logread | grep sfp
Apr 7 23:41:47 AP_EG_1 kernel: [ 9.734858] sfp sfp: Host maximum power 3.0W
Apr 7 23:41:47 AP_EG_1 kernel: [ 10.069434] sfp sfp: module Turris RTSFP-10G rev A sn 2109150023 dc 210915
Apr 7 23:42:07 AP_EG_1 kernel: [ 46.262911] mv88x3310 i2c:sfp:11: Firmware version 0.2.8.0
Apr 7 23:42:08 AP_EG_1 kernel: [ 46.960751] mv88x3310 i2c:sfp:11: selected MAC type: 4
Apr 7 23:42:09 AP_EG_1 kernel: [ 47.542922] mvneta f1034000.ethernet eth2: PHY [i2c:sfp:11] driver [mv88x3310] (irq=POLL)
root@AP_EG_1:~#
@Pepe: Is this expected behavior? If yes, this command should be somewhere in official documentation, because both my TO and the Turris RTSFP-10G are supported hardware, right? Or is this just broken atm in 6.0 due to beta status?
edit: For another TO, which is still running on 5.3.6, I also had to activate the SFP with the command above. So this seems to be broken in all branches atm?
This is expected behavior for Omnias without new u-boot.
1 Like
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.
- I kept hass.io in a LXC container, which runs docker inside it.
- 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 
