Für alle RSK-Hoods ist eine neue stable-3.14.0 Firmware in Arbeit:
Patches:
-
respondd
-
iwfull für die RSK-Pakete
-
Support gl-inet mifi
Neue v2025.1.x_configs für die einzelnen Hoods, mit geändertem Community tunneldigger und site-Änderung.
3 „Gefällt mir“
Die neue stable-3.140.0 liegt jetzt auf dem Updateserver.
Das soll heißen »jetzt mit Community-Tunneldigger-Package« oder habt Ihr an jenem Package Änderungen vorgenommen?
von master repo beim tunneldigger auf main repo beim community tunneldigger gewechselt. Guckst Du modules in der site-dir 
2 „Gefällt mir“
stable.3.14.1 liegt jetzt auf dem Update-Server zum Download, nachdem bei der vorigen Version einige targets nicht gebaut wurden. Dazu noch Paketabhängigkeit vom tunneldigger watchdog angepasst und Support für unifi-6-lr-v2 und unifi-6-lr-v3 hinzugefügt.
Mir fiel gerade auf, daß wir den in v2025.1 noch nicht drin hatten — beim Blick in Eure Version fiel mir dann aber auf, daß unser TD kein PID-File schreibt, der Check also fehlschlägt:
root@59581-FW-Test-a823:~# cat /lib/gluon/gluon-version
v2025.1+
root@59581-FW-Test-a823:~# cat /var/run/tunneldigger.mesh-vpn.pid
cat: can't open '/var/run/tunneldigger.mesh-vpn.pid': No such file or directory
root@59581-FW-Test-a823:~# pgrep tunneldigger | head -n 1
3334
Tut das wirklich bei Euch?
Erm, ff-mesh-vpn-tunneldigger kommt mit eigenem /usr/bin/tunneldigger-watchdog:
* check_data_file_clashes: Package gluon-tunneldigger-watchdog wants to install file /home/ffgt/build/gluon-4830-v2025.1/site-4830/gluon-build/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/target-dir-744c5022/usr/bin/tunneldigger-watchdog
But that file is already provided by package * ff-mesh-vpn-tunneldigger
* check_data_file_clashes: Package gluon-tunneldigger-watchdog wants to install file /home/ffgt/build/gluon-4830-v2025.1/site-4830/gluon-build/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/target-dir-744c5022/usr/lib/micron.d/tunneldigger-watchdog
But that file is already provided by package * ff-mesh-vpn-tunneldigger
* opkg_install_cmd: Cannot install package gluon-tunneldigger-watchdog.
That said, die image-customization.lua referenziert gluon-tunneldigger-watchdog auch gar nicht 
bei der 3.14.1 habe ich die Abhängigkeiten aktualisiert auf ff-mesh-vpn-tunneldigger. vorher hat der watchdog noch auf mesh-vpn-tunneldigger referenziert.
Hatte mit den builds bei den fehlenden targets selbst schon genug Focus, dass ich darauf nicht mehr geschaut habe. Das Ergebnis funktionierte aber bislang bei allen Einwahl- und Traffic-Tests.
Auch im Dauerbetrieb: Testbetrieb auf node
Was unnötig ist, denn ff-mesh-tunneldigger hat, wie gesagt, einen eigenen Watchdog an Bord (und Du das Watchdog-Package ja gar nicht mitbaust). Eine Abhängigkeit weniger
1 „Gefällt mir“
der separate watchdog ist ja auch gar nicht in image-customization.lua drin
genauso wenig, wie im gluon 2015.1 die u6-lr v2 und v3 als target
existieren - aber sie sind halt reingepatcht und laufen: genauso wie der gl-mifi.
stable 3.14.1 für die Hood Lohmar Innenstadt für den Rollout signiert.
1 „Gefällt mir“
Rollout für alle anderen alle RSK-Hoods gestartet.
2 „Gefällt mir“
und Überraschung - die er-x machen kein sysupgrade:
upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.1->2.0).
upgrade: Partition table has been changed due to kernel size restrictions. Refer to the wiki page for instructions to migrate to the new layout: https://openwrt.org/toh/ubiquiti/edgerouter_x_er-x_ka
Image check failed.
autoupdater: warning: sysupgrade --test failed with return code: 1
Die ubiquity er-x lassen sich momentan nur LOKAL mit HandsOn migrieren, denn nach dem Durchlauf der upgrade-scripte kommt die node im setup-mode wieder hoch.
HOWTO:
die shellscripte aus https://github.com/darkxst/erx-migration/tree/main in /tmp herunterladen.
danach chmod +x auf die beiden.
Dann das aktuelle sysupgrade image mit wget in /tmp herunterladen. mit ln -s gluon-xxx-sysupgrade-image sysupgrade.img die Firmware lokal bereitstellen (sonst holt er sich openwrt images).
Zu diesem Zeitpunkt sieht die Partitionierung noch so aus:
root@Rathaus-1:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 „u-boot“
mtd1: 00060000 00020000 „u-boot-env“
mtd2: 00060000 00020000 „factory“
mtd3: 00300000 00020000 „kernel1“
mtd4: 00300000 00020000 „kernel2“
mtd5: 0f7c0000 00020000 „ubi“
mit ./ubnt_erx_migrate.sh das Upgrade starten und das Upgrade bestätigen.
nach dem reboot hat sich die Partitionierung geändert auf:
root@tdf-erx-fimwaretest:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 „u-boot“
mtd1: 00060000 00020000 „u-boot-env“
mtd2: 00060000 00020000 „factory“
mtd3: 00600000 00020000 „kernel“
mtd4: 0f7c0000 00020000 „ubi“
leider kommt die node dann im setup-mode unkonfiguriert wieder hoch.
Nach der Neukonfiguration kann die Node dann wieder an den Start gehen:
1 „Gefällt mir“