Offline von stable zu rawhide/tng (Vorbereitung fastd -> L2TP)

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 :grimacing:

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 :frowning:


Ab hier wird’s eher technisch, weiterlesen am besten nur für technisch Interessierte :wink:

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 :slight_smile: 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. :slight_smile:
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 :wink:

Danke!

Yepp, würde ich auch so sehen: vorher, nachher :wink:

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 :wink:

It’s running …

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) :slight_smile:

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 …

@wusel

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:

  1. Beitrag im Blog (hängt wegen WP-Desaster)
  2. Statistiken funktionieren (hängt an Ansibilisierung von yanic — den collectd-Kram verstehe ich nicht)
  3. rawhide -> stable
  4. Statistiken gucken
  5. tng -> experimental, testing
  6. 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

Ich zieh’ die Antworten bzgl. Blog/Wordpress mal in den neuen Thread, sorry.

Fragen hierzu:

  1. Soll es dabei bleiben, daß Facebook aus dem Blog gefüttert wird? Nutzt noch jemand FB (ich quasi nur noch genötigtenfalls oder zufällig; Twitter, Telegram, Instagram, für mehr ist keine Zeit) und könnte die Leute dort, die ggf. im FB-System antworten abholen?

  2. Mit Wordpress haben wir die Möglichkeit, daß Texte von mehreren vorab gelesen und redigiert werden können — für mindestens den Text zur Gründungsversammlung fände ich das ganz schick, wenn da noch ein, zwei andere Leute drübergucken würden. Volunteers? (Und ja, ist schon wieder spät dafür …)

Posten tut nun (wieder) nach:

(Verschiedene Plugins, aber kostenlos ist ja immer schwierig.)

Next Step: