Ich wollte doch nur ein bisschen unverfänglich über meine Ideen diskutieren…
Das sind doch nur Hirngespinste von mir (einem interessierten Laien), ob und wie man FF evtl. verbessern könnte.
Ich hab schon weit über 50 Router in Witten geflasht und aufgebaut. Und bin zu zig Routern wieder hingelaufen, weil der Stecker gezogen wurde. Den Hinweis auf Teamsport verbitte ich mir.
Ich seh hier einen Ansatzpunkt. Das Problem meine ich schon öfters heraus gelesen zu haben.
Es wäre wohl hilfreich, wenn sich diese diversen Organisationen, die ISP sind und/oder massiv Ressourcen übrig haben, einfach einmal zusammen in einem Thread vorstellen.
Das würde Leuten, die auf der Suche nach einem einfachen und praktikablen Weg sind helfen, die passende Gruppe zu finden und auch andere inspirieren, die ebenfalls zu einem wollen werden.
Das kann ja ganz unverbindlich sein und soll nicht als Angebot gelten sämtlich Arbeit bei diesen abzuladen.
Grüße Sebastian
Vorstellung macht durchaus Sinn, aber massiv irgendwas über wird niemand haben.
Die Freifunk Communitys sind grundsätzlich untereinander vernetzt. Da aber Freifunk immer einen lokalen Bezug haben sollte, macht es keinen Sinn wenn z.B die Münchener Leute aus Norddeutschland aufnehmen, nur weil Sie noch Kapazitäten über haben.
https://freifunk.net/wie-mache-ich-mit/community-finden/
Ist immer ein guter Anlaufpunkt, um herauszufinden, ob eine Community in der Nähe ist. Da kann man sich dann der Community in seiner Nähe anschließen und sich einbringen. Wenn man grundsätzlich das Zeug zum Gateway/Supernode Admin hat, wird man dort mit Kusshand aufgenommen werden und kann sich alles nötige für den GW Betrieb zeigen lassen.
Einen lokalen Bezug kannst du auch ohne Supernode Admins Vorort haben. Unser Einzugsgebiet (FFMUC) ist zum Beispiel sowieso riesig und es gibt lokale Gruppen die sich um das Vorort kümmern, aber nichts mit den Supernodes zu tun haben.
Aber ja, Kommunikation ist da oft schwierig aber es gibt Videokonferenzen, das kann man hinbekommen. Die Frage ist will man das, denn die Arbeit und Verantwortung wird dadurch nicht weniger.
Da kann man sich ganz gut einarbeiten. Als ich mit Freifunk angefangen habe, hatte ich davon auch keinen Plan. Bücher lesen und Fragen stellen hilft. Aber es geht natürlich nicht von heute auf morgen.
Oder einfach nen Ansatz wählen (je nach Vorwissen) und Leute ansprechen … cc @Barbarossa der weiß wovon ich rede ;).
findest Du?
wie schon in der Diskussion um die API: Hier offenbart sich wieder dieser Geburtsfehler seitdem Freifunk von Wiki auf Github umgestellt hat:
Es wird nach einem zentralen Willen „nach Ortschaft“ aufgezäumt.
Statt dass Leute zusammenfinden die ähnliche Interessen haben.
Also Auswahl nach „welche Art von Freifunk wird betrieben“ (Kölner, Berliner, Aachener Modell, um es mal so blumig zu beschreiben)
Oder auch „welche Orchestrierung wird benutzt“. KVMler werden in Winterberg nicht glücklich. Debian&Ubuntu-Nutzer werden Bergischen Land wenig Freude haben.
An sich ist es in der Tat egal, ob man, beispielsweise, mit Münsterland oder München zusammenarbeitet — die fraglichen Server stehen aus $Gründen i. d. R. nah an Internetknoten, bei der heute verbreiteten Tunnel-Gateway-Architektur (d. h. keine Ausleitung am Knoten sondern an zentralen Gateways) kostet das nur wenige ms Laufzeit.
Aber an sich sollte Freifunk auch eine soziale Komponente haben, und Teleconferencing ersetzt da imho nicht den persönlichen Kontakt, auch nicht mit wandgroßen UHD-Videowänden und/oder 360°-Kameras. (Und mit schulpflichtigen Kindern hat man Himmelfahrt, Ostern, Pfingsten oder zwischen den Jahren ggf. andere Prioritäten, als sich auf einschlägigen Treffen rumzutreiben, frißt das Hobby doch schon werktags Lebenszeit.)
Es gibt doch ein Konzept für Freifunk in dezentral in Gluon mit Babel von @Klaus_Dieter.
So ähnlich hatte ich mir das auch vorgestellt.
Freifunk-Router bekommen ein Prefix (eine Community) und „Eintrittsupernodes“ per site.conf mit.
Supernodes sind in dem Kontext Nodes, die VPN-Zugang zum Freifunknetz anbieten. Exitnodes welche, die Exit ins Internet anbieten. Dann gibt es noch Border-Nodes, das sind Knoten, die zwischen mehreren Domains routen können. Auch vorstellbar, dass man auf einem Layer DE-Weite Border-Nodes aufspannt ähnlich dem InterCity-VPN - nur halt dezentraler.
Auf den Nodes, die genug Speicher haben, läuft eine Datenbank, die Informationen wie respondd oder besser alfred sammelt und geschickt weiterverteilt und den Routern bereitstellt. In dieser Datenbank werden z.B. Informationen über von Nodes angebotene Peerings gespeichert. So ein Peering ist ein Angebot von Nodes, eine direkte Verbindung per VPN anzubieten (dafür muss der Port offen sein, IP könnte aber dynamisch sein). In diesem Angebot können zusätzliche Dienste beworben werden, die dieses Peering attraktiv machen wie Internet-Exit und wie viel Bandbreite aktuell dafür bereitsteht. Solche Peerings erhöhen die Redundanz und reduzieren kostenintensiven Verkehr.
Außerdem und das ist für mich das schlagkräftige Argument eröffnet es dem Laien die Möglichkeit mit einer FritzBox 4040 mit Mullvad-Ausleitung in Deutschland eine Exitnode mit Gluon für seine Community bereitzustellen.
Was einen ISP ausmacht, ist etwas umstritten; der FFRL hat’s, IMHO, richtig gemacht und ist LIR geworden — mehr ISP geht eigentlich nicht, zumal ein eigenes Netz existiert. (FTR, wer noch plante, LIR zu werden und 4 /24 (gar als ein /22) zu ergattern, der Zug ist abgefahren.) Die schiere Anmeldung bei der BNetzA bewirkt ja, nach BNetzA-Aussage, keinen Providerstatus.
Den zweiten Halbsatz verstehe ich nicht: wieso sollte ein »Hi, wir sind ISP und es ist geil«-Posting andere ›inspirieren‹, dem nacheifern zu wollen?
Das Henne-Ei-Problem sehe ich – an wen kann ich mich wenden, wenn ich gerne Freifunk machen möchte, aber den Internetzugangskram gerne nicht selbst mir aufhalsen will? –, doch andererseits: Fragen kostet doch nichts, außer ggf. etwas Überwindung?
Was mich an dem Konzept schon mal stört ist die wirklichkeitsfremde, rein akademische Herangehensweise:
All of these ideas are designed for ipv6-only networks
IPv6 ist leider nachwievor das – seit 20 Jahren – kommende Internetprotokoll; die Musik spielt bei IPv4 und ich zumindest verschwende keine Lebenszeit auf untaugliche Versuche.
Bislang habe ich die Info nicht gefunden, wie Roaming im WLAN bei multiplen externen Prefixen funktionieren soll. Andere-SSID-je-AP ist unpraktikabel und in Größenordnungen von zehntausenden von Freifunk-APs auch nicht mehr witzig.
Puh. *Gebetsmühle raushol* Alle Knoten einer SSID bilden zwangsläufig das gleiche IP-Netz, damit darf es keine lokalen Exits (im Sinne von „lokaler Mullvad-Tunnel“ oder „balls-of-steel-DSL-Exit“) in einem ESS geben.
Im Falle einer 200 Knoten-Community hiesse daß, es gäbe ca. 190 SSIDs (10% der Knoten als in lokalen Meshes eingebunden angenommen), damit auch nur 1 Knoten einen eigenen Exit fahren könnte.
That ship has sailed, kein Nutzer wird 100+ SSIDs allein in seinem Heimatkreis händisch freischalten — dazu ist selbst in Deutschland Mobilfunkabdeckung zu gut und zu günstig.
Für IPv4 kannst du NAT46 benutzen und mit NAT426 funktioniert dann auch Roaming problemlos.
L3roamd und Netztrennung wie bei Batman auch - nur hoffentlich irgendwann in vollautomatisch. Jede domain/site hat ein eigenes Prefix und Border-Router routen dazwischen. Es ließe sich auch bewerkstelligen, seamless von einer Domain in die andere zu roamen, aber es gibt genug zu tun.
Das Problem lösen wir doch auch. NAT426 z.B. macht connection-tracking auf die Internet-IP-Adressen um festzustellen, welche Gateway für welchen Internet-Server genutzt werden soll. Du kannst also X IPv4-Gateways in ein Netz packen - für Verbindungen zu neuen IPs wird dann die aktuell beste Gateway gewählt. Alte Verbindungen werden über ihre alten Gateways abgewickelt. Mit IPv6 könnten wir das so ähnlich lösen, aber das würde NAT benötigen und das wollen wir bei IPv6 ja eigentlich nicht. Wenns nicht anders geht, dann werden wir das aber so machen.
Meckern und es nicht als praktikabel darzustellen hilft nicht. Wir brauchen Leute, die helfen das umzusetzen, denn erst einmal ist jedes technische Problem lösbar…
All of these ideas are designed for ipv6-only networks
IPv6 ist leider nachwievor das – seit 20 Jahren – kommende
Internetprotokoll; die Musik spielt bei IPv4 und ich zumindest
verschwende keine Lebenszeit auf untaugliche Versuche.
Das Thema hatten wir in dem anderen thread auch schon mal. Clients sehen
ipv4 und ipv6. Das IPv4 Internet ist nativ erreichbar - und der
leichteste Einstieg in Dezentralität ist über ipv6. Das hat weder etwas
mit akademischem Ansatz noch mit angeblich untauglichen Versuchen zu
tun. Einfach mal reindenken anstatt kategorisch ohne Kenntnis der
Technik abzulehnen würde uns alle weiter bringen.
Für IPv4 geht das übrigens auch, hat jedoch eine Komplexität, die ich
im Moment weder durchdenken noch bauen möchte, denn ich schließe erstmal
ein Thema ab.
Bislang habe ich die Info nicht gefunden, wie Roaming im WLAN bei
multiplen externen Prefixen funktionieren soll. Andere-SSID-je-AP ist
unpraktikabel und in Größenordnungen von zehntausenden von Freifunk-Aps
auch nicht mehr witzig.
Genau so wie mit nur einem externen prefix. Da gibt es keinen
Unterschied. Siehe Layer 3 Maste plan.
Puh. *Gebetsmühle raushol* Alle Knoten einer SSID bilden zwangsläufig
das gleiche IP-Netz, damit darf es keine lokalen Exits (im Sinne von
„lokaler Mullvad-Tunnel“ oder „balls-of-steel-DSL-Exit“) in einem
ESS
geben.
Mit dem Hinweis dass man so etwas nicht bauen könne, bist Du anderthalb
Jahre zu spät dran. Die Gluon-Integration liegt als PR vor, ist
allerdings noch in Arbeit.
Also: Pack die Gebetsmühle wieder ein und stell stattdessen auf Empfang.
Wie das mit einer ssid geht steht im Layer 3 Master Plan, den tcatm 2016
aufgeschrieben hat. In der Wayback machine findest du den noch unter Layer 3 Master Plan / Nils Schneider
Beim aktuellen Babel-Ansatz würden die Prefixes im ganzen Netz verteilt werden, wenn denn eine distribute-Regel bei Babel vorhanden wäre. Natürlich müsste das Prefix auch announcet werden. Softwaretechnisch problemlos möglich, aber wie tcatm geschrieben hat, macht es Sinn nur die Prefixes zu announcen, zu deren Gateways eine Node eine gute Metrik hat. Das müsste noch implementiert werden. Außerdem verhalten sich Client-Devices wohl nicht so toll mit verschiedenen Prefixes. Da gab es mal ne Diskussion auf der Gluon Mailing-Liste. Ist ne Sache die mal durchgetestet werden müsste, aber eine Lösung gibt es in jedem Fall, selbst wenn sie heißt: „Exitnode, die das Netz-Prefix nicht global routen kann, muss NAT66 machen“ oder alternativ „Node an der der Client hängt macht Netmap auf default Routen außerhalb des Source-Prefixes“, aber dann bräuchte jede Exitnode ein /64 und das wäre auch nicht so toll.
Das Problem war glaube ich, dass Clients erwarten, dass jede in ihrem Netz announcte Gateway ihr globales Prefix routen kann bzw. dass es standardkonform nur ein IPv6-Subnetz in einem Layer 2-Netz geben darf. Im schlimmsten Fall brauchen wir eine Lösung wie NAT426, die ein homogenes IPv6-Netz faket… Wir sind nicht eingeschränkt, weil es das eigentlich noch nicht gibt, was wir hier bauen. Ist ja sozusagen ein Zukunfts-Internet.
Dein NAT426-Kernelmodul ist, entnehme ich den Fundstücken zu dem Stichwort, work-in-progress? NAT46 auf dem Knoten braucht eine NAT64-Gegenstelle, wo?
Erm, Netztrennung verhindert Roaming? (Gewolltermaßen bei batman.) L3roamd scheint wieder v6-only zu sein.
2001:db8:f00:ba8::/64. Mein T-Uplink habe 2003:666:dead:feed::/64 und ich leite darüber aus. Der Knoten müßte dann ja beide Prefixe verteilen (RA?), und Dein NAT426-Modul hier erkennen, daß der 2003er Prefix „näher“ ist? Der nächste Knoten in Funkreichweite habe einen UM-Uplink, 2a02:908:deca:fbad:/64, bietet auch lokale Ausleitung an.
Sofern ich das richtig verstanden habe, sorgt nat426.ko „irgendwie“ dafür, daß das Endgerät weiterhin TCP-Sessions, die mit Adressen aus 2001:db8:f00:ba8::/64, 2003:666:dead:feed::/64 und 2a02:908:deca:fbad:/64 usw. begonnen wurden, bekommt, egal, wo im (L3-) Mesh sich das Endgerät befindet? Was passiert mit UDP-„Verbindungen“, z. B, meinem OpenSSH-Tunnel?
Das Gute ist der Feind des Besseren. Derzeit lösen wir das Problem auf Layer 2 mit Batman. Klappt galanterweise für v4 und v6 ohne irgendwelchen Klimmzüge; ja, die lächerlich großen DHCP-Ranges sind eben das: lächerlich. Aber wenn man IPv4 im FF-Kontext nur als „Dinosaurier github-Enabler“ nimmt, kann man auch in jedem Mesh 10/8 nehmen und das Thema ist gegessen; Inter-Zonen-Verkehr mit RFC1918-v4 ist Bullshit, mit public v6, notfalls ULA, ist End-to-End möglich.
Ich sehe noch nicht, wie das mit den lokalen Exits funktionieren soll. Derzeit hat jedes Mesh bei uns einen (public) /64-Prefix, das Routing dessen ist extern gesichert. V4 eitert per stateful NAT (conntrack) am GW raus, Rückantwort kommt über das GW ins Mesh zurück, tut. Per zentralem DHCP bekommt der Knoten dauerhaft die gleiche interne v4-IP, das funktioniert und ist nachvollziehbar. Mit l3roamd und 464xlat scheint mir das L3-Setup nicht wirklich handlicher?
Klar, Deine Entscheidung. Aber ohne IPv4-Unterstützung sehe ich 2019 kein Zugangsnetz als nutzbar an, siehe github. DNS64 ist tot, durch a) DNSSEC und b) DoH im Browser und c) die Kombination von beidem (Browser kann broken DNSSEC erkennen und schaltet direkt auf DoH).
Bedankt, Ich gucke dann 2024 mal, ob sich der „Master Plan“ in Code verfestigt hat.
Ich halte fest: so trivial mit dem lokalen Exit ist das nicht, im Zweifel führt es zu NATPT und lustigen anderen „Herausforderungen“. Natürlich kann man alles mit ein paar Kilotonnen Sourcecode lösen; ein paar zweitausend Kilotonnen, denn da „draußen“ IPv6 ignoriert wird, müssen zwei Lösungen, eine für den mikroskopischen IPv4-Adressraum und eine für IPv6, entwickelt werden. Derzeit sehe ich nicht den Vorteil eines L3-Netzes gegenüber einem L2-Netz auf Basis des aktuellen Flattermanns. Und, wie Du selbst sagst:
To be fair Batman V has improved much and with enough RAM and bandwidth even Batman V networks can scale quite good.
Ich finde es toll, daß Ihr da mit Elan bzgl. L3 Euch engagiert; aber ich habe einfach prägende OLSR1-Erfahrung, und wenn ich mir den Wasserkopf an Protokollen und Dämonen angucke, die L3 mitsichbringt, verglichen mit batman_adv.ko, sehe ich da keinen Vorteil für uns.
Aber: was hat das jetzt eigentlich mit „Zentrale Supernodes für alle FF-Communities in DE wünschenswert“ zu tun?
Zentrale Supernodes sind ein notwendiges Übel und eigentlich unvereinbar mit der Freifunkideologie. Dieses Übel muss beseitigt werden. Vor allem senkt es Kosten und die Einstiegshürde, wirklich Bandbreite zu spenden, es erhöht die Redundanz und macht Freifunk technisch zum Spitzenreiter.
Grundlegend funktioniert es, aber es braucht noch ein wenig Pflege und aktuell habe ich keine Zeit dafür. Die NAT64-Gegenstelle ist eine Exit-Node, die IPv4-Traffic abwerfen kann. Dafür wird ein spezielles /48-Prefix genutzt. Mit der MAC-Adresse der Exit-Nodes bildet sich ein /96, wo du das gesamte IPv4-Netz mappen kannst. l3roamd schickt dem NAT426 dann z.B. Konfigurationsänderungen, wenn sich die Metriken der Exit-Nodes ändern. Oder wenn ein Client geroamt ist, kommuniziert l3roamd, ob der Client freigegeben werden soll und wenn ja, wie die Tracking-Daten der letzten Node lauten (bzw. l3roamd konfiguriert den Client im NAT426 entsprechend).
Erst einmal hat das (nicht 100% dezentrale) Netz, wenn sich eine Community drum kümmert, die sogar ein AS betreibt oder wenn man gut mit dem Serveranbieter steht, häufig ein von mehreren Exitnodes nutzbares globales IPv6-Prefix. Dort gibt es mehrere IPv6-Gateways, die das gleiche Subnetz bedienen können. Diese werden im Normalfall mit Router Advertisements announcet und die Clients bilden sich eine IPv6-Adresse auf Basis dieses Prefixes und haben damit eine globale IPv6-Adresse und mehrere Gateways, denen sie die Daten schicken könnten, die alle mit ihrer globalen IP-Adresse klarkämen. Im dezentralen Fall haben wir jedoch unter Umständen Exit-Nodes, die nicht delegiert sind, globale Adressen aus ihrem (Inter)Netz zu verteilen. Wir wollen aber jeden Krümel günstige Bandbreite nutzen können. Das heißt, dass wir unter Umständen eine Möglichkeit brauchen, mitzuentscheiden, über welche Gateway der Client ausleitet. Aktuell ist das Konzept dahinter, dass die IPv6-Gateway immer die lokale Node ist, an der der Client hängt und dass diese Adresse bei allen Nodes identisch ist. Dann könnte man mittels connection-trackings und Übertragung der Daten mittels l3roamd allerhand Magie betreiben um die vielen Exits richtig zu nutzen. Aktuell ist es noch nicht möglich, das Abbrechen von Verbindungen bei IPv6 zu verhindern, wenn Netzprefix-fremde Gateways genutzt werden und der Client sich nicht intelligent verhält.
Auf IPv4 trifft deine Aussage jedoch zu. Da manche Services Probleme damit haben, wenn die Anfragen von verschiedenen Source-Adressen kommen (weil der Client z.B. gerade geroamt ist und bei der neuen Node eine bessere default-route announcet wird. Z.B. wenn dann auf einmal die Verbindung vom Gameserver abbricht. Das ist wie du sagst. Das „Mainstream“-Internet hinkt etwas hinterher was solche Fälle angeht. Das NAT426 trackt deshalb Verbindungen anhand der globalen IPv4-Adresse der Destination aus Client-Sicht. D.h. deine TCP- und UDP-Verbindungen benutzen weiterhin die gleiche Gateway um z.B. 8.8.8.8 zu erreichen. Wird die Metric zu schlecht oder timen die Verbindungen aus, wird der Eintrag gelöscht und die aktuell von l3roamd präferierte IPv4-Exit-Node wird genutzt. Im Fehlerfall, wenn die Node z.B. ausfällt, teilt l3roamd das NAT426 mit und die Verbindungen werden sowieso gekappt.
Es wird nicht allzu verschiedene Lösungen für IPv4 und IPv6 geben. Seien wir doch froh, dass IPv6 kein DHCP braucht. DHCPD ist auch ein richtig tolles Ding. Gab es vorher nicht und ist leider noch ziemlich unbekannt.
Naja, also mit Batman funktioniert das Roaming zwischen Supernodes doch nur, wenn diese layer 2-Verbindungen zueinander haben, wodurch Kreuztraffic entsteht. Da gibt es doch keine Lösung für das Problem und wenn nicht auf den "Freifunk-"IPs masqueradet wird, dann gehen dir aber auch die Verbindungen kaputt. Das heißt ohne single point of failure gibt es im Freifunk aktuell kein IPv4-Gateway-Roaming für Clients. Der DDHCP funktioniert wohl auch ganz gut.
Der IPv6-Teil hingegen wird wohl iptables-Magie - das ganze Routing kann die Node übernehmen, wenn sie selbst vom Client als default Gateway angenommen wird.
Edit: Verständnishalber: das Routing unterschiedlicher Prefixes läuftBabel-mäßig über Source-Routing wie von tcatm vorgeschlagen. Da geht natürlich das Roaming kaputt ohne iptables-Magie, wenn Gateways mit anderem Prefix genutzt werden…
Ich trete ja gern irgendwo zwischen… Schöne Ansätze und Ideen.
Aber als stupide Aufgabenstellung:
Gestaltet doch mal ein Konzept bei dem die Communitys die nicht so dick mit Kenntnissen aufgestellt sind, ne Chance haben sich neben der Finanzierung ein wenig ein zu bringen.
Die flattermann Instanzen sind ansich brauchbar dokumentiert (bis auf den l2tp Kram wie ich finde), da kann man sich mit Verständnis für die Materie rein arbeiten, anders gesagt - Arbeitsteilung betreiben.
Gibt es doch schon. Mehrere!
(Oder hast Du Dich von der derailten Diskussion der letzten 5-10 Beiträge vom Thema ablenken lassen?)
Münsterland, Eulenfunk (gibt sicher noch mehr)
„BringYourOwnBlech“ und schon geht’s los!
Die Leute in diesen Communities nehmen auch Leute „bei der Hand“ um die Kochbücher zu erläutern, also ggf. gemeinsam Dinge zu tun.
Was es (zumindest meines Wissens) nicht direkt online gibt ist „Freifunk as a Service“. Also „Andere Leute Freifunk machen lassen gegen reguläre, adequate Bezahlung“.
(Und wenn Dir die Konzepte nicht gefallen: Mache ein besseres oder bringe Dich in diese selbst mit ein. PRs welcome. Liegt alles bei Github. Aber klar, können wir jetzt natürlich auch in Richtung „Github ist Microsoft, Ih-Bäh!“ derailen.)
Ich weiß - bezog sich aber eher auf die Fragestellung.
Ein Vorschlag… biddeschön:
Dezentral, dabei Zentral, mitmachen kann jeder muss aber nicht. Nen „Grunddesign“ wird „vorgeben“ um mit zu machen. Vorgabe wäre z.b. sowas wie „Geht nur mit Gluon“
Die Multidomänenfirmware ist dazu ein interessanter Ansatz => Pauschale „Basisfirmware“, nackt ohne großen Krempel. Nutzer/Knotenaufsteller ist glücklich das er was ans „Rennen“ bekommt.
Etwas wie nen Updatemodul => Anhand einer Variable die „Verpflichtend“ ist, wird die passende Regionale/Lokale Firmware ermittelt. 24h Später läd sich der Knoten die passende Firmware selbst. Erklärungen etc.pp zu dem Vorgehen könnte man auf der „Download“ Seite und in der EMail die das System automatisch an den „Betroffenen“ versendet (er muss ja was lt. PPA an Kontaktdaten da lassen)
Hätte zur Folge - der Dienstanbieter kann mehr oder weniger „einfach“ seinen Dienst antreten.
Dies würde als „Vorraussetzung“ bedeuten → die teilnehmenden Domänenbetreiber müssten miteinander Sprechen, da sie mehr oder weniger ähnliche bis gleiche Systeme betreiben würden. Die ein oder andere Partei bekommt damit zusätzliche Unterstützung und hat damit Möglicherweise mehr „Personal“ in der Hinterhand um mal was zu Fixen, bzw. die Probleme die Auftreten können wären weniger differenziert, hilfestellungen etc. schneller möglich.
… behandeln wir hier.
Die L2-Verbindung per L2TP, VXLAN oder gar VLAN – nötigenfalls auch per L2TP-over-WireGuard – ist eher trivial, und der Kreuztraffic kein großes Problem.
Es gibt Lösungen, die die conntrack-Table synchronisieren; aber das ist doch eine Ablenkung vom eigentlichen Thema. (Auch beim dezentralen Exit kommt ohne conntrack-Synchronisierung bei Absturz des Gateways das Ende für bestehende v4-Verbindungen.)
Das mit Mails ist, schon vor der DSGVO nicht so einfach; bevor Du da was produktives hinschickst, mußt Du per Double-Opt-In das Einverständnis absichern. JFTR: DSVGO beats PPA.
Aber Du suchtest doch nach was wo »Communitys die nicht so dick mit Kenntnissen aufgestellt sind, ne Chance haben sich neben der Finanzierung ein wenig ein zu bringen« — inwiefern bringen ›Geldbeutel-Communities‹ in Deinem skizzierten Fall mit mehr als Geld, oder wie überhaupt, ein?
Aber das, was Du da als »Multidomänenfirmware« bezeichnest, machen wir seit ein paar Jahren (vorher mit eigenen Patches, nun mit dem nativen Gluon-Feature): wir haben eine FW, während der Erstinstallation wird anhand der Koordinaten (über einen zentralen Setup-Server) die zu verwendende »site.conf« ermittelt (die mittlerweile intern eine site.json ist), diese wird installiert und feddich. Dank Automatisierung im Backend können mehrere Meshes einfach parallel betrieben werden.
Mit Dingen wie den Ansible-Rollen der Münsterländer können eigene VMs relativ einfach zu einer Gluon-Freifunk-Plattform gemacht werden — allein, wenn man nicht weiß, wie das alles zusammenspielt, wird der Frustlevel für den, der den ersten Schluckauf bearbeiten soll, unendlich groß sein.
Nö, Dienstbetreiber sind verpflichtet Kontaktdaten zu veröffentlichen, zur Verfügung zu stellen.