OpenWrt 21.02.1 is coming into HBL branch

inconsistent: Requested package sentinel-fwlogs that is not available.

We know. :frowning: We are working on fix.

1 Like

An update this morning solves everything.
zarizeni

Any idea why the updater doesn’t start automatically? For a few days now, I have in my logo after the autostart:

turris updater-supervisor: Traceback (most recent call last):
    File "/ usr / bin / updater-supervisor", line 33, in <module>
     sys.exit (load_entry_point ('svupdater == 1.5.1', 'console_scripts', 'updater-supervisor') ())
    File "/usr/lib/python3.9/site-packages/svupdater/__main__.py", line 87, in main
  AttributeError: 'NoneType' object has no attribute 'next_window'

also my netmeter starts automatically even if the automatic measurement is switched off.

1 Like

Already reported to us. The fix is currently on review.

1 Like

Today’s update fixes this issue.

Any advice on how to stop the netmeter from starting automatically.
In the settings, autorun is disabled and still starts.

Upgraded my MOX A(SDIO)B(WLE1216v5-20) and PAB(WLE1216v5-20) to HBL and TOSv6 without issues that far. Wi-Fi is working now (QCA9984 Cascade Series WiFi card and Wi-Fi card WLE1216V5 does not work with Turris MOX (#332) · Issues · Turris / Turris OS / Turris Build · GitLab).

1 Like

Is it normal for HBL to update daily even without my permission?

@ackstorm23 are you running docker inside the LXC container only, or you also run docker on TOS 6?
I tried to do so on TOS 6, but I get name resolution errors when trying to build:

WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0xb55df070>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution')': /simple/requests/
ERROR: Could not find a version that satisfies the requirement requests (from versions: none)
ERROR: No matching distribution found for requests
The command '/bin/sh -c pip install requests pytz backoff psycopg2-binary' returned a non-zero code: 1

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.

  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.