I am not running any containers at all…
and RAM usage is very stable too…
I wonder why foris-controller uses so much CPU time though…
and RAM usage is very stable too…
@miska → is this a problem that banip expects different firewall on Turris 7 and we don’t have it there yet?
Ok, if I understand correctly firewall4 is not implemented now in turris and is targeted for 7.1. Which is fine, in the meanwhile I remember we had to do similar in the past. I tried to install older packages for openwrt 21 and it seems to be working.
Downloaded:
banip_0.7.11-3_all.ipk
luci-app-banip_git-21.165.16952-467b853_all.ipk
luci-i18n-banip-cs_git-23.090.62029-650e6d2_all.ipk
luci-i18n-banip-en_git-23.090.62029-650e6d2_all.ipk
From: Index of /releases/21.02.7/packages/arm_cortex-a7/
(luci + packages).
Installed with opkg install *.ipk (in the dir where you downloaded).
Enabled banip in luci (system → startup) and restarted → seems to be working now as the report is stating it gets new hits.
2 Likes
In the same boat here.
Would be great if anyone from the Turris team would comment on this, since I don’t want to mess up a perfectly running installation of Turris OS 7.0
Hi Forum,
still having issues - WiFi, Luci getting inaccessible after a bit more than 48 hours.
Firefox
TypeError
boardinfo.release is undefined
Error
XHR request timed out
IE
TypeError
Cannot read properties of undefined (reading ‘description’)
cleared cache, tried IE and Firefox, nothing works except restart. I can connect thourgh SSH and diagnostic took a really long time… sent it to tech.support@ hope they can detangle those hickups.
Seems that connection to WiFi Card stopped - in my case AsiaRF AW7916-NPD.
Thanks for help.
Hi @mazhead,
yes it is not implemented, because FW4 is based on nftables. :-/ But we are testing FW4 for now.
3 Likes
In which branch, please? Is the hbd branch on OpenWrt snapshot level or based on 23.05 and usable for testing again?
Thanks for testing this and finding a temporary solution!
I wouldn’t even have noticed banIP is missing without this thread.
The Foris updater has some hiccups doing it this way (tries to either remove or update the banip packages), which I solved with an additional config file:
/etc/updater/conf.d/banip.lua
Repository('turris-652-packages', 'https://repo.turris.cz/archive/6.5.2/omnia/packages/packages', {
priority = 40,
ocsp = false,
pubkey = "file:///etc/updater/keys/release.pub"
})
Repository('turris-652-luci', 'https://repo.turris.cz/archive/6.5.2/omnia/packages/luci', {
priority = 40,
ocsp = false,
pubkey = "file:///etc/updater/keys/release.pub"
})
Install("banip", {repository = {'turris-652-packages'}})
Install("luci-app-banip", {repository = {'turris-652-luci'}})
Install("luci-i18n-banip-en", {repository = {'turris-652-luci'}})
Install("luci-i18n-banip-de", {repository = {'turris-652-luci'}})
This makes the updater want to reinstall these versions once, but afterwards it stays silent and happy on the fixed versions. But I’d probably expect a bad surprise when FW4 comes at some point and I forget to remove the config again beforehand 
4 Likes
For now just locally, but when it will be actual it will be in hbk and I will let you know. 
1 Like
Thanks! This works great for vpn-policy-routing (and luci-app-vpn-policy-routing) as well.
could you please post your file for this. I am lookong for a solution for vpn policy routing too ?
Just copy the script and replace the package names with the ones you need. This is what works for me (/etc/updater/conf.d/vpn-policy-routing.lua):
Repository('turris-652-packages', 'https://repo.turris.cz/archive/6.5.2/omnia/packages/packages', {
priority = 40,
ocsp = false,
pubkey = "file:///etc/updater/keys/release.pub"
})
Repository('turris-652-luci', 'https://repo.turris.cz/archive/6.5.2/omnia/packages/luci', {
priority = 40,
ocsp = false,
pubkey = "file:///etc/updater/keys/release.pub"
})
Install("vpn-policy-routing", {repository = {'turris-652-packages'}})
Install("luci-app-vpn-policy-routing", {repository = {'turris-652-luci'}})
Run pkgupdate to apply.
1 Like
Today my turris did crash and hang, no DHCP, no data, but it did not reboot, the watchdog was seemingly being kept alive…
May 3 15:09:45 turris ddns-scripts[8422]: ipv4ddns: Rerun IP check at 2024-05-03 17:09
May 3 15:09:45 turris ddns-scripts[8423]: ipv6ddns: Rerun IP check at 2024-05-03 17:09
May 3 15:09:57 turris perd[2675]: USER root pid 0 cmd condmv -A "RESULT 9901 ongoing" /home/atlas/data/new/main /home/atlas/data/out/main
May 3 15:10:01 turris crond[16966]: (root) CMD (/usr/bin/notifier)
May 3 15:10:01 turris crond[16965]: (root) CMDOUT (There is no message to send.)
May 3 15:10:01 turris crond[16965]: (root) CMDEND (/usr/bin/notifier)
May 3 21:01:45 turris syslog-ng[4276]: syslog-ng starting up; version='4.6.0'
I have connected an ESP32 to the UART and would be able to log the data from there, but so far the port is quiet unless I echo something to /dev/ttyS0
what would I have to do to enable “logging” to the serial port?
[22:00:15][D][uart_debug:158]: <<< "[ 1340.128725] ICMPv6: process `sysctl\' is using deprecated sysctl (syscall) net.ipv6.neigh.br-Guardaed.base_reachable_time - use net.ipv6.neigh.br-Gu"
[22:00:15][D][uart_debug:158]: <<< "ardaed.base_reachable_time_ms instead\r\n"
maybe it’s working already… we will see…
yeah I see kernel messages and even uboot now 
[22:10:32][D][uart_debug:158]: <<< "board SerDes lanes topology details:\r\n"
[22:10:32][D][uart_debug:158]: <<< " | Lane # | Speed | Type |\r\n"
[22:10:32][D][uart_debug:158]: <<< " --------------------------------\r\n"
[22:10:32][D][uart_debug:158]: <<< " | 0 | 6 | SATA0\t|\r\n"
[22:10:32][D][uart_debug:158]: <<< " | 1 | 5 | USB3 HOST0\t|\r\n"
[22:10:32][D][uart_debug:158]: <<< " | 2 | 5 | PCIe1\t|\r\n"
[22:10:32][D][uart_debug:158]: <<< " | 3 | 5 | USB3 HOST1\t|\r\n"
[22:10:32][D][uart_debug:158]: <<< " | 4 | 5 | PCIe2\t|\r\n"
[22:10:32][D][uart_debug:158]: <<< " | 5 | 0 | SGMII2\t|\r\n"
[22:10:32][D][uart_debug:158]: <<< " --------------------------------\r\n"
it’s a bit rough, but it’ll do for now…
Thank you very much, unfortunately it fails because of some other reason. I’m wondering why it’s so complicated to find an actual reason, what does [string “backend”]:1226: [string “backend”]:278 mean (
DBG:backend.lua:394 (status_parse):Parsing status file /usr/lib/opkg/status
DBG:src/lib/locks.c:82 (lua_lock_release):Released lock at /var/lock/opkg.lock
line not found
ERROR:src/pkgupdate/main.c:151 (main):
[string "backend"]:1226: [string "backend"]:278: attempt to concatenate local 'pkg_name' (a nil value)
There further seems to be an issue with sentinel - not shure why there is a wrong time stamp in
May 5 17:40:42 L* sentinel-dynfw-client[2063]: 2024-05-05 19:40:42,899 - WARNING - Unable to renew certificate (another try after 8 sec): [Errno -3] Try again
May 5 19:40:49 L* sentinel: INFO [certgen.action_spec_init:89] Valid certificate found
May 5 17:40:55 L* sentinel-dynfw-client[2063]: 2024-05-05 19:40:55,949 - WARNING - Unable to renew certificate (another try after 16 sec): [Errno -3] Try again
May 5 17:41:16 L* sentinel-dynfw-client[2063]: 2024-05-05 19:41:16,999 - WARNING - Unable to renew certificate (another try after 32 sec): [Errno -3] Try again
May 5 17:41:54 L* sentinel-dynfw-client[2063]: 2024-05-05 19:41:54,189 - WARNING - Unable to renew certificate (another try after 64 sec): [Errno -3] Try again
wrong timestamp also effects other plugins - might be that 2 hours difference come from UTC+2 = MESZ but than it is UTC+4 becouse of wrong addition or implementation.
May 5 19:41:48 L* dnsmasq-dhcp[4708]: read /etc/ethers - 0 addresses
May 5 19:43:17 L* dnsmasq[4708]: now checking DNSSEC signature timestamps
May 5 19:43:17 L* dnsmasq-dhcp[4708]: read /etc/ethers - 0 addresses
Thanks to developers and forum,
Vienna
I can confirm, that there is a bug with updater in Turris MOX (as stated first by @bakuka in Opkg in stable 7.0.0 uses hbl instead of hbs):
Downloading https://repo.turris.cz/hbl/mox/packages/core/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_core
Downloading https://repo.turris.cz/hbl/mox/packages/core/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/base/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_base
Downloading https://repo.turris.cz/hbl/mox/packages/base/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/cesnet/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_cesnet
Downloading https://repo.turris.cz/hbl/mox/packages/cesnet/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_luci
Downloading https://repo.turris.cz/hbl/mox/packages/luci/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/node/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_node
Downloading https://repo.turris.cz/hbl/mox/packages/node/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_packages
Downloading https://repo.turris.cz/hbl/mox/packages/packages/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_routing
Downloading https://repo.turris.cz/hbl/mox/packages/routing/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_telephony
Downloading https://repo.turris.cz/hbl/mox/packages/telephony/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/mox/packages/turrispackages/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_turrispackages
Downloading https://repo.turris.cz/hbl/mox/packages/turrispackages/Packages.sig
Signature check failed.
Remove wrong Signature file.
As can be seen above wrong repo is used for packages: https://repo.turris.cz/hbl/mox/
Seems this needs to get fixed with next version @TomasZak
Hi,
sorry to ask - is banIP needed in order for Adblocking Plugin and Sentinel to work?
Thx,
Vienna
Hi @ssdnvv,
thanks for the info. I noticed it on this weekend, when I reinstalled my MOX. We will look at it. As temp. solution what worked for me was reinstall all packages with:
pkgupdate --reinstall-all
2 Likes
Yeah, I have also seen those wonky timestamps from dnsmasq and other stuff…
Hi @kai,
could your investigation on SIDO SDIO WiFi crashing kernel on Turris OS 7.0 (#431) · Issues · Turris / Turris OS / Turris Build · GitLab from Turris OS 7.0 is in rc! - #12 by Stepan_Dalecky could also effect my AsiaRF AW7916-NPD not recognised - Crash after installing - #2 by Vienna
Thx,
Vienna