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.
Hallo,
der besagte Knoten scheint erfolgreich sich aktualisiert zu haben und hat sich mit dem anderen Knoten verbunden.
Den Zusatz “l2tp” in der SSID habe ich manuell entfernt. Nicht das die Gäste sich zu sehr irritiert fühlen. 
Er wird sicherlich beim nächsten Update wieder rein kommen, oder? Zumindest solange die tests noch laufen. Richtig?
Gruß und einen schönen Abend.
Hmmja, schon, aber … Schon ein peinlicher Fehler
Danke!
Yepp, würde ich auch so sehen: vorher, nachher
Yepp:
Vielen Dank für Eure Tests!
Ich werde mit der aktuellen rawhide noch mal einen Installationsvorgang durchspielen, sie danach dann nach experimental und testing, nach 2 Tagen dann stable schieben. IMHO ist sie mehr als »gut genug« als Ausgangsfirmware für den anstehenden Wechsel auf L2TP und ein aktuelles, weiterentwickeltes Batman-Advanced.
Kurzum: wer noch Bugs in oder Probleme mit der Firmware hat/kennt, JETZT wäre ein guter Zeitpunkt, das, ggf. nochmal, vorzubringen
Sorry, war wohl nicht sauber formuliert meinerseits: die Idee ist, jemand guckt sich das, mit full access, an und fixt es optimalerweise — also alleine (oder mit welchem Telefonjoker außer mir auch immer)
Es sind ja mehrere Plugins borked; Discourse poster nimmer ins Forum, Twitter nicht mehr auf … Twitter sowie das FB-Plugin nicht mehr ins Fratzenbuch.
Ich werde nachher mal einen Umzug auf 'ne andere VM vornehmen, auf ein neueres WP, hoffentlich löst das die Probleme …
Kannst du einmal in das Legacy Netz schauen. Aktuell geht v4 nicht raus. Traceroute bleibt bei 10.255.128.23 hängen. Ich weiß nichtob das mit den aktuellen umstrukturierungen zusammen hängt. (EDIT: Seit heute morgen kurz vor sechs)
1 „Gefällt mir“
Good catch, siehe http://legacy-mon.4830.org/status.html:
Problem zw. DUS und BER:
root@de6:~# traceroute 192.251.226.180
traceroute to 192.251.226.180 (192.251.226.180), 30 hops max, 60 byte packets
1 130.255.76.1 (130.255.76.1) 164.913 ms 164.893 ms 164.828 ms
2 bg1.dus2.de.as29141.net (5.45.181.211) 0.385 ms 0.365 ms 0.338 ms
3 bg1.ams1.nl.as29141.net (5.45.181.213) 4.184 ms 4.163 ms 4.126 ms
4 ae11-30.cr1.dus6.plusserver.com (80.249.214.89) 14.296 ms 14.267 ms 14.240 ms
5 bgp-gut01.4830.org (193.26.120.82) 13.936 ms 13.896 ms 14.072 ms
6 bgp-gut01.4830.org (193.26.120.82) 2675.985 ms !H 2675.893 ms !H 2675.937 ms !H
Äh, oder auch nicht:
root@legacy-ber01 ~ # birdc6 show route export upstream
Unable to connect to server control socket (/run/bird/bird6.ctl): No such file or directory
root@legacy-ber01 ~ # birdc show route export upstream
Unable to connect to server control socket (/run/bird/bird.ctl): No such file or directory
root@legacy-ber01 ~ # bird --version
BIRD version 1.6.3
=> Der Routingdaemon auf dem Gateway in BER läuft nicht (zu alte Version), somit wird die Route zur Exit-IP 192.251.226.180/32 nicht im internen Netz per OSPF propagiert, somit weiß der Router in DUS (bgp-gut01) nicht, wohin damit.
Einmal die aktualisierte Gateway-Rolle auf dam GW ausgerollt:
root@aux01:~/deploy_ffgt_20200714/ffgt-ansible# ansible-playbook -vv -i hosts gateways.yml --limit legacy-ber01
Und:
root@legacy-ber01 ~ # bird --version
BIRD version 1.6.8
root@de6:~# traceroute 192.251.226.180
traceroute to 192.251.226.180 (192.251.226.180), 30 hops max, 60 byte packets
1 130.255.76.1 (130.255.76.1) 0.923 ms 1.011 ms 1.000 ms
2 bg1.dus2.de.as29141.net (5.45.181.211) 0.403 ms 0.375 ms 0.347 ms
3 bg1.ams1.nl.as29141.net (5.45.181.213) 4.337 ms 4.303 ms 4.282 ms
4 ae11-30.cr1.dus6.plusserver.com (80.249.214.89) 14.590 ms 14.552 ms 14.528 ms
5 bgp-gut01.4830.org (193.26.120.82) 14.499 ms 14.420 ms 14.411 ms
6 bgp-ber01.4830.org (193.26.120.86) 21.117 ms 20.977 ms 20.952 ms
7 192.251.226.180 (192.251.226.180) 20.879 ms 21.504 ms 20.583 ms
1 „Gefällt mir“
@wusel
Sollen wir / ich noch einmal ein Szenario testen?
Aktuell laufen beide Netze Stabil, willst du den Schwenk zum Jahreswechsel noch einleiten?
Mein geplanter Ablauf:
- Beitrag im Blog (hängt wegen WP-Desaster)
- Statistiken funktionieren (hängt an Ansibilisierung von yanic — den collectd-Kram verstehe ich nicht)
- rawhide -> stable
- Statistiken gucken
- tng -> experimental, testing
- tng -> stable
wollte @MichaelKliewe da nich etwas helfen?
Sonst würde ich mich auch anbieten.
@wusel schrieb oben:
Ich würde mir das Wordpress nach wie vor angucken wollen, aber ich brauche halt Zugriff per SSH und Wordpress-Admin denke ich, um Logs einzusehen etc. Die Logs sind vermutlich nur hilfreich, wenn sie so weit zurückreichen wie der letzte fehlgeschlagene Versuch.
Eine der ersten Fragen wäre vermutlich: Wie kann/darf ich das testen, ohne Schrott auf den jeweiligen Plattformen zu posten? Gäbe es ein sinnvolles Posting, mit dem man testet, oder müsste man (sprich: Jemand mit Zugriff) die Posts nach dem Test wieder entfernen von den Zielplattformen?
2 Beiträge wurden in ein existierendes Thema veschoben: Update/fix Blog/Webseite