Benutzer:PeterPhilipp: Unterschied zwischen den Versionen

Aktuelle Version vom 27. August 2023, 08:52 Uhr

Ich war von 2014-2018 aktiv. Dann eine Pause. Ich will 2021 wieder aktiv werden.

Meine Kontakt mail ist: freifunk [at] delphinusdns [dot] org

Good to knows

Ein Backup Gateway auf OpenBSD basis

Ich hab ein halbes dutzend Hobbies, und viele basieren rund um dem Betriebssystem OpenBSD. OpenBSD ist jetzt in der version 6.9. Um 6.8 rum bekam es wireguard support. Rola und ich haben versucht eine cloud instanz von mir bei Hetzner die OpenBSD ist umzubauen das es ein backup gateway werden kann. Was wir jetzt haben ist eine test-loesung. Wir hatten drei oder vier reibungspunkte wo wir nicht sicher waren das OpenBSD diese erfüllen konnten.

GRE tunnel (muss kompatibel zu Linux sein)
Babeld muss funktionieren auf OpenBSD (wir benutzten 1.10 version)
wireguard um den FFF Router einen tunnel zu geben
ip tables oder kompatibel. Wir benutzten rdomain(4).

Mehr hierzu ein wenig spaeter (fuer die details):

Bei mir ging es nicht

Ende Juni 2021, hab ich beschlossen das gateway abzubauen. Für ungefähr 1-2 wochen ging der gateway nicht mehr. Die routen haben sich alle auf blackhole routen umgestellt auf die schnittstelle lo5. Ich weiss nicht was ich da tun soll, restart vom babeld hat nicht geholfen. Vielleicht war die technologie noch nicht ausgereift für BSD. Es lief die meiste Zeit von mitte Mai bis ende Juni also 6 wochen.

OpenBSD

Ich benutzte OpenBSD 6.9 mit patch 001 auf dem system. Der VPS steht bei Hetzner Online in Nürnberg.

rdomains

Ein rdomain ist ein routing tree in einem routing forest von wo es bis zu 254 routing trees (auch tables genannt) im OpenBSD system gibt. rdomain 0 ist die default route auf dem VPS und kann nicht für FFF benutzt werden. Ich habe rdomain 5 benutzt da ich andere netzwerke schon auf 3 und 4 hatte (1 und 2 hab ich garnicht benutzt). Ein route tree in seinem rdomain ist isoliert auf diesem rdomain und wenn die rdomains nicht durch drivers oder dem pf firewall system verbunden werden kommt nichts auf rdomain 0 oder anderen rdomains raus. Das ist so wie die fff routing table geschichte mit den Linux systemen.

wireguard konfigurieren

Ich habe bisher nur ein wg (wg2) hier ist die /etc/hostname.wg2 datei (zensiert)

rdomain 5
wgport ZENSIERT wgkey ZENSIERT2 wgpeer ZENSIERT3 wgaip ::/0 wgaip 0.0.0.0/0
inet6 fe80::1234:5678:90ab:cdef%wg2 64
inet 10.83.252.xxx/32
up

Hier musste ich die eui64 selber eintragen da in OpenBSD "inet6 eui64" einen fehler auf wg(4) macht.

Update: Leider kann man die gleiche IP Adresse nicht auf alle wg Schnittstellen tun. Ich hab das heute herausgefunden.. :-(, Kein problem ich hab mir ein /27 dafür reserviert im FFF Netz (Portal:Netz#10.50.186.96.2F27_.28PeterPhilipp.29)... Ich hoffe das ist OK.

GRE konfigurieren mit pf trick

Von meiner /etc/hostname.gre0 datei:

rdomain 5
inet6 eui64
inet 10.83.252.xxx/32
tunnel 2a01:ZENSIERT1 2a01:ZENSIERT2
up

Dieses konfiguriert den GRE tunnel, aber wenn pf auf dem system ist (wird immer da sein bei default) muss man IPv6 Destination Options durchlassen und zwar ungefähr so:

anchor "gre" {
       pass in on vio0 inet6 proto 47 from 2a01:ZENSIERT1 to 2a01:ZENSIERT2 allow-opts
       pass out on vio0 inet6 proto 47 from 2a01:ZENSIERT2 to 2a01:ZENSIERT1 allow-opts
}

Siehe das "allow-opts" das ist benötigt da Linux GRE ein extra header im IPv6 reinfügt. Im IPv4 modus hab ich's nie ausprobiert obwohl Rola es bereit gemacht hat. Der debug für diese allow-opts hat mich einige Stunden zurückgesetzt, aber am ende hab ichs gefunden. Es ist erwähnt im pf.conf(5) manual page.

Die lo5 Schnittstelle

Wird angelegt sobald eine rdomain 5 schnittstelle angelegt wird. Ich habe es dann doch konfiguriert in der datei /etc/hostname.lo5:

rdomain 5
inet 127.0.0.1/8
inet6 ::1/128
up

Wie jedes /etc/hostname.if kann man es gleich aktivieren mit

sh /etc/netstart lo5

Die anderen schnittstellen hab ich auch so (um)konfiguriert (sh /etc/netstart gre0 # z.B.)

babeld

Die änderungen die ich an babeld vollzogen habe sind hier https://github.com/pbug44/fff-obsd-babeld/commit/8b05ac09e0f31f903cf24100954024143c0568da.

Ich hab /etc/rc.local geändert das babeld automatisch nach boot gestartet wird:

# babeld
/sbin/route -T 5 exec /usr/local/sbin/babeld -D

Ich muss route benutzen um in den rdomain 5 zu gehen.

Die /etc/babeld.conf hab ich angepasst aus (hier raus: Freifunk-Gateway_aufsetzen/Babel) und sie sieht so aus:

# babeld config for openbsd
skip-kernel-setup true
default type tunnel max-rtt-penalty 128
interface gre0
interface lo5 type wired rxcost 4096
interface wg2
redistribute local ip 10.50.0.0/16
redistribute local ip 10.83.0.0/16
redistribute local ip fd43:5602:29bd::/48
redistribute local deny
redistribute ip 10.50.0.0/16
redistribute ip 10.83.0.0/16
redistribute ip fd43:5602:29bd::/48
local-port 33123
log-file /dev/null

Babel Routen im rdomain 5

Wenn babeld gestartet wird, muss sicher gemacht werden das keine statische routen existieren. Es ist alles Dynamisches routing. Hier zeigt die routen im rdomain 5 auf OpenBSD:

job# netstat -nr -T 5 | wc -l
   2110
job# netstat -nrfinet6 -T5 | wc -l
   1261
job# netstat -nrfinet -T5 | wc -l
    850

Gute 2K routes das babeld eingeführt hat, eine babel route hat eine '2' flagge angehängt.

Der Test Router

Der test router heisst zrd01 und steht in Schweinfurt. https://monitoring.freifunk-franken.de/routers/17104

Vielen Dank!

Vielen Dank an Robert (rola) der sehr sehr viel geduld mit mir hatte. Wir haben einen Babel gateway aufgesetzt erst für Privat und dann als Backup für die FFF Region Schweinfurt vielleicht? Mal sehen, der nächste Schritt ist die Community zu fragen ob sie Robert ablöst damit ein echt redundantes Netzwerk entsteht. Ich werde die ML bald anfragen.

TODO

IPSEC für den GRE vielleicht. Feedback aus der Community wird auch helfen.

Administration von Knoten

Ich administriere gerade einen Knoten (bei meinen Eltern). Wegen Stromsparmassnamen habe ich 3 geräte Zuhause ausgestellt (ich spare somit 17 Watt), mein Freifunk Knoten zuhause war sowieso nicht populär. Vielleicht bringe ich es zurück in der (fernen) Zukunft.

Anfang Herbst 2022 wird der Knoten zrd01 (bei meinen Eltern) auch für die Winter Saison 2022/2023 abgeschaltet. Das ist nicht schlimm da der Knoten keine teilnehmer für monate hatte. Aber ich stehe da ohne Knoten administrierung bis März. Leider muss das sein.

Im Frühling 2023 hab ich beschlossen doch nicht wieder anzufangen mit dem knoten bei mir und meinen Eltern, ich bin aber interessiert mit dem "GartenNetz" knoten (siehe unten). Strom ist teuer geworden.

Solar Batterie

Nicht jeder hat eine Südliche seite mit Balkon oder Fenster. Ich habe ein Westliches Fenster wo ich ein 100 Watt Solar panel reingetan habe. Es macht vielleicht 4-5 KWh im Jahr (!) Meistens um die Sonnenwende im Juni hat die 70 Ah Batterie (auto batterie) ein bissle zu viel ladung. Dann hänge ich geräte dran um es zu entladen (wenigsten bis auf 50%). Dieses Jahr, in 2021, habe ich 4 wochen Freifunk gehabt. Es war ein TP-LINK WR-1043v4 den ich rangehängt habe. Und da der Knoten ein wenig mehr zur Strasse stand haben sich warscheinlich Leute dafür interessiert die sonnst nicht in guter Reichweite sind. Aber das ist nur meine einschätzung. Gerade (26. September) lädt die Batterie und ist wieder auf 12V oder so, es wird warscheinlich bis April dauern wenn ich den Router wieder daranstellen kann.

Das Panel ist jetzt verkauft an einen anderen Freifunker, die Batterie hab ich noch und die steht zu katastrophen zeiten bereit (hoffentlich wird sie nie benutzt).

Ein Garten Netz Knoten

Ich bin dabei ein solar betriebenen repeater zu bauen der für Freifunk eingesetzt werden kann. Ich werde hieran noch einige Zeit brauchen bevor ich es erläutere.

Bisher hab ich für das Protokoll eine Idee: LEAPER https://sky.delphinusdns.org/eap-tls-idea.txt

Update (ende August 2023):

Ich hab wenig Zeit gehabt viel weiter zu machen. Ich hab drei ESP32 module gekauft weil sie billig waren aber hab gemerkt das das Microcontroller toolkit mich in eine lernkurve bringt die ich nicht weiter verfolgen will.

Aber da kommt immer neues aus China. Letzlich hab ich den Milk-V Duo gesehen der 64-bit RISC-V macht mit 64 MB RAM. Es kostet 9USD aber das WLAN modul ist extra. Warscheinlich so teuer wie die alten WR-841'er am ende. Ich will mal sehen ob ich da OpenBSD drauf laden kann, also diese Investition wird bald stattfinden vielleicht um Weihnachten. Vielleicht wird 2024 das Jahr wenn ich den "prototyp" fertig bekomme.

@@ Zeile 1: / Zeile 1: @@
-Hallo!
+Ich war von 2014-2018 aktiv.  Dann eine Pause.  Ich will 2021 wieder aktiv werden.
-Ich bin Peter Philipp aus [[Schweinfurt]].  Ich wirke mit bei Freifunk Franken schon seit ungefähr 2013/2014.  Ich betreibe den AREA52 knoten am Deutschhof.
+Meine Kontakt mail ist: freifunk [at] delphinusdns [dot] org
+== Good to knows ==
-== Treffen ==
+* [[FF-Router_am_Gastzugang_einer_Fritzbox]]
+* [[Unbricken_eines_TP-Link_1043ND]]
+* 841'er zurück zu stock [[FreifunkFranken_Firmware_zurück_zu_stock|hier]].
-=== Haßfurt ===
+== Ein Backup Gateway auf OpenBSD basis ==
-Alle 4-6 Monate erschein ich zum Treffen im Meehäusle in Haßfurt.  Es sind immer gute Zeiten.
+Ich hab ein halbes dutzend Hobbies, und viele basieren rund um dem Betriebssystem OpenBSD.  OpenBSD ist jetzt in der version 6.9.  Um 6.8 rum bekam es wireguard support.  Rola und ich haben versucht eine cloud instanz von mir bei Hetzner die OpenBSD ist umzubauen das es ein backup gateway werden kann.  Was wir jetzt haben ist eine test-loesung.  Wir hatten drei oder vier reibungspunkte wo wir nicht sicher waren das OpenBSD diese erfüllen konnten.
-=== Woanders ===
+* GRE tunnel (muss kompatibel zu Linux sein)
+* Babeld muss funktionieren auf OpenBSD (wir benutzten 1.10 version)
+* wireguard um den FFF Router einen tunnel zu geben
+* ip tables oder kompatibel.  Wir benutzten rdomain(4).
-Noch keine Zeit woanders zu erscheinen.  Vielleicht passiert was in 2018/2019.
+Mehr hierzu ein wenig spaeter (fuer die details):
-=== FFF Sommerfest 2017 ===
+=== Bei mir ging es nicht ===
-Hat mir sehr gut gefallen.  Vielleicht komm ich wieder in 2018.
+Ende Juni 2021, hab ich beschlossen das gateway abzubauen.  Für ungefähr 1-2 wochen ging der gateway nicht mehr.  Die routen haben sich alle auf blackhole routen umgestellt auf die schnittstelle lo5.  Ich weiss nicht was ich da tun soll, restart vom babeld hat nicht geholfen.  Vielleicht war die technologie noch nicht ausgereift für BSD.  Es lief die meiste Zeit von mitte Mai bis ende Juni also 6 wochen.
-== Projekte ==
+=== OpenBSD ===
-=== Hochhaus ===
+Ich benutzte OpenBSD 6.9 mit patch 001 auf dem system.  Der VPS steht bei Hetzner Online in Nürnberg.
-Das über Projekt währe natürlich ein richtfunk zwischen der Innenstadt zum Blauen Hochhaus und zum Deutschhof zu errichten.  Es ist sicherlich teuer und uns fehlen die Kontakte.  Es ist erst mal auf Eis gelegt.  Interressant ist zu wissen das Radio Primaton von hier aus sendet, also sind Kommerzielle anlagen erlaubt auf dem dach.
-Wenn ich bisschen fantasieren kann... auf dem dach des hochhauses wären 3 richtungen gut.
-* In richtung Innenstadt
+=== rdomains ===
-* In richtung Deutschhof
-* In richtung Haßfurt (Airport) das wäre der knüller!
-=== Am Deutschhof in Schweinfurt ===
+Ein rdomain ist ein routing tree in einem routing forest von wo es bis zu 254 routing trees (auch tables genannt) im OpenBSD system gibt.  rdomain 0 ist die default route auf dem VPS und kann nicht für FFF benutzt werden.  Ich habe rdomain 5 benutzt da ich andere netzwerke schon auf 3 und 4 hatte (1 und 2 hab ich garnicht benutzt).  Ein route tree in seinem rdomain ist isoliert auf diesem rdomain und wenn die rdomains nicht durch drivers oder dem pf firewall system verbunden werden kommt nichts auf rdomain 0 oder anderen rdomains raus.  Das ist so wie die fff routing table geschichte mit den Linux systemen.
-Bei meiner Wohnung sind ca. 50 Wohnungen in der nähe, ich habe jeden in 2016 einen Brief geschickt um jedem haus einen Freifunk Knoten zu geben damit wir meshen können und weiterstossen in das "Zentrum" vom Deutschhof was ein grosser platz ist mit Kirche, und mehreren Geschäften.  Leider war keiner interessiert.
-Reddog meinte das ich das nicht gut genug beschrieben habe und nicht gut genug die Kontakte geknüpft habe, was warscheinlich stimmt.
-=== Solar betriebener Router ===
-Ein Solar betriebener Router, mehr darüber unten.
-== Die private Telefonanlage ==
+=== wireguard konfigurieren ===
-=== Das Setup ===
+Ich habe bisher nur ein wg (wg2) hier ist die /etc/hostname.wg2 datei (zensiert)
-[[File: AREA27-SIP.png]]
+ rdomain 5
+ wgport ZENSIERT wgkey ZENSIERT2 wgpeer ZENSIERT3 wgaip ::/0 wgaip 0.0.0.0/0
+ inet6 fe80::1234:5678:90ab:cdef%wg2 64
+ inet 10.83.252.xxx/32
+ up
-Ich habe zwischen AREA27 und AREA52 ein Asterisk aufgespannt.  Ein APU1 router ist bei AREA27 der einen Asterisk läuft auf OpenBSD.  Auf der anderen Seite (AREA52) habe ich einen NUC der auch OpenBSD läuft und routing in mein Heim netz macht.  Das ganze ist ziemlich kompliziert gebaut mit den folgenden Technologien die auf OpenBSD zu finden sind:  iked (IPSEC), vxlan (layer 2 tunnel), gif (layer 3 tunnel), rdomain (alternativer routing table), bridge (layer 2 switch), Asterisk (VOIP software), pf (packet filter).
+Hier musste ich die eui64 selber eintragen da in OpenBSD "inet6 eui64" einen fehler auf wg(4) macht.
-Ein APU1 router mit 3 Ethernet Schnittstellen verkraften ungefähr 12 watt.  Der NUC den ich angab ungefähr gleich aber es ist ja sowieso an bei mir zuhause als IPSEC accelerator.
+Update:  Leider kann man die gleiche IP Adresse nicht auf alle wg Schnittstellen tun.  Ich hab das heute herausgefunden.. :-(,  Kein problem ich hab mir ein /27 dafür reserviert im FFF Netz ([[Portal:Netz#10.50.186.96.2F27_.28PeterPhilipp.29]])... Ich hoffe das ist OK.
-[[File: AREA27-bridge.jpg]]
+=== GRE konfigurieren mit pf trick ===
-Hier ein ping von AREA27 zu AREA52:
+Von meiner /etc/hostname.gre0 datei:
-  # ping -c 2 172.16.0.52
+  rdomain 5
-  PING 172.16.0.52 (172.16.0.52): 56 data bytes
+  inet6 eui64
-bytes from 172.16.0.52: icmp_seq=0 ttl=255 time=53.840 ms
+  inet 10.83.252.xxx/32
-bytes from 172.16.0.52: icmp_seq=1 ttl=255 time=53.740 ms
+  tunnel 2a01:ZENSIERT1 2a01:ZENSIERT2
-  --- 172.16.0.52 ping statistics ---
+  up
-packets transmitted, 2 packets received, 0.0% packet loss
- round-trip min/avg/max/std-dev = 53.740/53.790/53.840/0.050 ms
-Die Latenz ist erträglich.  Eigentlich alles unter 150 ms ist erträglich bei VOIP.
+Dieses konfiguriert den GRE tunnel, aber wenn pf auf dem system ist (wird immer da sein bei default) muss man IPv6 Destination Options durchlassen und zwar ungefähr so:
-Es ist warscheinlich die sicherste Telefon Leitung in der welt zwischen meinen Eltern und mir.
+ anchor "gre" {
+        pass in on vio0 inet6 proto 47 from 2a01:ZENSIERT1 to 2a01:ZENSIERT2 allow-opts
+        pass out on vio0 inet6 proto 47 from 2a01:ZENSIERT2 to 2a01:ZENSIERT1 allow-opts
+ }
-[[File: AREA27-841-typical.png]]
+Siehe das "allow-opts" das ist benötigt da Linux GRE ein extra header im IPv6 reinfügt.  Im IPv4 modus hab ich's nie ausprobiert obwohl Rola es bereit gemacht hat.  Der debug für diese allow-opts hat mich einige Stunden zurückgesetzt, aber am ende hab ichs gefunden.  Es ist erwähnt im pf.conf(5) manual page.
-Im Bild sieht man den typischen Verbrauch von Verkehr auf dem blauen Port des WR-841v10.  Man kann fast gar nicht erkennen wann ein Telefonanruf gemacht wurde aber im Bild sind bestimmt über zwei Anrufe.  Das Grundrauschen ist immer noch der grösste Faktor.
+=== Die lo5 Schnittstelle ===
-Um nicht grössere Verwirrung zu gestalten habe ich auch für AREA52 ein Netzwerk Plan, die wichtigen komponente die hier sind sind mercury das der NUC ist, venus das der router am Freifunk netzwerk hängt und gamma das der VDSL router ist.  Der rest ist in meinem Büro hinter uranus.
+Wird angelegt sobald eine rdomain 5 schnittstelle angelegt wird.  Ich habe es dann doch konfiguriert in der datei /etc/hostname.lo5:
-[[File: AREA52-networkmap.png]]
+ rdomain 5
+ inet 127.0.0.1/8
+ inet6 ::1/128
+ up
-Die ganz oben genannten technologien tunneln Freifunk und mein Netzwerk zusammen auf mercury.  Ja in meinem Wohnzimmer sind viele Kabel verlegt, geht nicht anders. :-).
+Wie jedes /etc/hostname.if kann man es gleich aktivieren mit
+ sh /etc/netstart lo5
-=== Fehler auf Schnittstelle re2 ===
+Die anderen schnittstellen hab ich auch so (um)konfiguriert (sh /etc/netstart gre0  # z.B.)
-Es ist durchaus möglich das AREA27 zu hacken versucht wurde.  Hier ein paar logs von der dmesg des OpenBSD switches:
+=== babeld ===
- Nov 30 21:02:36 area27 /bsd: arp: attempt to overwrite permanent entry for 192.168.178.39 by a4:db:30:d3:15:04 on re2
+Die änderungen die ich an babeld vollzogen habe sind hier https://github.com/pbug44/fff-obsd-babeld/commit/8b05ac09e0f31f903cf24100954024143c0568da.
- Nov 30 21:02:36 area27 /bsd: arp: attempt to overwrite permanent entry for 192.168.178.39 by a4:db:30:d3:15:04 on re2
-Eine andere erklärung ist das jemand 192.168.178.0/24 in das freifunk netz geleakt hat und hat genau die adresse dieses switches benutzt.
+Ich hab /etc/rc.local geändert das babeld automatisch nach boot gestartet wird:
-Auf dem switch ist re1 die schnittstelle mit 192.168.178.0/24 was zur Fritzbox geht.  Es verwundert mich doch sehr sowas zu sehen.  Hätte nie gedacht...
+  # babeld
+  /sbin/route -T 5 exec /usr/local/sbin/babeld -D
-Ein paar tage später wurde immer noch "spoofed" verkehr gemessen.   Hier von den anti-spoof filtern:
+Ich muss route benutzen um in den rdomain 5 zu gehen.
- @25 block drop in on ! re1 inet from 192.168.178.0/24 to any
+Die /etc/babeld.conf hab ich angepasst aus (hier raus: [[Freifunk-Gateway_aufsetzen/Babel]]) und sie sieht so aus:
-  [ Evaluations: 605902    Packets: 13        Bytes: 416         States: 0     ]
-  [ Inserted: uid 0 pid 84277 State Creations: 0     ]
-leider hab ich kein log angemacht.
+ # babeld config for openbsd
+ skip-kernel-setup true
+ default type tunnel max-rtt-penalty 128
+ interface gre0
+ interface lo5 type wired rxcost 4096
+ interface wg2
+ redistribute local ip 10.50.0.0/16
+ redistribute local ip 10.83.0.0/16
+ redistribute local ip fd43:5602:29bd::/48
+ redistribute local deny
+ redistribute ip 10.50.0.0/16
+ redistribute ip 10.83.0.0/16
+ redistribute ip fd43:5602:29bd::/48
+ local-port 33123
+ log-file /dev/null
-=== Austausch Knoten ===
+=== Babel Routen im rdomain 5  ===
-Am 9. Dezember 2017 wurde der knoten area27 von einem WRT-1043NDv4 abgelöst.  Der alte 841'er wurde merkwürdiger weise sehr langsam und hatte hohe last.  Neuer knoten heisst area27b.
+Wenn babeld gestartet wird, muss sicher gemacht werden das keine statische routen existieren.  Es ist alles Dynamisches routing.  Hier zeigt die routen im rdomain 5 auf OpenBSD:
-== Solar betriebener Router ==
+ job# netstat -nr -T 5 | wc -l
+ job# netstat -nrfinet6 -T5 | wc -l
+ job# netstat -nrfinet -T5 | wc -l
-=== Solar panel ===
+Gute 2K routes das babeld eingeführt hat, eine babel route hat eine '2' flagge angehängt.
-Ähnlich wie den [[Autarker Router|Autarken Router]] von Michi in Röthlein, habe ich eine Solar anlage aufgebaut.  Das macht es der zweite oder dritte Solar betriebener Router in der Schweinfurt Umgebung und im Schweinfurter Hood.
-Das Projekt hat mich einiges gekostet (um 550 EUR) aber ich habe eine 100 Watt Panel mit 70 Ah Batterie, und alles mit Kfz-Steckern und verteilern, DC-DC Adaptern und ein DC-AC Wandler.  Da ich die Ausrüstung für Camping gekauft habe ist es vielleicht so teuer gekommen.  Ich habe am 6. Oktober einen Freifunk Router unter Batterie in betrieb genommen, ich rechne ich habe 7+ Tage Strom unter Batterie und am 7. Oktober habe ich bemerkt das das Panel mitgeholfen hat.
-Anders wie bei Michi ist mein setup eine Indoor-Anlage also muss ich mich nicht um Schnee kümmern, aber das Panel ist auf der Westseite am Fenster befestigt.  Da gibt es eine maximale Wirkung von 65% und nur zu späten Zeiten am Tag wird es richtig in betrieb genommen vorausgesetzt die Sonne scheint.  Die Solar anlage wird sich nie selbst bezahlen ausser ich ziehe mal um in den nächsten paar Jahren oder so (und bekomme eine Sonnenreichere Wohnung).
+=== Der Test Router ===
-<gallery>
+Der test router heisst zrd01 und steht in Schweinfurt. https://monitoring.freifunk-franken.de/routers/17104
-Datei: solar-panel-livingroom.jpg
-</gallery>
-Wenn es ein Strom Ausfall gibt hoffe ich auf LTE umzusteigen unter Solar.  Dafür werde ich eine Fritzbox LTE und den WR-841v8 laufen lassen.  Es spricht gut für Freifunk eine "Emergency Basis" zu haben in Zeiten der Not.
-Wenn's mehr zu berichten gibt werde ich es hier schreiben.  Erstes Ziel ist mal durch den Winter kommen, spätestens bei der März Tag-Nacht Gleiche werde ich dann gegebenenfalls mehr Geräte auf die Solaranlage bauen.
+=== Vielen Dank! ===
-=== Voraussicht und Ereignisse ===
+Vielen Dank an Robert (rola) der sehr sehr viel geduld mit mir hatte.  Wir haben einen Babel gateway aufgesetzt erst für Privat und dann als Backup für die FFF Region Schweinfurt vielleicht?  Mal sehen, der nächste Schritt ist die Community zu fragen ob sie Robert ablöst damit ein echt redundantes Netzwerk entsteht.  Ich werde die ML bald anfragen.
-* 6. Okt - Inbetriebnahme (Batterie stand 5 Balken)
-* 10. Okt - 16. Okt - zurück an AC wegen blödem wetters (Vorsichtsmassname batterie stand 3 Balken)
-* 16 Okt. - Wiederinbetriebnahme (Batterie stand 4/5 Balken)
-* 18 Okt. - Nachts aus / Tags an (Batterie stand 3 Balken)
-* 20 Okt. - Aus fürs Wochenende (Batterie stand 3 Balken)
-* 20 Okt.- 21 Dezember keine Last auf Batterie wegen schlechter Sonnenlage (Stand 2 Balken)
-* um 21. Dez - Dezember Sonnenwende 2017
-* um 20. Mär - März Tag-Nacht Gleiche
-== freifunk-schweinfurt.de DNS verwaltung ==
+=== TODO ===
-=== Registrierung ===
+IPSEC für den GRE vielleicht.  Feedback aus der Community wird auch helfen.
-Ich habe den domain registriert und laufe es von meinem eigens gebauten DNS server.  Gerade macht Freifunk-Schweinfurt.de einen HTTP Redirect (Location tag) auf Freifunk-Franken.de's Schweinfurt seite.
-=== DNSSEC ===
-In der Zukunft will ich DNSSEC aktivieren um noch bessere Integrität zu leisten.  Mein DNS server kann das tun aber es kann noch keinen DNSKEY austauschen deswegen bin ich da ein weng lahm mit.  Aber der DNS server wird in 2018 hoffentlich den Code bekommen um einen "Key Rollover" zu machen.
-=== Wiki ===
+== Administration von Knoten ==
-Vielleicht ist da eine chance einen eigen Freifunk-Schweinfurt wiki zu betreiben.  Solange der traffic unter 1 TB ist kann ich das auch hosten.  Mal sehen was mit dem Freifunk Franken wiki passiert in den nächsten drei Monaten.
-=== Hood Schweinfurt V2 ===
+Ich administriere gerade einen Knoten (bei meinen Eltern).  Wegen Stromsparmassnamen habe ich 3 geräte Zuhause ausgestellt (ich spare somit 17 Watt), mein Freifunk Knoten zuhause war sowieso nicht populär.  Vielleicht bringe ich es zurück in der (fernen) Zukunft.
-Mit der V2 hood SSID von schweinfurt.freifunk.net wird es vielleicht mehr interesse auf freifunk-schweinfurt.de geben.  Spätestens 2018 werden wir es herausfinden.
+Anfang Herbst 2022 wird der Knoten zrd01 (bei meinen Eltern) auch für die Winter Saison 2022/2023 abgeschaltet.  Das ist nicht schlimm da der Knoten keine teilnehmer für monate hatte.  Aber ich stehe da ohne Knoten administrierung bis März.  Leider muss das sein.
+Im Frühling 2023 hab ich beschlossen doch nicht wieder anzufangen mit dem knoten bei mir und meinen Eltern, ich bin aber interessiert mit dem "GartenNetz" knoten (siehe unten).  Strom ist teuer geworden.
-=== DNS secondary in Kanada ===
+== Solar Batterie ==
-Falls der deutsche primary DNS server ausfällt gibt es einen secondary in Toronto, Kanada der hoffentlich weiterspricht.  Redundanz ist bei mir etwas wichtig.
+Nicht jeder hat eine Südliche seite mit Balkon oder Fenster.  Ich habe ein Westliches Fenster wo ich ein 100 Watt Solar panel reingetan habe.  Es macht vielleicht 4-5 KWh im Jahr (!) Meistens um die Sonnenwende im Juni hat die 70 Ah Batterie (auto batterie) ein bissle zu viel ladung.  Dann hänge ich geräte dran um es zu entladen (wenigsten bis auf 50%).  Dieses Jahr, in 2021, habe ich 4 wochen Freifunk gehabt.  Es war ein TP-LINK WR-1043v4 den ich rangehängt habe.  Und da der Knoten ein wenig mehr zur Strasse stand haben sich warscheinlich Leute dafür interessiert die sonnst nicht in guter Reichweite sind.  Aber das ist nur meine einschätzung.  Gerade (26. September) lädt die Batterie und ist wieder auf 12V oder so, es wird warscheinlich bis April dauern wenn ich den Router wieder daranstellen kann.
-== Freifunk in Notzuständen ==
+Das Panel ist jetzt verkauft an einen anderen Freifunker, die Batterie hab ich noch und die steht zu katastrophen zeiten bereit (hoffentlich wird sie nie benutzt).
-=== USV und Batterien ===
+== Ein Garten Netz Knoten ==
-Ich habe einen Freifunk Router (AREA52U) an einem USV zusammen mit dem Router und modem an der Telekom.  Das heisst das nach Stromausfall hier am Deutschhof Freifunk weitergeht für mindestens 25 minuten.
+Ich bin dabei ein solar betriebenen repeater zu bauen der für Freifunk eingesetzt werden kann.  Ich werde hieran noch einige Zeit brauchen bevor ich es erläutere.
-Auch die Batterie für die Solar anlage sollte einiges halten (ist gerade aber im schlechten zustand).  Wenn mal die batterie aufgeladen wird von der Sonne in 2018 sind wir in der lage ein LTE Router an einen Freifunk Router anzuhängen und das würde Freifunk länger als nur 25 minuten halten.  Vielleicht in höhe von ein paar stunden.  Pflege von der Batterie machts aus.
+Bisher hab ich für das Protokoll eine Idee:  LEAPER https://sky.delphinusdns.org/eap-tls-idea.txt
-Ich weiss nicht wie gut das VDSL der Telekom funktioniert wärend eines Stromausfalls.  Es ist noch nie passiert.
+Update (ende August 2023):
-Ich finde Notaggregate sind wichtig und Freifunk kann ein gutes Vorbild machen in der gesellschaft damit.  Sehen wir wohin es uns hinführt.
+Ich hab wenig Zeit gehabt viel weiter zu machen.  Ich hab drei ESP32 module gekauft weil sie billig waren aber hab gemerkt das das Microcontroller toolkit mich in eine lernkurve bringt die ich nicht weiter verfolgen will.
-=== Grosse Strom/Internet Ausfälle ===
+Aber da kommt immer neues aus China.  Letzlich hab ich den Milk-V Duo gesehen der 64-bit RISC-V macht mit 64 MB RAM.  Es kostet 9USD aber das WLAN modul ist extra.  Warscheinlich so teuer wie die alten WR-841'er am ende.  Ich will mal sehen ob ich da OpenBSD drauf laden kann, also diese Investition wird bald stattfinden vielleicht um Weihnachten.  Vielleicht wird 2024 das Jahr wenn ich den "prototyp" fertig bekomme.
-Ich hab mich über Zeit mehrmals informiert im Internet wo die Bodenstationen sind von Satelliten Internet.  Wenn es etwas gibt in Island währe perfekt da einen Gateway server hinzubauen (1984.is VPS provider vielleicht).  Aber die Satelliten betreiber verraten nicht wo ihre Bodenstationen sind leider.  Ein Deutschland weiter ausfall würde uns alle lahmlegen, leider.
-Leider bin ich auch nicht auf einer Südseite um eine Schüssel aufzubauen, also ist ein Projekt nicht in frage für mich um USV und Schüssel aufzubauen, mit GW in Island etc etc.  Aber man kann träumen.