Nach langer Zeit gibt es mal wieder eine neue »stable« Firmware.
Nach dem Durchlaufen der »experimental«- und »testing«-Stufen wurde heute die Version 1.2.0~56 als »stable« freigegeben. Der Rollout im Netz läuft also nun.
Die vorige »stable«-Version war 1.1.5~41 vom Januar 2021 und basierte auf Gluon 2018.2; die aktuelle basiert auf Gluon 2019.1, siehe Release-Notes:
Release Notes for gluon-4830-1.2.0~56
========================================
This Freifunk Firmware is based on Gluon v2018.1.4 (1.0.x)
or v2018.2 (1.1.x; as of 2020-01-10 based on v2018.2.4) or
v2019.1 (1.2.x; as of 2021-04-06 based on v2019.1.3) and
includes some additional modules.
Oft angekündigt, wird auch diese Version vermutlich nicht die letzte sein, die 4/32-Geräte wie den TP-Link WR-841N/ND unterstützt; die aktuelle Gluon-Basis 2021.1 unterstützt diese Geräte noch, weshalb auch wir, sollten wir den Zwischenschritt machen, die Unterstützung nicht auslaufen lassen werden.
Dennoch der dringende Appell, sich um zeitnahen Ersatz jener Gerätschaften zu kümmern.
Moin.
Auf unserer Karte wird zurzeit nur die Firmware 1.1.5~41 als genutzt angezeigt. Ich vermute mal, dass die Knoten, die Offline angezeigt werden, in Wirklichkeit mit der neuen Firmware arbeiten.Sie können sich nur mit dem Map-Server ihre Daten nicht austauschen.
Beispiel hier: 17192-offloader-6061 http://[2001:bf7:170:192:219:99ff:febc:6061]/cgi-bin/status
Wo ist da gerade der Wurm?
Jain. Über map.4830.org werden IIRC auch die Statusdateien für freifunk-karte.de usw. ausgespielt, am »IIRC« siehst Du das Problem: »man« müßte da einmal draufkucken (ggf. Logfiles) und dann das umziehen auf map03.
Letzteres wird aus Ansible konfiguriert — daher gibt’s auch eine kleine Karten-Inflation, newmap.4830.org, map03.4830.org, map04.4830.org, map-bi.4830.org, … — Fluch und Segen der Automation Und »newmap« wollte ich nicht kaputt machen, aber stimmt, wenn wir den Namen schon eingeführt haben, ist das ein simpler CNAME und gut, oder?
Da meine 4040 das Update nicht selbst bezogen hat, habe ich den branch von tng auf stable umgestellt. Auch nach einigen Stunden hat sich noch nichts getan. Also manuell anwerfen:
~# autoupdater
Retrieving manifest from http://firmware.ipv6.4830.org/stable/sysupgrade/stable.manifest ...
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found
Ist das wieder ein IPV6 Problem? Wobei ich für V4 auch keine Auflösung bekomme. Von meinem Rechner aus lässt sich die Liste herunterladen.
Das muß so, .ipvX. hat nur vX-Eintràge. firmware.4830.org mit v4 & v6 machte um 2015/2016 Probleme, daher die getrennten Einträge.
Ja, vermutlich. Überlege noch, wie smokeping von den einzelnen Mesh-IPs aus umsetzbar ist; so heißt es, in site-Repository zu gucken, welche GWs welches Mesh beackern, dann auf jedes GW einloggen und traceroute -s 2001:bf7:$meshnet:$mesh::$id firmware.ipv6.4830.org machen … sowie im Nichterfolgsfalle von dort den Rückweg prüfen. Zeitaufwendig und auf Admins beschränkt
root@web01:~# traceroute -m 10 2001:bf7:1310:128::4
traceroute to 2001:bf7:1310:128::4 (2001:bf7:1310:128::4), 10 hops max, 80 byte packets
1 2a06:e881:1700:1:6267:7032:2020:2020 (2a06:e881:1700:1:6267:7032:2020:2020) 0.427 ms 0.371 ms 0.333 ms
2 2a06:e881:1705:a101::2 (2a06:e881:1705:a101::2) 12.302 ms 12.283 ms 12.194 ms
3 2a06:e881:1702:1:400:c1ff:fe1a:787d (2a06:e881:1702:1:400:c1ff:fe1a:787d) 12.435 ms 12.438 ms 12.400 ms
4 2a06:e881:1702:1:400:c1ff:fe1a:787d (2a06:e881:1702:1:400:c1ff:fe1a:787d) 2111.360 ms !H 2111.385 ms !H 2111.337 ms !H
root@web01:~# ssh -A 2a06:e881:1702:1:400:c1ff:fe1a:787d uname -a
Linux l2tp-ham01 5.4.0-58-generic #64~18.04.1-Ubuntu SMP Wed Dec 9 17:11:11 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
1310:128 ist IIRC Mesh 01, also GWs raussuchen und Server-IDs:
Genau, lieber keine Verbindung als eine Verbindingung. Sucht noch mal nach einer zugreifbaren ICBM, um diesen Security-Nazis mal zu zeigen, was eine Harke ist. ARGH!
Ernsthaft jetzt, RSA ist nun auch, nach DSA, deprecated? Das wird ja richtig toll funktionieren im Automotive-Sektor, wo unupdatable gear 30+ Jahre funktionieren muß … Gut, daß ich generell nichts update … spart mir weitere Herzkasper
IIRC kann der sshd von OpenWrt (dropbear) bislang nix anderes als RSA (und DSA), jedenfalls keine EC-basierten Schlüssel/Methoden? Und wahrscheinlich wird das auch nicht rückportiert werden, d. h. um auf die Knoten zu kommen braucht es für wenigstens die nächste halbe Dekade noch einen SSH-Clienten, der mit RSA klarkommt: Gibt’s schon Pläne, DSA und RSA komplett zu entfernen?
eigentlich nur heißen. der Knoten hatte keine Verbindung ins Mesh, und damit keine v6-Routen.
Irgendwas ist da merkwürdig mit Smokeping. Alle aktuellen Gateways haben nun einen Block Updateserver_per_Mesh, der eigentlich von verschiedenen IPs aus testen sollte — aber lt. Graph gibt es das Problem nicht, welches man auf der Kommandozeile aber durchaus sehen kann
root@l2tp-fra01 ~ # for i in " " "-s 2001:bf7:1310:128::a" "-s 2001:bf7:1310:160::a" "-s 2001:bf7:1310:176::a" "-s 2001:bf7:1310:144::a" "-s 2001:bf7:170:192::a" "-s 2001:bf7:170:64::a" ; do from="$(echo $i|sed -e 's/-s //g')" ; if [ "$i" = " " ]; then from="default" ; else from="from $from" ; fi ; echo "$from" ; fping6 -q -c 5 $(echo $i | sed -e 's/-s/-S/g') firmware.ipv6.4830.org ; echo ; done
default
firmware.ipv6.4830.org : xmt/rcv/%loss = 5/5/0%, min/avg/max = 5.13/5.20/5.31
from 2001:bf7:1310:128::a
firmware.ipv6.4830.org : xmt/rcv/%loss = 5/0/100%
from 2001:bf7:1310:160::a
firmware.ipv6.4830.org : xmt/rcv/%loss = 5/5/0%, min/avg/max = 12.6/13.1/13.6
from 2001:bf7:1310:176::a
firmware.ipv6.4830.org : xmt/rcv/%loss = 5/5/0%, min/avg/max = 12.5/15.7/28.0
from 2001:bf7:1310:144::a
firmware.ipv6.4830.org : xmt/rcv/%loss = 5/5/0%, min/avg/max = 12.8/15.8/26.4
from 2001:bf7:170:192::a
firmware.ipv6.4830.org : xmt/rcv/%loss = 5/5/0%, min/avg/max = 5.37/6.78/11.8
from 2001:bf7:170:64::a
firmware.ipv6.4830.org : xmt/rcv/%loss = 5/0/100%
root@33332-SCE-Guetersloh:~# autoupdater -f
Retrieving manifest from http://firmware.ipv6.4830.org/stable/sysupgrade/stable.manifest ...
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found
root@33332-SCE-Guetersloh:~# traceroute firmware.ipv6.4830.org
traceroute to firmware.ipv6.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e216), 30 hops max, 64 byte packets
1 2001:bf7:1310:128::a (2001:bf7:1310:128::a) 36.042 ms 38.904 ms 37.251 ms
2 * * *
3^C
root@33332-SCE-Guetersloh:~# ip -6 route show
fd91:dab6:a2b2:1::/64 dev br-wan metric 256
fd91:dab6:a2b2:1::/64 via fe80::b6a5:efff:fe09:ef98 dev br-wan metric 512
default via fe80::b6a5:efff:fe09:ef98 dev br-wan metric 512
unreachable default dev lo metric 65535 error -148
unreachable default dev lo metric -1 error -128
2001:bf7:1310:128::/64 dev br-client metric 256
fd10:ca1:1::1 dev local-node metric 256
fd10:ca1:1::/64 dev br-client metric 256
fd10:ca1:1::/64 dev br-client metric 1024
unreachable fd73:8bc9:7371::/48 dev lo metric 2147483647 error -148
fe80::/64 dev local-node metric 256
fe80::/64 dev br-client metric 256
fe80::/64 dev bat0 metric 256
fe80::/64 dev br-wan metric 256
fe80::/64 dev primary0 metric 256
fe80::/64 dev client0 metric 256
fe80::/64 dev mesh0 metric 256
fe80::/64 dev mesh-vpn metric 256
default via fe80::f0be:efff:fe00:110 dev br-client metric 512
unreachable default dev lo metric -1 error -128
ff00::/8 dev local-node metric 256
ff00::/8 dev br-client metric 256
ff00::/8 dev bat0 metric 256
ff00::/8 dev br-wan metric 256
ff00::/8 dev primary0 metric 256
ff00::/8 dev client0 metric 256
ff00::/8 dev mesh0 metric 256
ff00::/8 dev mesh-vpn metric 256
unreachable default dev lo metric -1 error -128
root@33332-SCE-Guetersloh:~#
Und »newmap« wollte ich nicht kaputt machen, aber stimmt, wenn wir den Namen schon eingeführt haben, ist das ein simpler CNAME und gut, oder?
