Ich erlaube mir zur Diskussion der technischen Fragen einen neuen Thread zu eröffnen.
Die Freifunk Infrastruktur ist, sofern sie nicht grundlegend überarbeitet wird, erstmal auch nach dem Wegfall der WLAN Störerhaftung nötig.
Anders als viele zu glauben scheinen, sind die Gateways der Communitys nicht nur einfache Relays, sondern stellen alle zentralen und netzrelevanten Dienste für Freifunk bereit.
Dazu zählen:
DNS Auflösung innerhalb der Freifunk Netze und ins Internet
DHCP Zuweisung der IP der Freifunk Clients dadurch wird das roamen
zwischen verschiedenen Nodes möglich
Bereitstellung der Firmwareupdates für Freifunk Router
Zugang zum InterCity VPN und damit eine Verbindung der Communitys untereinander
NTP Server zur Syncronisation der Systemzeit auf den Freifunk Routern
OpenWRT Package Mirror zur Nutzung von ipkg auf den Nodes
Weiterleitung des Internettraffics an einen Exit um den Anschlussinhaber vor
Abmahnungen zu schützen
Bereitstellung der Verkehrsdaten zur Auswertung und Nutzung der Freifunk MESH Maps
Ich denke es wäre nun grundsätzlich möglich, auf den Supernodes den Traffic abzukippen, wenn auch immernoch problematisch.
Diese Dienste können dezentral gemanaged werden. Die Supernodes werden wir aber weiterhin brauchen, um als VPN-Server und Gateway für manche Router zu dienen.
Nö? DNS kann man frei wählen. wenn man will auch welche Außerhalb des FF-Netzes und z.B. innerhalb des DN42 falls ICVPN existiert. Ist der DNS Server dort richtig aufgesetzt stellt es kein Problem dar auch FF adressen aufzulösen.
Auch hier nö, Einfach einen DHCP Server aufsetzen, Gateway-Mode aktivieren, sich überlegen wie man den Traffic routen will, go! (Ergibt zwar nur bedingt Sinn, aber man MUSS den DHCPd nicht auf einem GW betreiben)
Auch die müssen keineswegs irgendwo im Internet rumliegen, die liegen halt primär dort rum, da man dort entsprechende Bandbreiten in alle Richtungen zur Verfügung hat.
Okay, ja, hier wird es etwas haarig, aber wenn du die Infrastruktur passend baust, geht das auch so. DN42 Peer, Sich selbst als GW annoncen, dazu den Internettraffic entweder woanders hinschicken oder um/ausleiten. Geht also auch mit etwas aufwand.
Das ist Firmwaresache, das kann laufen wo es will, du musst es nur in deine Firmware einbauen im Zweifel einen „offenen“ Round-Robin betreiben.
Siehe NTP.
Wenn man wirklich möchte, kann man auch hier eigene GWs am eigenen Anschluss betreiben an denen du einfach kein VPN annimmst. Dann leitest du vermutlich den Traffic lokal aus, da du wahrscheinlich weit besser erreichbar bist, als die GWs im Internet.
Zumindest bei A.L.F.R.E.D. kannst du ebenfalls deine Daten selbst generieren. hässlich wird es nur mit mehreren A.L.F.R.E.D.-Servern mit unterschiedlichen Versionen, sonst auch kein Problem.
Alles in allem also eigentlich nur eine Frage des Wollens. Man muss eigentlich nicht mal was umstellen, es funktioniert auch schon so. Warum man es aber im Moment so händelt hat vor allem den Grund, dass man es halt so sehr einfach administrieren kann. Außerdem sind lokale Anschlüsse meist etwas zu dünn um größere Trafficmengen zu händeln. Nicht zuletzt hat man noch das Problem, dass es zu sehr hässlichem Quertraffic über deine private Leitung kommen kann, wenn es nicht ideal konfiguriert ist.
Die Gründe warum man dennoch nicht direkt ausleiten „sollte“ wurden ja woanders schon zu genüge genannt. Rein technisch ist es aber kein Problem.
DHCP Zuweisung der IP der Freifunk Clients dadurch wird das roamenzwischen verschiedenen Nodes möglich[/quote]
Auch hier nö, Einfach einen DHCP Server aufsetzen, Gateway-Mode aktivieren, sich überlegen wie man den Traffic routen will, go! (Ergibt zwar nur bedingt Sinn, aber man MUSS den DHCPd nicht auf einem GW betreiben)[/quote]
Es muß einheitliches DHCPv4 & v6-RA gesprochen werden, wenn, wie Tarnatos schrieb, das Roaming (was imho nur ein Handover ist) weiterhin funktionieren soll. Daß man bei batman_adv auf jedem Knoten den Gateway-Modus aktivieren kann, steht außer Frage — genauso, wie daß das generell keine gute Idee ist.
Ohne einheitliches DHCPv4 (und das muß bei batman_adv dort laufen, wo der Gateway-Modus aktiviert ist (DHCP-Relay als Sonderfall außen vor)) hast Du kein Netz mehr, sondern verschiedene Hotspots, an denen von anderen Knoten kommende Geräte nicht wirklich gut funktionieren.
Oder kurz: klar kannst Du auf jedem Knoten in einem batman_adv-Netz einen DHCP-Server laufen lassen. Ist dann aber halt scheiße.
Lokale Wolken (zusammenhängende Straßenzüge, Plätze; also da, wo Knoten meshen und sich Nutzer zwischen Knoten bewegen) wollen mit batman_adv und wolkenzentraler IP-Vergabe bedient werden (oder einer Mobile-IP-Tunneling-Lösung). Zwischen den Wolken könnte man routen — siehe http://libre-mesh.org. Das wäre eigentlich eh’ die Lösung, aber soweit ich den libre-mesh-Ansatz bislang verstehe, müßte man da eher planen, statt, wie derzeit, einfach batman_adv-Knoten in die Landschaft zu stellen und der Rest findet sich.
Die DHCP-Server müssen in dieser Konfiguration Anfragen „von außerhalb“ mit einem NAK beantworten und zudem muss natürlich sichergestellt sein, dass die Netze der Domaine untereinander geroutet werden.
Alternativ kann man sogar das Layer2-Netz behalten, inklusive der Tunnel zu den Fastd-Servern.
Die Lokalen Nodes sind aber alle Gateway mit einer lokalen DHCP-Range (die mittels noch zu definierender Magie zentral ausgewürfelt wird inkl. Fallback-Senario etc…)
Und wenn ein Client von einem anderen Wolke hineinroamed, dann hat er bis zum DHCP-NAK (Und Adressneuvergabe) halt eine IP, die per Layer2 zum Gateway des anderen Knotens geht… Das ist dann blöd, aber eben Notbetrieb solange bis das dhcp-renewal ansteht.
Das ist aber eine Binse.
Alles was wir im Freifunk tun muss ständig überarbeitet werden.
Firmware, Server, Domaingrößen/Grenzen, Vereine…
Und wenn man’s nicht tut, dann geht’s zwar erstmal ein paar Monate noch, aber irgendwann ist der Ofen dann aus.
[quote=„thomasDOTwtf, post:6, topic:12152, full:true“]
Das ist ziemlich sinnlos, da sowieso alles im Internet unverschlüsselt abläuft.[/quote]
aber dann ist das Inranet verschlüsselt und ermöglicht so ein Router-Router using von Ressourcen, so lange kein Endclient per WLAN dran ist.
(OK, Idee ist spontan, noch nicht ganz zuende gedacht, aber ich seh, ebenso wie Firmen mit ihren Aussenposten per VPN und verschlüsselt verbunden sind, da auch eine FF-Intranet-interne Nutzung. rein emotional klebe ich an der Verschlüsselung)
das ist klar, meine ich auch nicht.
Aber ich denke mal ins Blaue:
A macht ne Webcam von seinem Garten und jede Minute von den Vögeln dort. Stellt er nicht ins Internet, sondern in einem shared Folder seines PCs, worauf alle von FF Zugriff haben, aber sonst keiner.
Alle anderen FFler (des Ortes oder des Netzbereiches, die am selben Server hängen), haben das Folder in ihrer Netzwerkliste mit Realtime Vögelfotos
Anstelle der Vögelbilder lassen sich -zig Nutzungsmöglichkeiten denken. Kern-Gedanke ist, jeder FFler des Netzteils, also mit demselben Server verbunden, hat Leserecht auf eine spezilelen Folder oder Anwendung seines PCs. Theoretisch auch mit Schreibrecht, dann köntne man ein lokals Forum ohne Internet machen, als rein lokale Diskussionsrunde über jedes beliebige Thema, oder eine Netzzeitung, oder …
Müsste gehen.
ist doch völlig egal. Geht nicht darum zu überlegen, warum jemand was macht oder nicht, sondern um die Bereitstellung einer technischen Möglichkeit, die jeder nutzen kann wie und warum er möchte.
Freifunk bietet Möglichkeiten an, Freifunk ist kein Vormund und entscheidet nicht was wer sinnvoll oder nicht macht.
Immer diese Bevormundungen kotzen mich an.
Stimmt, wenn du sagst würdest, du willst ein neues, eigenes Netz bauen, in dem nur die Netzteilnehmer Zugriff auf bestimmte Dinge haben, wäre es völlig egal und ich hätte die Frage auch nicht gestellt. Dein Vorschlag betraf aber die Infrastruktur von Freifunk im allgemeinen und damit musst du auch mit meiner Frage leben.
Du fragst nach Sinn und Inhalt, Freifunk ist aber FREI + Funk und Technik, ohne Frage nach Inhalt.
und dieser Thread lautet „Technische Änderungen“ nicht „inhaltliche …“
Du kannst ja einen neuen aufmachen für „DIskussion über Sinn oder nicht von Technik allgemein und speziell etc.“
Unzählige Probleme. Das fängt schon dabei an das wenn du Supernode auf einer VM machst und der ganze Host wird beschlagnahmt (es gibt genug Deppen), haftest du oft für den Ausfall und bist ggf. Regresspflichtig gegenüber den anderen VM-Betreibern. In manchen Verträgen ist das geregelt in anderen nicht. Die interessiert nicht warum, wieso, gerechtfertigt oder nicht. Die Abuse-Problematik bleibt ebenfalls die gleiche (Vertrag gekündigt spätestens nach dem 3. Abuse). Ich könnte jetzt noch unendlich weitere Aspekte aufzählen, warum ich denke das es bei dem bestehenden Konstrukten aus FFRL-Exit und VPN-Anbietern bleibt.
@Arwed das sind rechtliche Aspekte, gehört in extra Thread, hier geht es um Technik, alles andere muss ggf. die Gruppe vor Ort entscheiden. Verquick hier bitte keine Themen die separiert gehören.
Edit
m.E. sollte eine klarte „Diskussionshierarchie“, auch getrennt nach Topics, eingehalten werden:
was ist technisch machbar
was davon ist rechtlich zulässig
was von dem, was übrig ist, ist moralisch vertretbar
das, was dann noch über ist, kann derjenige, der Lust hat, versuchen.
Aber bitte nicht alles im selben Thead diskutieren.
Das hört sich jetzt aber nicht nach einer technischen Änderung an, oder?
Ich halte das in #7 beschriebene Szenario einer 3fach gestaffelten Ausleitung (nach AS-Listen) nach wie vor für gangbar.
Und den Performance-Lack beim Roamen „von Wolke zu Wolke“ muss man halt in Kauf nehmen. Es wäre ja kein abriss.
im Zweifel einen „offenen“ Round-Robin betreiben.