<p dir="ltr">Mal n Vorschlag der evtl. viel zu einfach ist.<br>
Asylbewerberheime brauchen uns, wenn man ehrlich ist, eh nur als Hotspot-Anonymisierungsdienst also scheiß auf Vernetzung.<br>
Ein Freifunkrouter, der tut was er immer tut und ein ungeflashter Router, der tut was er normal Router tut. IPs von 192.168.100.1 - 192.168.100.256 vergeben und ins ff-netz routet.<br>
Darüber wären wir ne dicke Stange überflüssiges Rauschen und die Betreiber die Störerhaftung los.<br>
Auf Dauer die Lösung, welche unsere Server schont, unser Netz am laufen hält und somit auch den Ruf von Freifunk.<br>
Jauh soweit meine Meinung. :)</p>
<p dir="ltr">LG Alex</p>
<div class="gmail_quote">Am 10.09.2015 14:52 schrieb "Christian Dresel" <<a href="mailto:fff@chrisi01.de">fff@chrisi01.de</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Guten Tag<br>
<br>
ich finde die Idee zumindest einfacher zu verstehen und umzusetzen, zu den Nachteilen schreib ich gleich mal was drunter<br>
<br>
Am 10.09.2015 um 10:11 schrieb delphiN:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Am <a href="tel:09.09.2015%2023" value="+49909201523" target="_blank">09.09.2015 23</a>:41, schrieb Tim Niemeyer:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:NetworkForRefugees" rel="noreferrer" target="_blank">https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:NetworkForRefugees</a><br>
</blockquote>
Vielen<br>
Dank!<br>
<br>
Ich habe noch einen weitere Möglichkeit zur Diskussion:<br>
Der neue Internet-Zugangs-Server wird zu einem einfachen anonymen<br>
VPN-Provider. Der Rest kann dann so bleiben wie er ist. Man würde dann<br>
also einfach ein paar neue Gateways anlegen und gezielt "über" den<br>
großen Unterkünften platzieren um damit dort neue, schnelle Hoods zu<br>
schaffen.<br>
<br>
Nachteile:<br>
- - Der gesamte Broadcast-Overhead der neuen Hood ginge (wie bisher<br>
auch) über die DSL-Anschlüsse der Einrichtungen.<br>
</blockquote>
Ist die DSL Leitung da wirklich der Flaschenhals? Ich bin da noch nicht wirklich "drinnen" in dem Broadcastproblem auch wenn ich langsam mehr und mehr davon verstehe (danke Tim, in der U-Bahn hab ich da wieder einiges dazu gelernt ;) Beispiel mit Netzwerkdrucker hats bei mir dann geklingelt).<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- - Es kann passieren, dass statt den schnellen Neuen ein altes<br>
langsamer Gateway bei der Einrichtung eingestellt wird. (DHCP-Proxy,<br>
der gezielt langsame Gateways ausbremst?)<br>
</blockquote>
das Problem haben wir doch sowieso schon, ich erinner an den Samstag vor ein paar Wochen als nue1 keine Verbindung mehr nach Berlin hatte und den halben Samstag dadurch das Internet lahm gelegt hat (zumindest denjenigen die von nue1 eine IP bekommen haben, mit meinen heutigen wissen würde ich mir einfach eine manuelle IP verpassen und auf einen anderen Gateway ausweichen, dazu brauchts dann aber etwas tiefergehende Kenntnisse).<br>
Idee ohne wissen obs technisch möglich ist:<br>
Man prüft auf jeden Gateway regelmäßig ob denn noch eine Internetverbindung besteht. Sollte dies aus welchen Grund auch immer nicht mehr der Fall sein (siehe oben wo Berlin wohl eher schuld war als nue1, das FFF-Netz ging ja nur Internet nicht mehr):<br>
1. Schritt: Der Gateway gibt keine weiteren IPs mehr aus. Jeder Client der jetzt neu verbiendet landet auf einem anderen Gateway (dazu sollten dann natürlich genug Reserven vorhanden sein -> wir brauchen wieder mehr Gateways) wenn der Endanwender also flucht weil sein Internet nicht geht und sein Handy/PC/Laptop etc. neu startet sollte dies schon reichen das er wieder Internet hat.<br>
Diesen Schritt halte ich technisch für absolut machbar, beim 2. muss ich euch fragen ob sowas technisch geht.<br>
2. Schritt: Der Gateway nimmt nun einigen Clients die IP wieder weg, welche sich somit eine neue von einem anderen Gateway holen, sagen wir mal pro Minute 5 Clients weniger. Ist nur die Bandbreite überlastet wird irgendwann die Prüfung ob noch Internetzugang besteht wieder erfolgreich sein und man kann aufhören weiteren Clients die IP wegzunehmen. Ist eine größere Störung vorhanden wird irgendwann kein Client mehr eine IP von dem Gateway haben und jeder Client weicht auf einen anderen Gateway aus.<br>
Leider ist mir nicht bekannt ob dies mit DHCP umgesetzt werden kann, ich weiß das es beim verleihen von IP Adressen Leasetimes gibt aber ob nachträglich die IP zurückgenommen werden kann? *Schulterzuck*<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Vorteile:<br>
- - Firmware und Gateways müssen quasi nicht angepasst werden.<br>
- - Bei einem Ausfall des neuen Servers würden automatisch bestehende<br>
Gateways übernehmen.<br>
- - Wir könnten ganz einfach diesen VPN-Tunnel auch für bestehende<br>
Gateways verwenden, damit auch bestehenden Hood von dem schnellen<br>
Zugang profitieren können.<br>
</blockquote>
wie gesagt, ich finde die Vorteile überwiegen den Nachteilen, ist aber nur meine Leihenhafte Meinung ;)<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Was denkt Ihr?<br>
delphiN<br>
<br>
- -- <a href="mailto:freifunk@wunschik.net" target="_blank">freifunk@wunschik.net</a><br>
<a href="mailto:delphiN@jabber.ccc.de" target="_blank">delphiN@jabber.ccc.de</a><br>
Mitglied: Freie Netze e.V., CCC, Piratenpartei<br>
<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.14 (GNU/Linux)<br>
<br>
iQIcBAEBAgAGBQJV8TslAAoJEGuH2dOBPapCcxQQAI1ImkLqI120YsGGWA0FHIH9<br>
RVNLfO2Fi4UTwfYHTk61VXnFYuT3SbrbVHsU2uvskdfw+2AhHQRuE/u2Lp7Dei5q<br>
PValH/8U6IracJEWa9I5c4NpnYOC2n/b6jayc0ZlDtT9otpkJTg4Rt6ANCMOlGHe<br>
p/yVKxXHcHBcE2lbFqm4wx6+W7cOF/r2Dsb1In43mBCAylAEnzmXHXm8U58pYqBS<br>
L5GnHrL3RlUv6z5F1Bsm2g5n4IME98lBwyDWCnYW1u7drQ/K013JnzZ2DYKjjyQx<br>
BkyQTM8UeiqZJuVwlyeE3bsJ6hvNaLo+ZcuqR1v3wrB2NuEmbRJjL3v/1u3EMdke<br>
TI5IcTaBgXCDDuclHH9PM1YyywC4YDrRf4t9H4fIxUY0YTF+nS30zgq2zNyofTWa<br>
GNB85YZMTiYCtyncUts1ax9nWK4j6bVXh6gD48siakqVqQ4ffJLUxwSjKdl5KtIx<br>
MB5bZYjg3MLDKbPjlTUhkbfDLCmvcFWSc3KE152mWPfbHKjtBoD6yzVdZvxOlD68<br>
DMxboxGCOdNAgbzVTR10hcILd2jTpkkpzUZVR+HEd5xXOPFkXjZhed5IbxLXHVsI<br>
bwQP/6F5KnRWc+jLbddBztozeSIF+6E0FtVX+yGu3VUjAkfa1rEkRepLpbScSwK+<br>
TKx/rzMV1BKF8xv/KMta<br>
=YMuJ<br>
-----END PGP SIGNATURE-----<br>
</blockquote>
<br>
-- <br>
franken-dev mailing list<br>
<a href="mailto:franken-dev@freifunk.net" target="_blank">franken-dev@freifunk.net</a><br>
<a href="http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net" rel="noreferrer" target="_blank">http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net</a><br>
</blockquote></div>