Was nun: Störerhaftung komplett(?) gekippt

Das ist meines Erachtens genau der richtige Thread für die Diskussion: Spekulation über das, was aus einer inzwischen gelakten, noch ziemlich unverbindlichen Beschlussvorlage wird, die handwerkliche Fehler hat…

Als Freifunkende können wir uns natürlich ganz freundlich freuen, solange der FUD vom den Gesetzgebung noch ein wenig aufrecht erhalten wird und das Thema „schön lang“ als Sau durch’s Dorf getrieben wird.

1 „Gefällt mir“

Wie in

angemerkt wurde, sind wir nun an dem Punkt:
Die Störerhaftung ist faktisch weg (von ein paar akademischen Überlegungen abgesehen)

Derzeit habe ich hier auf der Liste (Vollständigkeit desgignbedingt) für den Gluon-:Freifunk

  • Framework für eine zuverlässige (securitybugfixes) Firmware für Clientnetze
  • Gigantische Toolchain von großen Installationen ohne unerfreuliche Closed-Web-APIs
  • funktionsfähiges Client-Roaming innerhalb der lokalen Wolken
  • Gewissheit als Client bei „Freifunk“ ein freies Netz ohne absurde Captcha-Seiten zu bekommen.
5 „Gefällt mir“

Ich fasse es nochmal anders:

  1. wir haben die derzeitige Infrastruktur in den Domains
  2. wir verfügen über Erfahrungen für sehr viele Topologien
  3. wir kennen die Limits des 24/7-Betriebes genauso wie Skalierungsgrenzen
  4. wir haben organisatorische Strukturen, die weit über den Bereich „nur Technik“ hinausgehen, um Projekte zu organisieren und sind dabei mit anderen vernetzt
  5. Viele Knotenbetreibende schätzten bislang nicht nur den Schutz vor Abmahnkanzleien, sondern auch die Unterschiede bei Ermittlungen im Strafrechtsbereich.

Was könnte man nun tun, um diese „neue“ Freiheiten zu nutzen?

a) Traffic direkt aus Supernodes ausleiten,
b) Traffic direkt auf den lokalen Wan-Uplinks ausleiten.

Nur setzt es bei a) an den Supernodes voraus, dass Hoster-Abusedesks die Erklärung „offenes Wifi-VPN“ akzeptieren und nicht mehr jede Woche mindestens 2 VMs „zugesperrt“ werden wie anno Dunnemal bei Netcup und Webtropia „nach dem zweiten Abuse-Ticket“.
Und bei b) wird’s schwierigst mit PublicIPv6. Nicht nur weil viele Anschlüsse heute nach wie vor kein IPv6, mit Technicolor7200er auch keine Prefix-Delegation funktioniert und fixe Ipv6 geht natürlich gar nicht. Faktisch würde man dann v6NAT brauchen… und trotzdem noch haufenweise lokale RA/Prefixe, die nur innerhalb der lokalen Wolke gehalten werden. Viel Spass dann bei Wolken mit mehreren Uplinks…

Sprich: Ein Hotspot-Szenario mit Einzelroutern im Hinterzimmer kann bedingt profitieren, aber komplexe Setups mit mehreren Uplinks in einer Wolke sind -meiner Ansicht nach- noch nichtmal theoretisch so erschlossen, dass man wüsste, in welche Richtung da nun z.B. für Gluon entwickelt werden könnte.

Will sagen: Wir können auch im Freifunk davon profitieren, um Dinge besser/einfacher zu machen.

Wir wissen nur noch nicht, wie man lokale Ausleitungen auf Supernode und Consumer-Dialup-Ebene technisch sinnvoll nutzen können, außer „mehr Speed für Clients bei gleichzeitig weniger Kosten im Backend“.

4 „Gefällt mir“

Ich habe in Berlin auch mit @monic über dieses Thema gesprochen.

Ich fände es technisch interessant lokales Ausleiten zu ermöglichen. Also nicht an irgendwelchen Gateways, sondern an den Knoten direkt. Natürlich nur auf expliziten Wunsch des Knotenbetreibers und mit einem dicken Achtung versehen und auch nur für Clients, die in der lokalen Wolke hängen. Das geht aber nur, wenn man Batman beibringen könnte, dass ein als Batman-Gateway deklarierter Knoten, dies nur in der lokalen Wolke bekannt geben soll, nicht aber an per VPN verbundene Knoten. Sonst brechen Netze, die wirklich funktionieren sollen und von ihren Betreibern nicht nur als Testnetze angesehen werden, in der Praxis recht schnell zusammen, weil sich irgendwelche Knoten am anderen Ende der Stadt einen nur über ADSL angebunden Knoten als Gateway suchen.

Ich sehe es als Chance, unser Netz weiter zu skalieren, weil man weniger Bandbreite an den Gateways bereit stellen muss. Roaming ist trotzem weiter möglich und einheitliches IPV6 wird auch weiterhin über die Gateways abgewickelt. Lokales IPV6 könnte dazugeschaltet werden, sofern verfügbar.

Themen durch Moderation zusammengefügt, MPW.

Hallo,

der Titel ist natürlich provokant. Aber diese Einschätzung teilend, stellt sich mir die Frage, ob in bestimmten Situationen Freifunk noch „überzeugungsfähig“ ist.

Jetzt mal ganz losgelöst von dem untereinander vermashten Bürgernetz, sondern eher auf den Teilbereich „freier WLAN-Zugang“ für Alle betrachtend: warum sollte ich meinen Anschluss nicht direkt freigeben, bei nun entfallenem Risiko?

Ich schalte ja gerade an verschiedenen Standorten unserer Wohnbereiche für Menschen mit Handicap Freifunk an und werde auch dabei bleiben.

Aber helft mir mal ein bisschen auf die Sprünge, warum und wie ich Interessenten mit ähnlichen Vorhabeplänen überzeugen kann, auch FF zu nutzen und zu fördern.

Oder hat sich das in der Sparte „freier WLAN-Zugang“ erledigt und ist obsolet?

Liebe Grüße,

Jürgen

hi

nehmen wir mal du machst das und es passiert etwas GANZ schlimmes (mehr als bisschen Urheberrecht, setzt hier einfach irgendwas ganz ganz böeses ein ich möchte keine Standartbeispiele jetzt bringen) bei Freifunk steht erstmal eine Community/Verein/whatever dahinter wo sich die Kripo oder wer auch immer ermittelt hinwendet und dann schon sieht, das da wohl offenes WLAN für die gemeinschaft betrieben wird, bei deinen offenen WLAN stehen sie Sonntag morgen um 5Uhr mit 5 Polizeiwagen und Durchsuchungsbefehl vor deiner Haustür. Auch wenn man nix zu verbergen hat (hat man das wirklich nicht?) ist das doch recht unangenehm wenn man halb nackt die Tür öffnet und so überrascht wird ;). Die Nachbarn denken sich dann vermutlich auch ihren Teil :wink: Ob die dann einfach wieder abziehen wenn du denen sagst „Ich hab mein WLAN aber offen“, also ich bezweifel es :wink:

mfg

Christian

2 „Gefällt mir“

Schau doch mal in diesen Thread:

(alternativ könnten wir natürlich auf jede Frage hier auf das entsprechende Posting des anderen Threads verweisen.)

Andreas, dann mach den hier doch zu, dann geht es weiter im nun mehr nicht mehr „what if“ :slight_smile:

Bei Freifunk geht es nicht nur um offenes WLAN, sondern um den Aufbau eines freien Netzes ohne die typischen Drangsalierungen durch den Provider, d.h. keine Drosselungen, keine wild wechselnden IP-Adressen und möglichst auch kein seit 20 Jahren obsoletes IPv4-only-Netz.

1 „Gefällt mir“

Danke, dass Du nochmal eine gekürzte Version von Felix’ darstellung verfasst hast.

Dafür gibt es einen offenen PR seit vielen Monaten im Gluon.
Ich betrachte es als gelöst, da die Diskussion doch derzeit nur über die „Codequalität“ (und den üblichen foo) geht.
Da nochmal die Grunsatzdiskussion in Richtung „ungelöst“ aufzubrechen finde ich ziemlich unfair jplitza gegenüber.

Für V4 geht es mittels HopPenalty+lokalem dhcpd+iptable-rules an den vpn-Links derzeit schon.

Das IPv6-Problem ist jedoch ungelöst, zumal der Volumen-V6-Anteil (Google, Facebook, Portale der Erwachsenenbildung) gefühlt bei über 50% liegt (lange nicht mehr nachgeschaut…).
Und da sehe ich keine Lösung, die nicht zumindest extra-eklig ist (Ipv6-Nat, Sixxs…)

Die Beiträge von #101 bis #106 hier waren vorher unter dem Titel „
3. Gesetz zur Änderung des TMG - braucht es dann noch Freifunk?
“ in einem separaten Thema und wurden zusammengeführt, weil es um exakt dasselbe Thema geht.

2 „Gefällt mir“

Roaming im Sinne von Handover von AP zu AP im ESS wird funktionieren. IPv4-Verbindungen werden spektakulär scheitern, denn im ESS wird beim AP-Wechsel keine Adresserneuerung vorgenommen. Bedenke, batman_adv manipuliert DHCP-Pakete; wenn AP 1 lokal ausleitet, die anderen nicht, wüßte ich gerne, wie die 192.168.180.13/24 mit GW 192.168.180.1, die der Client von AP 1’ batman_adv im GW-Mode bekommen hat (in der Annahme, daß auch für batman_adv der lokale GW das beste ist), an AP 2, der über die zentralen GWs ausleitet und insofern in 10.12.0.0/20 arbeitet, funktionieren soll.

Vielleicht übersehe ich was, aber mir ist derzeit schleierhaft, wie in batman_adv-Netzen lokale Ausleitung funktionieren könnte.

ESS (ESSID) bedingt physisch eine L2-Kopplung aller APs und logisch die Nutzung der gleichen L3-Parameter. Wenn lokal exitende APs statt mit „my.ssid“ mit „lokal.my.ssid“ laufen würden, klappte dies, vorausgesetzt, zwischen allen lokal ausleitenden APs liegen hinreichend „Fahrradminuten“, daß von WLAN auf Mobilfunk gewechselt wird.

IPv6, davon hat batman_adv noch nichts gehört; dies hat Vor- und Nachteile. Vorteil: irgendwo in der L2-Wolke kann jemand RAs reinplärren. Nachteil: irgendwo in der L2-Wolke kann jemand RAs reinplärren. Das „lokal zugeschaltete IPv6“ würde sich das Gerät dann mehr oder minder lange merken und ggf. auch über andere APs nutzen wollen; vermutlich ähnlich erfolgreich wie bei v4.

Reden wir über dasselbe, stillgelegte, SixXS?!

Leider geht meine Nummerierung nur bis 97? FTR, so gut die Zusammenführung gemeint gewesen sein mag, wenn man den Reagenzglas-Thread liest, fällt man zwangsläufig ob nicht zusammenpassender folgender Beiträge auf die Nase; ich denke ein weiteres Mal, daß der moderierende Eingriff hier mehr kaputtgemacht hat, als die Ausgangssituation vermocht hätte. Bitte lassen …

1 „Gefällt mir“

Es ist nicht sinnvoll, in zwei Threads über das gleiche Thema zu diskutieren. Ich sehe da keinen Grund zur Beschwerde.

2 „Gefällt mir“

Neben allem was technisch nun möglich wäre, oder auch heute schon sofort möglich ist (Stichwort: „Alt-Exit SSID“) gluon-alt-esc: add client + provider package by T-X · Pull Request #1094 · freifunk-gluon/gluon · GitHub):

Freifunk kann jetzt auch dort profitieren, wo Leute in der Vergangenheit nicht mitmachen wollten (oder keinen Uplink spenden) wollten, weil sie befürchteten „Dass das mit dem Freifunk-VPN vielleicht doch mal nicht funktioniert“ (im Sinne von: „Und wenn ich doch eine Abmahnung bekomme“).

Zumindest könnte man jetzt bei denjenigen nochmal nachhaken. (im Schlimmsten Fall müssen die sich dann eine andere Ausrede ausdenken, warum sie keine Bandbreite teilen möchten.)

2 „Gefällt mir“

Erstmal eine riesen Massenpanik würde ich sagen?! Keiner weiß mehr wohin mit seinen Gedanken!!

Nein,

Mit dem neuen Releasetag „gluon-next“ ist es von T-X rebased worden und wäre jetzt durchaus einsetzbar, meiner Einschätzung nach. Also nicht „in der Euphorie mal als ProofOfConcept hingerotzt“ und dann nie wieder angefasst.

Es ist also durchaus „überlegt“ veröffentlicht worden, ist ein valider Pull-Request und wird auch nach wie vor aktiv maintained.
(Ich habe es aber nicht selbst ausprobiert)

Ich denke eher genau das Gegenteil ist der Fall. Mutige Power-Freifunker können die Gateways entlasten indem sie auch einen Teil lokal ausleiten. Ich denke nicht, dass die ängstlichen dadurch eher zu Freifunk kommen. Aber es wäre schön, wenn du Recht behieltest.

Den PR hatte ich gar nicht mitbekommen. Habe den im PR kommentiert. Ich fände auch eine Variante mit lokalen Batman-Exit besser.

ich erlaube mir mal meine Erinnerung aus dem letzten Gluon Developer Meeting zu diesem Pull request beizutragen.
Der Haupt-Maintainer von gluon hat sich ziemlich deutlich gegen dieses Paket ausgesprochen, und ich finde ihr solltet auch stark darüber nachdenken. Das folgende enthält auch meine Meinung, aber der Grundgedanke wurde von jemand anderem in besagtem Meeting geäußert.

Freifunk ist ja eben gerade NICHT nur der einfache Zugang ins Internet. Dieses Paket führt aber weiter dazu, dass Freifunk nur darauf reduziert wird, dass es kein Mesh-Netzwerk mehr ist, sondern eine Firmware für schnöde „Hotspots“ wie sie jeder kommerzielle auch anbietet.
Das kann ich aber doch genauso gut mit dem Gastzugang meines routers machen, wenn ich nur das will - den Freifunk-Namen dafür missbrauchen - ist das doch Mist?!

kurz: es ist sehr unwahrscheinlich, dass das in Gluon aufgenommen wird.

3 „Gefällt mir“

Wieso würde das Paket Freifunk darauf reduzieren?

Ich habe das so verstanden, dass damit einerseits Pakete direkt rausgeleitet werden ins Internet, andererseits aber das maschen und die Verbindung zum Freifunk erhalten bleibt. Dies ist durch den Wegfall der Störerhaftung erst möglich.

Klingt perfekt. Wo genau ist der Nachteil?