Hmm. Bitte parallel checken, ob – insbesondere bei TNG –, das Netz generell tut. Also mit Handy rein und z. B. mal v6.de ansurfen: funktionieren beide IP-Versionen?
v6.de geht über TNG. Speedtest App meldet Plusserver anstelle von Kai.
root@33332-Buschkoettersweg-63-2dbc:~# autoupdater
Retrieving manifest from http://firmware.ipv6.4830.org/stable/sysupgrade/stable.manifest ...
No new firmware available.
Der 841 kann über seine direkte Verbindung prüfen. Ist dann classic Freifunk.
Ich guck’s mir gleich Mal von Unterfranken aus an …
root@l2tp-gut01 ~ # ps -Aelf | grep -i dhc
0 S root 19493 19424 0 80 0 - 3518 pipe_w 17:53 pts/0 00:00:00 grep -i dhc
root@l2tp-gut01 ~ # systemctl restart isc-dhcp-server
root@l2tp-gut01 ~ # ps -Aelf | grep -i dhc
4 S dhcpd 19496 1 4 80 0 - 12493 poll_s 17:53 ? 00:00:00 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
0 S root 19502 19424 0 80 0 - 3518 pipe_w 17:53 pts/0 00:00:00 grep -i dhc
Also sterbende isc-dhcpd sind wohl ein generelles Problem 
Ein anderes ist wohl v6:
root@97270-Am-Rosengarten-f24d:~# traceroute google.com
traceroute to google.com (2a00:1450:4001:81e::200e), 30 hops max, 64 byte packets
1 2001:bf7:1310:666::5 (2001:bf7:1310:666::5) 63.575 ms 67.880 ms 73.106 ms
2 * * *
3 * * *
4 *
root@l2tp-gut01 ~ # traceroute -m 5 -6 -s 2001:bf7:1310:666::5 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 5 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
root@l2tp-gut01 ~ # traceroute -m 5 -6 -s 2001:bf7:1310:128::5 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 5 hops max, 80 byte packets
1 2001:bf7:1310:128::a (2001:bf7:1310:128::a) 19.260 ms 19.279 ms 19.207 ms
2 * * *
3 * * *
4 * * *
5 * * *
root@l2tp-gut01 ~ # traceroute -m 5 -6 -s 2001:bf7:1310:176::5 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 5 hops max, 80 byte packets
1 2001:bf7:1310:176::a (2001:bf7:1310:176::a) 42.408 ms 42.390 ms 42.347 ms
2 * * *
3 * * *
4 * * *
5 * * *
Da muß ich dann wohl heute abend 'bei …
Yepp, v6 ist broken …
… zumindest bei zzz. Ich werde die L2TP-Gateways wohl mal komplett neu machen auf Basis der aktuellen Ansible-Rollen.
Edit: Legacy tut aber 
Mit rawhide (1.1.2~54) ist heute Nacht ein Testknoten nach tng (1.1.5~37) migriert.
@Echo, @Thomas, @m.bitterlich und alle anderen, die am TNG-Test teilnahmen, bitte nochmals einen Offline-Test von rawhide nach tng testen. Insbesondere scheinen an der Müritz/Feldberg keine TNG-Knoten (mehr) aktiv zu sein?
Ablauf:
-
Testnoten auf aktuelle rawhide-FW bringen (ab 1.1.2~54), downgraden, falls notwendig (ssh-Zugang einrichten nicht vergessen, beim Downgrade die alte Konfiguration nicht übernehmen!)
-
Testknoten auf ‘tng’-Zweig zwingen:
root@17258-FW-Test-4830-b9d0:~# sed -e "s/option branch .*$/option branch 'tng'/g" -i /etc/config/autoupdater -
Testknoten im WLAN isolieren und neu starten:
root@17258-FW-Test-4830-b9d0:~# sed -e 's/:de:ca:fb:/:f0:0b:a3:/g' -i /etc/config/wireless root@17258-FW-Test-4830-b9d0:~# reboot -
Sofern vorhanden, WAN-Verbindung des Testknotens jetzt kappen
Plan ist derzeit, zum Sonntag rawhide durchzupromoten bis stable, um dann um den Jahrewechsel den Schwenk auf eine TNG-Firmware (via rawhide => experimental => testing => stable) zu vollziehen.
(Falls jemand helfen möchte: das Blog ist nach einem Update von WP und Plugins – alles via Dashboard – im A…imer, es wird nix mehr zu Twitter oder ins Discourse verlinkt. (Genau wegen so einem Mist mache ich Updates normalerweise nur unter vorgehalter, scharfer Waffe und unter enervierendem Protest.) Thus: Any help appreciated.)
33378-a42bb0f43a87
von testing auf rawhide
autoupdater -f
über WAN Link (hat IPv6 genutzt)
r300e
downgrade auf rawhide
firstboot
Netzbasierte Lokalisierung -> OK
SSH Key hinzugefügt
Anschließend auf Wizward und dort weiter gemacht
sed -i -e ‘s/KreisGT.freifunk.net/test-KreisGT.freifunk.net/g’ /etc/config/wireless
wifi reload
Um sicht nicht mit meinem Offloader Probleme zu bekommen
root@33378-test-300e:~# sed -i -e ‘s/KreisGT.freifunk.net/test-KreisGT.freifunk.net/g’ /etc/config/wireless
root@33378-test-300e:~# wifi reload
root@33378-test-300e:~# grep -i ssid /etc/config/wireless
option ssid ‘test-KreisGT.freifunk.net’
root@33378-test-300e:~#
root@33378-test-300e:~# sed -e “s/option branch .*$/option branch ‘tng’/g” -i /etc/config/autoupdater
root@33378-test-300e:~# uci get autoupdater.settings.branch
tng
root@33378-test-300e:~# uci commit autoupdater
Verbindung gekappt
Warten … 
Die Isolation ist ja jetzt gegeben durch die Unterschiedlichen Versionen. So wird es in der Realität dann ja auch sein. Mal schauen wie es morgen aussieht.
1 „Gefällt mir“
Entweder war ich jetzt zu langsam mit dem Kabel raus ziehen. Oder der AP war danach schnell mit dem Update.
…
Ich werde ihn noch einmal zurücksetzen
EDIT:
Fehler gefunden, mein Hauptknoten war noch nicht auf TNG, deshalb hatte er ein Mesh aufgebaut.
Test läuft bei mir also weiter.
Test läuft…
Unter welcher URL sollte die Karte aktuell erreichbar sein?
20:50h - Test gestartet
20:55h - FF_Offline
nächster Tag - immer noch Offline, aber 1.1.5-38 installiert
Sag Bescheid, wann du Zeit hast, mich da ranzulassen, dann schaue ich mal, was da kaputt gegangen ist. Kenne das Plugin nicht, das solche Cross-Postings macht, aber gucken kann ich ja mal
Zeitvorschläge: Samstag 13-16 Uhr, Sonntag 16-19 Uhr, Montag 13-19 Uhr… Sag Bescheid wanns bei dir passt.
Das ist übrigens ein relevanter Punkt: bei »Schwenk auf eine TNG-Firmware« wird eine tng-FW mit Standard-SSID gebaut werden und dann in allen Autoupdater-Zweigen ausgerollt. Sprich: DANACH ist die l2tp-SSID Geschichte, bitte achtet darauf bei Euren Installationen 
Legacy (fastd, batman compatibility level 14): https://map.4830.org/ffgt bzw. https://map.4830.org/mueritz
TNG (l2tp, batman compatibility level 15): https://map03.4830.org/
Bei mir sieht alles gut aus. mein 300e hat sich heute Nacht aktualisiert.
Ich werde jetzt noch meinen 841 resetten und die Testing Firmware installieren. Werde ihn dann auf vom Autoupdater auf experimental stellen um dann evtl. Fehler im weiteren Update Prozess zu erkennen. (Ohne Mesh und Kabel). Das werde ich wenn ich die möglichkeit habe auch noch mit einem zweiten 841 machen.
Die Karten funktionieren bei mir leider alle nicht. Bei den ersten beiden bekomme ich ein ERR_SSL_PROTOCOL_ERROR und beim letzten TypeError: Cannot read property 'forEach' of null
Firefox meldet SSL_ERROR_RX_RECORD_TOO_LONG
Update: whoot ? Ohne s eingegeben leitet mich irgndwie weiter so das es doch tut.
@wusel Es ist aber auch zu erwarten das sich am Offline nichts ändert denke ich. D.h. wenn ohne Mesh ein Update auf TNG erfolgt ist, war der Test erfolgreich.
Äh, sorry, Legacy => natürlich ohne SSL: http://map.4830.org/ffgt bzw. http://map.4830.org/mueritz …
Legacy/handgeklöppelt => too lazy for that.
Ja; im Normalfall sind dann die VPN-Knoten schon auf TNG und es würde gemesht und der Knoten käme online.
Das ist quasi das Szenario, was @Thomas testet, Mesh-Knoten im Legacy-Netz künstlich separieren (Achtung, Ausgangsfirmware muß eine der letzten zwei rawhides sein, damit Offline-Upgrade tut), kommt der nach Offline-Upgrade automagisch wieder zurück ins Mesh? Testet u. a., ob die WLAN-Parameter der neuen Firmware korrekt installiert werden.
1 „Gefällt mir“
moin!
habe heute zum testen auch nochmal einen knoten auf den tng branch umgestellt.
(versuch 1: einfaches wechseln des branch + autoupdater
2: firstboot
3: image runtergeladen und mit sysupgrade -n eingespielt)
verbindungsaufbau zum gateway tut aber offensichtlich nich
OS: 18.06-SNAPSHOT, r7945+26-83ce31d FW: 1.1.5~38
HW: Ubiquiti UniFi-AC-MESH
root@17258-Gutshof:~# batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-9, MainIF/MAC: primary0/c2:2c:2b:63:da:9b (bat0/78:8a:20:70:67:85 BATMAN_IV)]
Router ( TQ) Next Hop [outgoingIf] Bandwidth
root@17258-Gutshof:~# ping heise.de
ping: bad address 'heise.de'
root@17258-Gutshof:~# cat /etc/resolv.conf
search lan
nameserver 127.0.0.1
root@17258-Gutshof:~# cat /tmp/resolv.conf
search lan
nameserver 127.0.0.1
root@17258-Gutshof:~# cat /tmp/resolv.conf.auto
# Interface wan
# Interface wan6
scheitert es evtl an der auflösung der gateway ips? tunneldigger läuft
2673 root 1552 S /usr/sbin/hostapd -s -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
3082 root 1048 S /usr/bin/tunneldigger -u 788a20706785 -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10006 -b l2tp-gut01.4830.org:10006 -b l2tp-gut02.4830.org:10006 -b l2tp-ham01.4830.o
3085 nobody 1020 S /usr/bin/tunneldigger -u 788a20706785 -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10006 -b l2tp-gut01.4830.org:10006 -b l2tp-gut02.4830.org:10006 -b l2tp-ham01.4830.o
3086 nobody 1020 S /usr/bin/tunneldigger -u 788a20706785 -i mesh-vpn -t 1 -b l2tp-ber01.4830.org:10006 -b l2tp-gut01.4830.org:10006 -b l2tp-gut02.4830.org:10006 -b l2tp-ham01.4830.o
3259 root 1200 R ps
test mit 1.1.1.1 als ergänzung in der resolv.conf löst dann zumindest die domain in der konsole korrekt auf, aber der tunnel will trotzdem nicht --also doch dns wohl doch nicht das problem?
tunneldigger = {
brokers = {
'l2tp-ber01.4830.org:10006',
'l2tp-gut01.4830.org:10006',
'l2tp-gut02.4830.org:10006',
'l2tp-ham01.4830.org:10006',
'l2tp-ham02.4830.org:10006',
'l2tp-fra01.4830.org:10006',
'l2tp-ams01.4830.org:10006',
},
},
Errrrm … *Nach Loch im Boden ausschau haltend* Äh, …
Also: die Meshes 05 (Müritz) und 06 (Feldberg) sind bis heute Nacht nicht auf den oben gelisteten Gateways konfiguriert gewesen. Die sind ist im Zuge der verschiedenen Umkonfigurationen der letzten Monate in Ansible auf gw-fra01a und gw-fra01b gewandert, aber die FW-Einträge wurden einerseits nicht nachgezogen, andererseits wurde das konkrete Setup auch erstmal aus Komplexitätsgründen fallen gelassen — und die Einstellungen wurden nicht zurückübernommen. Sorry for that 
Ist nun auf l2tp-ber01 und l2tp-fra01 konfiguriert, auf l2tp-ber01 sehe ich auch eine Verbindung im Feldberg-Mesh:
root@l2tp-ber01 ~ # brctl show
bridge name bridge id STP enabled interfaces
br05 8000.02caffee0504 no
br06 8000.02caffee0604 no l2tp1024-1024
br96 8000.02caffee9604 no
Und nun isser auch auf der Karte, der Knoten:
https://newmap.4830.org/map06/#!v:m;n:788a20706785
Sorry nochmal
Ab hier wird’s eher technisch, weiterlesen am besten nur für technisch Interessierte
Nicht alle in der FW vorgesehenen Gateways haben immer alle Meshes aktiviert. Denn für jedes Mesh brauchen wir erst einmal einen v4-Pool, i. d. R. ein /20 oder /21 (~4100 bzw. ~2000 IPv4-Adressen), der dann durch die geplante Anzahl der (L2TP-) Gateways zu teilen ist, um die Adressranges für die IPv4-DHCP-Server zu konfigurieren.
Um mit dem Zusammenschluß ›aller‹ Freifunk-Netze, dem IC-VPN, kompatibel zu bleiben, verwenden wir im L2TP-Setup Adressen aus dem Bereich 10.234.0.0/15, die wir im dortigen Vergabesystem seinerzeit reservierten.
Die initialen Adressen für Gütersloh (10.255.0.0/16) und die Müritz-Region (10.169.0.0/16) planen wir zurück- und damit freizugeben, wenn sie nicht mehr benötigt werden.
Auch wenn ein /15, immerhin über 130.000 IPv4-Adressen, viel erscheint, sind es doch »nur« 32 /20 bzw. 64 /21, die man daraus ›schnitzen‹ kann.
Warum 2000 oder gar 4000 Adressen für ein Mesh? Nun, zu Spitzenzeiten hatte FFGT schon über 1000 Endgeräte im Mesh; seinerzeit arbeiteten wir aber noch mit einem zentralen, singulären DHCP-Server. Das vereinfachte Setup nutzt einen DHCP-Server je Gateway, sodaß wir je Gateway ca. soviele IPv4-Adressen vorhalten müssten, wie wir im Mesh maximal erwarten. Denn Geräte verbinden sich mit dem Freifunk-Netz, wenn sie es empfangen und werden aus dem Funkbereich des Freifunk-Netzes wortwörtlich herausgetragen — sprich: sie melden sich nicht ab. Für die Dauer der (von uns eingestellten) Gültigkeitsdauer der Adresszuteilung bleibt jene im DHCP-Server belegt — egal, ob der Client noch in Reichweite ist oder nicht. Zu kurze DHCP-Gültigkeiten führen zu Problemen bei der Nutzung, zu lange zu Adressknappheit auf dem jeweiligen Gateway — und spätere Änderungen der Adresszuteilungen je Mesh sind adminstrativ ›schmerzhaft‹.
Da wir im neuen Setup auf 2, 4 oder noch mehr Gateways je Mesh setzen, die Verteilung der Knoten auf die Gateways eher zufällig ist und teilweise auch große Installationen existieren (Rathäuser, Bibliotheken, Einkaufsmärkte und neu Impfzentren), sollten ca. 1000 IPs/Gateway verfügbar sein. (Müritz/Feldberg jeweils z. Zt. die Hälfte.)
Mit derzeit 7 Gateways in der Firmware (die auf 7 verschiedenen Servern in 5 verschiedenen Standorten aufschlügen) sollten wir erst einmal soweit gerüstet sein. Sprich: über Änderungen im »Backend« (Umzug einzelner Meshes zwischen den Servern) sollten wir Last und Traffic hinreichend gut steuern können, ohne neue Firmware bauen zu müssen.
Bzgl. gw-ORT##X: gw-fra01a lief auf unserem Server in FRA, gw-fra01b auf dem Server von Freifunk Lippe in FRA. Die Grundidee wäre, daß jeweils die Hälfte der eigenen VMs bei der Partnercommunity läuft und dies wechselseitig, wenn man, wie z. B. wir und Lippe in FRA und BER, Server (Hypervisor) im gleichen Rack/beim gleichen Colo-Anbieter/am gleichen IX hat. Ranzt dann ein HV einer Community ab, wäre nur die Hälfte der eigenen (Gateway-) VMs betroffen, die anderen liefen einfach bei der anderen Community weiter. Da das aber komplexer ist, als es erstmal klingt, ist das auf ›später‹ verschoben.
Hallo,
den ersten Knoten 17192-mff-da7a habe ich gerade mit “Gewalt” auf TNG aktualisiert. Beim Zweiten habe ich den Branch umgeschrieben und das Wlan isoliert (wie von @wusel vorgeschlagen).
In Funkreichweite von “mff” ist noch ein dritter Knoten. Hier wurden keine Änderungen bisher vorgenommen.
Bin nun gespannt, wann Knoten Nr 2 sich aktualisiert.
Gruß,
Mike
mögliche fehler finden und funktion testen war doch das ziel des aufrufs danke fürs schnelle nachtragen der fw rules/+xxx. knoten läuft.
für den test des “offline” umschwenkens kram ich nachher noch einen router aus der kiste.