Ich glaube, hier gab es eine Verwechselung technischer Begriffe. Eine Kollisionsdomäne ist eine Verbindung, in der Kollisionen auftreten können. Es handelt sich hier also um ein OSI Layer 1, wie z.B. Luft oder Twisted-Pair-Kabel. Auf dieser Ebene baut ein Layer-2-Protokoll auf, das Datenpakete (PDU) definiert und den gemeinsamen Zugriff auf Layer 1 regelt, so dass Kollisionen möglichst nicht mehr stattfinden. Die aktuelle Version des Ethernet-Protokolls leistet dies.
Meta-Communities, die eine solche Broadcast-Domäne betreiben, nennen wir deswegen Domäne. Bei der Begriffsfindung ist zugegebenermaßen nicht berücksichtigt worden, dass auch auf Layer 1 von einer Domäne gesprochen wird.
Zur genaueren Definition: Eine Domäne ist ein Layer-2-Netz (Broadcast-Domäne) des Freifunk-Netzwerks. Üblicherweise ist dies ein Mesh-Netzwerk, das über Ad-Hoc-WLAN-Verbindungen und VPN-Tunneln aufgebaut wird. Eine Domäne wird von einer einzigen Freifunk-Community oder von mehreren gemeinsam (Meta-Community) betrieben.
Ziel des Projekts Rheinland Backbone ist es, diese Domänen mit IP-Routing ans Internet anzuschließen. Dies gilt für Netzwerke außerhalb der Autonomen Systeme der Freifunk Community. Für Verbindungen innerhalb soll das Projekt IC-VPN dienen. Die über dieses System ans Internet angeschlossenen Communities können auch als eine Meta-Community bezeichnet werden, da sie das erweiterte Admin-Team des Backbone delegieren.
Diese Art von Domäne ist der derzeitige Stand unserer Entwicklung. Es gibt Überlegungen, wie dynamisch Domänen erzeugt werden. Sollte dazu ein Projekt aktiv werden, bildet sich eine Meta-Community, die mehrere Domänen an das Backbone anschließt und gemeinsame Router in einem Transfer-Netzwerk betreibt. Dieses Projekt nenne ich bisher „Freifunk Cloud“.
Ich glaube, gewollt ist Autonomie für Communities. Anstatt bei Wachstum das Netzwerk zu unterteilen und per weiterer Routing-Ebene anzuschließen, wünschen wir uns eine direkte Anbindung an den Rheinland Backbone (und das IC-VPN). Es besteht m.E. kein Vorteil darin, Hierarchien in den Domänen einzuführen.
Second that Nachdem dies geschehen ist, würde ich auch gerne ein, zwei Punkte anbringen, wo ich aktuell noch überschießenden Aktionismus sehe, der mit der Notwendigkeit der rechtlichen Klarheit imho weniger zu tun hat.
Die Punkte wurden ja im Mailwechsel besprochen. Dennoch würde ich gerne ein „ping“ absetzen auf #629125, denn trotz Updates per Web scheint das Ticket versandet zu sein
Und, FTR, trotz Hinweis am 10.02. rennt https://ticket.freifunk-rheinland.net nach wie vor auf MET-0040 … So richtig gepflegt scheint das Ticketsystem weder technisch noch inhaltlich zu werden?
hier kam unter den Freifunkern die Idee auf, Freifunk zu einer weiteren Kommunikationsnetz für Hilfsorganisationen im Katastrophenfall zu machen, denn Freifunk wäre in einem solchen Fall bei ausreichender Meshdichte ja relativ unzerstörbar, solange eben noch Strom da ist. Die Leute aus dem Roten Kreuz, mit denen wir das mal etwas überlegt haben, fanden die Idee auf jeden Fall gut.
Nun haben wir uns weiter überlegt, dass man dafür allerdings in einem solchen Katastrophenfall die Endgeräte der Katastrophenschutzangehörigen priorisieren müsste, denn wie man das ja von Handynetzen kennt, sind diese in solchen Fällen immer hoffnungslos überlastet. Hier entsteht also ein Problem. Wir müssten QoS machen, was ja im Pico Peering Agreement komplett ausgeschlossen wird.
Könnte man eventuell für klar definierte Fälle, wie eben einem ausgesprochenen Katastrophenstatus, welcher ja relativ genau gesetzlich definiert ist, die QoS-Regelung lockern? Oder ist die Missbrauchsgefahr einfach zu groß?
Wir hatten uns das grob so vorgestellt, dass dieser Status im Netz über ein Broadcast-Paket ausgelöst werden kann und die Router dann eine Liste von priorisierten Mac-Adressen laden und anwenden. Man könnte auch die Mac-Listen dann wie die Autoupdater Manifests durch mehrere Schlüssel signieren lassen, um Missbrauch vorzubeugen. Die genaue Implementierung haben wir noch nicht besprochen, weil wir erstmal eine Meinung zu dem Thema generell einholen wollten.
So schön man sich so ein Szenario vorstellen mag, ich bezweifle zum einen die Verfügbarkeit eines MESH in einem wirklichen Katastrophenfall. Zum anderen haben die einzelnen Hilfeleistungsorganisationen selber die nötige Technik um auch weitreichende Nachrichten und Datenverbindungen herzustellen.
Zudem gibts noch die Notfunker unter den lizenzierten Amateurfunkern, welche auch ganz offiziell in mögliche Katastrophen Szenarien eingebunden werden könnten. http://www.darc.de/distrikte/n/notfunk-distrikt-n
Was ich eigentlich sagen will ist, erst muss die Flächendeckung von Freifunk vorhanden sein und dann kann man vielleicht mal drüber nachdenken ob es Sinn macht. Und wer weiß ob nicht irgendeiner der aktiv bei den Hilfsorganisationen in den Fernmeldegruppen tätig und zufällig auch überzeugter Freifunker ist, in irgendein Staufach wo noch Platz ist ne Pico oder Nanostation unterbringt mit passend langen Kabeln zum Anschluss an was auch immer. Aber die Geräte werden niemals Teil einer offiziellen Ausstattung bzw. eines Ablaufes sein und wenn dann nur wirklich als allerletztes Mittel vielleicht zum Einsatz kommen.
Das hilft überhaupt nicht bei einer Überlegung, ob man das Pico Peering Agreement dahingehend ändert oder nicht. Dieser Thread ist für die Diskussion für die Ausarbeitung des Pico Peering Agreement gedacht. Wenn das erstmal steht und von den angebundenen Communites unterschrieben ist, lässt es sich nur schwer ändern. Daher ist es sinnvoll, sich mit solchen Ideen auch schon vor einer Flächenabdeckung zu befassen, zumal es einige Communites gibt, die bereits zumindest in der Innenstadt eine sehr gute Abdeckung haben.
Natürlich werden die Geräte niemals Teil einer offiziellen Ausstattung. Da gibt es aber zumindest hier auch noch einiges mehr, was nicht zur offiziellen Ausstattung gehört, aber trotzdem vorgehalten wird. Wie gesagt, hier war durchaus Interesse dafür, das zu ermöglichen.
Verstehe jetzt noch nicht wieso deswegen das Picopeer Agreement geändert werden sollte?
Es lässt sich schon jetzt schwer ändern diese „Einschränkungen“ sprich privilegierten Traffic mittels QOS dort hinein zu bekommen. Ich möchte das definitiv nicht und würde mir z.B. keine Firmware flashen die $Dinge tut wenn Irgendwer Irgendwo ein bestimmtes Paket im Netz broadcastet.
Ich spinne das jetzt mal weiter. In $Stadt ist ne Demo gegen $Irgendwas am laufen. Die Teilnehmer kommunizieren mittels Freifunk untereinander. Und zwar Frei und ohne Mitlauscher. Und jetzt kommt $Behörde, broadcastet das „Katastrophen“ Paket und schon kommt das Netz zum erliegen für die Demonstranten.
Das Freifunk Netz ist so wie es ist Best Effort und damit kann jeder leben, auch Hilfsorganisationen.
Wenn man davon ausgeht, dass Behörden die Möglichkeit haben, eine Mac-Liste zu signieren, also Zugriff auf die privaten Schlüssel der Berechtigten haben, dann können sie auch direkt die Firmwaresignaturschlüssel verwenden und die Knoten über ein kaputtes Firmwareupgrade abschalten.
Ich habe nicht so recht das Gefühl, dass du meinen Text überhaupt gelesen hast. Aber wie auch immer. Deine Meinung dazu ist klar.
Ich würde mich jetzt einfach aus dem Fenster lehnen und sagen: Wenn es tatsächlich einen Katastrophenfall gibt, und ihr mit QoS oder Verletzung der Netzneutralität recht konkret Menschenleben retten könnt, dann scheißt einfach solange auf das PPA…
im übrigen kann ich mir kein Szenario ausdenken, bei dem FF zuverlässiger, umfassender und schneller wäre, als die vorhandenen Einrichtungen in öffentlicher oder NGO-Hand. Im Gegenteil: geringe Reichweite, Abhängigkeit von einzelnen Steckdosen (die u,U. alle mal eben tot sind) , uvm.
Also eine utopische Idee ohne realen technischen Untergrund.
also ich nutze schon freifunk also extra netz … zum 3G/4G … ich muss aber sagen das wir ein VPN druber aufbauen …
Es rennt ein Ping auf dem Interface auf den Gateway im Fahrzeugt und der sucht den besten weg. Und wenn der Weg ist nimmt der halt den anderen
@MPW
Ich hätte einen Vorschlag zu machen, wäre es nicht Sinnvoll als ersten Punkt den Gültigkeitsbereich zu definieren?
Zum Beispiel: diese Dokument hat Gültigkeit für den Bereich so und so…
Auch wäre es gut zu wissen wer diese Dokument erstellt hat und wie es beschlossen wurde
Zum Beispiel:Wurde erarbeitet von der Gruppe… und mit 2/3 Mehrheit bei der Mitgliederversammlung verabschiedet.
Ich hätte einen Vorschlag zu machen, wäre es nicht Sinnvoll als ersten Punkt den Gültigkeitsbereich zu definieren?
Zum Beispiel: diese Dokument hat Gültigkeit für den Bereich so und so…
Auch wäre es gut zu wissen wer diese Dokument erstellt hat und wie es beschlossen wurde
Zum Beispiel:Wurde erarbeitet von der Gruppe… und mit 2/3 Mehrheit bei der Mitgliederversammlung verabschiedet.
Nachdem dies geschehen ist, würde ich auch gerne ein, zwei Punkte anbringen, wo ich aktuell noch überschießenden Aktionismus sehe, der mit der Notwendigkeit der rechtlichen Klarheit imho weniger zu tun hat.
