
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hallo,</div><div><br></div><div>fup2 Bonner Liste - ggf. interessiert's ja noch andere :-)</div><div>Antworten siehe unten.</div><br><div><div>Am 05.02.2012 um 05:05 schrieb Linus Lüssing:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Sat, Feb 04, 2012 at 05:24:47PM +0100, Jan Lühr wrote:<br><blockquote type="cite">Hallo Linus,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">leider ist unsere Wiki aktuell im Umbau, s.d. wir aktuell keine Struktur haben, in der Du den Artikel findest :-(.<br></blockquote><blockquote type="cite">Da weiterhin Jabber meine Nachricht verschluckt zu haben scheint, kurz per E-MailL:<br></blockquote><blockquote type="cite"><a href="http://kbu.freifunk.net/index.php/FSM-Dynamisches-Bridging">http://kbu.freifunk.net/index.php/FSM-Dynamisches-Bridging</a><br></blockquote><font class="Apple-style-span" color="#006312"><br></font></div></blockquote><br><blockquote type="cite"><div><br>Hmm, ich hatte noch Nachrichten auf dem Handy gefunden und die<br>erst später gesehen, nachdem ich dir per jabber vom Laptop aus<br>geantwortet hatte. kA ob das dort nun alle waren, hmm.<br><br>Na ja egal. Hab's mir jetzt mal angeschaut das FSM von dir. Und<br>wenn ich das richtig sehe, ist es ziemlich identisch zu dem<br>Vorschlag, den du auch am Telefon schon gemacht hattest, oder<br></div></blockquote><div><br></div><div>Ja.</div><br><blockquote type="cite"><div><br>Also auf jedenfall ist das ganze um einiges übersichtlicher als<br>mein wirrer Kram *hust* :). Und jau, es hat bei weitem weniger<br>Timeouts und der einzige Timeout, der da momentan drin ist, ist<br>eigentlich unkritisch (`nodeTimeOut`), da wie du dort schon<br>anmerktest, batman-adv vorher greifen sollte bei Pfad/Link<br>Problemen. Also ist TBD.1 vermutlich eher unkritisch - das Minimum<br>dort sollte vom OGM Intervall und/oder vom batman-adv purge<br>timeout (=3min.) abhängen, also sind deine 3min. als Minimum schon<br>gut geschätzt - aber jau, länger warten tut eigentlich auch nicht<br>weh, weil's wohl ne unkritische Ressource ist.</div></blockquote><blockquote type="cite"><div>Und bei ne'm<br>DoS-Angriff würde vll. auch sogar ein 3min. timeout nicht helfen,<br>hmm. Aber ist auch eher unwichtig erstmal.<br></div></blockquote><div><br></div><div>Puh - ich denke, bei einem DoS-Angriff sind Timer das einzige, was helfen kann. Aber dann brauchen wir weitere (z.B. die maximale Zahl neuer l2tp-Links pro Minute)</div>Das Thema DoS würde ich aber gerne mal außen vorlassen.</div><div><br><blockquote type="cite"><div><br>Warum gibt es TBD.2? Hatte es so verstanden, dass `removeL2TPLink`<br>das eigentlich schon machen sollte.<br><br>Glaube wanUP und wanDown müsste man noch etwas<br>ausführlicher/komplexer spezifizieren. Wenn man nur den<br>Link-Status nehmen würde... da würde es bestimmt ne Menge Leute<br>geben, die da evtl. mal etwas falsch zusammen stecken. Oder deren<br>Firewall blockt irgendwie den intracity-VPN Aufbau. </div></blockquote><div><br></div><div><div>Was imho relativ egal wäre, da in diesem Fall die VPN Verbindung nie aufgebaut wird, d.h. der Init-State nie verlassen wird.</div><div>Ich</div><div><br></div></div><blockquote type="cite"><div>Oder deren Internetverbindung wackelt regelmäßig, weil z.B. die Putzfrau immer <br>um 10:00 morgens den Stromstecker des DSL-Modems stattdessen für den<br>Staubsauger benutzt :P. Da kann (und wird) alles mögliche<br>passieren, und würde jener Router würde dann sicherlich für einige<br>Leute in der Umgebung dann trotzdem noch zum schwarzen Loch<br>werden (auch wenn nicht mehr ganz so tragisch wie bei meinem<br>ersten Vorschlag).<br></div></blockquote><div><br></div><div>Puh - das kann natürlich zu einem Problem werden - ich würde den Punkt aber gerne erstmal außen vorlassen, mein Gedanke:</div><div>-> Wan-UP ist einfach zu implementieren (OpenWRT erlaubt einen entsprechenden hook)</div><div>-> Der Fall (sollte) in erster Linie einzelne Router (<< 5 betreffen). Hier helfen ggf. händische Workarounds</div><div><br></div><div>Das wäre (imho analog zu DoS) ein Thema, das wir mit Prio-2 angehen sollten.</div><div><br></div><blockquote type="cite"><div><br>Ein wanDown müsste außerdem auch noch ein StopDhcpServer<br>beinhalten, oder?<br></div></blockquote><div><br></div><div>Ja.</div><br><blockquote type="cite"><div><br>Hmm, downloadNetConfig und establishVPN würde ich glaub' ich nicht<br>parallel machen. So würde es beides über das Internet gezogen<br>werden, oder? downloadNetConfig würde ich vorschlagen über das<br>intracity-VPN dann, also nach dem establishVPN zu machen, um<br>zumindest vor anonymen Trollen aus dem Internet geschützt zu sein,<br>die sich mal eben alle Adressen und Subnetze holen.<br></div></blockquote><div><br></div><div>Nacheinander geht natürlich auch - bringt aber kaum Sicherheitsgewinn:</div><div>-> Ein "Saboteur" kann immer über das VPN kommen.</div><div>-> Aktuell benötigst du zum Download MAC-Adressen als Username & Password. Bots bleiben also außen vor.</div><div><br></div><div>Dennoch hat ein sequentieller Ablauf den Charm, dass die Join-Punkt entfällt, das ganze also einfacher zu bauen wird.</div><div><br></div><blockquote type="cite"><div><br>downloadNetConfig würde ich dort in den Klammern neben 'Subnet,<br>Range für dhcp' noch IP Adresse im Transfer-Netz, also im intracity-VPN,<br>noch mit rein schreiben.<br></div></blockquote><div><br></div><div>Ändere es einfach in der Wiki :-)</div><br><blockquote type="cite"><div><br>Außerdem stellt sich noch die Frage, ob wir einen gewissen<br>Zusammenhang zwischen Transfer-Netz-IP und zugeiltem Subnetz für<br>die WLAN-Wolke haben wollen. Also sowas was ich ein wenig wirr<br>unter 'Adressing' beschrieben hatte. Z.B. würde dann mein TP-Link<br>Router dann in Lübeck für das Transfer-Netz die 10.130.0.22/24<br>bekommen, und dann in seiner Wolke selber 10.130.22.1/24 haben und<br>10.130.22.0/24 per DHCP anbieten. Vorteil: Man braucht im<br>intracity-VPN nur noch OSPF für die default-Routen / Internet-Exit-Gateways.<br></div></blockquote><br><div>Können wir überlegen. Ist eigentlich eine gute Idee. Das würde zugleich die Traffic-Mange auf dem VPN-Link reduzieren.</div><div><br></div><div><br></div><blockquote type="cite"><div>Hab' auch nochmal überlegt, vom Prinzip her wäre das ja das gleiche,<br>ob man jetzt seine Subnets/IPs sich von 1 bis x web servern im<br>intracity-VPN oder von 1 bis x DHCP servern im intracity-VPN holt.<br>Sollte dann quasi ich gleich robust und "dezentral" sein. Und wäre<br>dann nur noch eine Frage des Implementierungaufwandes, wenn ich<br>nicht sonst noch weitere Nachteile von einem der beiden übersehe.<br>In OpenWrt hat man den Vorteil, dass man beim Erhalt eines DHCP<br>Leases gleich seine eigenen Skripte darauf hin laufen lassen kann.<br>Und der DHCP Server im intracity-VPN sich dann die Vergabe schon<br>selbstständig merkt. Ein paar Layer höher per HTTP müsste man das<br>dann wohl noch den ganzen Reservierungsprozess noch<br>implementieren, oder (okay, wäre auch nicht so viel, aber<br>trotzdem)? Hmm, vll. klingt das konfigurieren per DHCP noch etwas<br>seltsam/ungewöhnlich, sehe jetzt aber noch keine Nachteile dadran<br>und ich glaube wir kriegen damit schon eine Menge "geschenkt".<br>Oder fallen dir noch Nachteile oder extra Aufwand bei der DHCP<br>methode auf?<br></div></blockquote><div><br></div><div>Die Idee hat - wie fast jede gut durchdachte IPv4-Adress-vergabe Strategie - die Eigenschaft, dass die Adressen schnell ausgehen können.</div><div>Mir kommen an sich noch 2 andere Ideen in den Sinn.</div><div>1. Das Transfer-Netz ist IPv6 Only (hat einen gewissen Charme, ist aber komplexer)</div><div>2. Intracity arbeitet nur auf OSI-3 und baut p2p-Links zum Server auf, die die default-Route setzen.</div><div>(Vorteil: Wenig komplex, Nachteil: Zentrale Struktur, Sternförmiges Routing)</div><div><br></div><div>Nichts destro trotz gefällt mir Vorschlag 2. fast am besten, da wir uns in der Anfangszeit viel Komplexität sparen (kein OSPF, keine Skalierungsprobleme auf Intracity-VPN, keine IP-Vergabe außerhalb von OpenVPN für das Transfernetz), so dass ich damit fast am liebsten Anfangen würde.</div><div><br></div><br><blockquote type="cite"><div><br>Zum Weglassen des batman-adv gateway Features hatte ich ja schon<br>gesagt, da ist der Nachteil dann die geringere<br>Ankunftswahrscheinlichkeit oder höhere Broadcast-"Verpestung" der<br>WLAN-Mesh-Wolke, je nachdem, wie man die Anzahl an<br>Rebroadcasts einstellt in batman-adv. Und sehe jetzt noch nicht<br>ganz die Nachteile, die ein Einschalten des Gateway-Features für<br>DHCP hätte.<br><br><br>Bei L2TPv3 kann man sich den UDP header auch sparen. Und weil's in<br>tinc ja schon drin ist, sollte es ohne den UDP header auch keine<br>Probleme mit Firewalls oder NAT geben. Hab' letztens nochmal<br>dieses Kommandos stattdessen benutzt:<br>l2tpv3tun add tunnel remote 141.83.153.180 local 141.83.65.45 tunnel_id 1 peer_tunnel_id 1 encap ip<br>l2tpv3tun add session tunnel_id 1 session_id 1 peer_session_id 1<br>(und glaube l2tp patches wurden immernoch nicht in die ip-utils<br>gemerged, kA ob das noch kommen sollte/wird)<br></div></blockquote><div><br></div><div>Ja - sehe ich auch so.</div><div><br></div><blockquote type="cite"><div>Unterschiedliche Ports brauchen wir dann also nicht, dann<br>unterschiedliche Tunnel IDs (die eigentlich Control Connection IDs<br>heißen sollten bei l2tpv3 laut RFC) stattdessen für ein Knoten Paar.<br>Bei den Session IDs glaube ich brauchen wir auch zwei<br>verschiedene, klingt irgendwie so in den RFCs, dass Datenpakete<br>nach der Session ID und ohne Tunnel ID übertragen und zugestellt<br>würden - müsste man aber nochmal testen.<br><br>Zumindest nach dem was l2tpv3tun (kA wie das bei openl2tp<br>aussieht) an Parametern vorschreibt, bräuchten wir dann also wirklich<br>ein Handshaking Protokoll zum Austausch der Peer Tunnel/Session IDs.<br>Hmm, mich wundert nur ein wenig, dass die Grafik auf<br><a href="https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol#L2TP_packet_exchange">https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol#L2TP_packet_exchange</a><br>einen automatischen Austausch der Peer Tunnel/Session IDs<br>suggeriert - aber der Artikel ist eh ein wenig komisch und sehr<br>L2TPv2 beschränkt / falsch für L2TPv3<br></div></blockquote><div><br></div><div>Fies - sollte aber nicht schwer zu bauen sein.</div><br><blockquote type="cite"><div><br>Vom Prinzip her, mit den mehreren Layer 3 Subnetzen pro Wolke muss<br>ich dir aber recht geben, dass mein erster Ansatz und dessen<br>Vorteil, das sich zwei Clients in der WLAN-Mesh-Wolke dann immer<br>über den batman-adv-besten Weg dann finden, die extra Komplexität<br>nicht rechtfertigt. Insbesondere, weil's ja eigentlich nicht<br>kritisch ist, jener nicht-optimale Weg, weil wohl davon<br>ausgeganegn werden kann, dass der Pfad über die default-Route zwar<br>länger aber immernoch bei weitem gut genug ist. Und den<br>Hauptnachteil zum 4.3 Szenario haben wir damit ja eliminiert,<br>nämlich die Möglichkeit zu komplett unnutzbaren Routen bzw. danach<br>dann das neues DHCP Lease holen (=Verbindungsabrüche) im Fall von<br>Roaming.<br></div></blockquote><div><br></div><div>Ok. Also rann ans Werk :-)</div><div><br></div><blockquote type="cite"><div><br>Ansonsten war ich noch wegen zwei weiteren architektonischen<br>Varianten für 4.4 am überlegen:<br>a) Könnte man später noch mit Routen-Announcements im<br>Falle von IPv6 rumspielen? Z.B. wenn ich zwei solche Knoten, zwei<br>Gateways mit intracity Anbindung hätte:<br>Könnte ein Client dann zwar vll. eine IPv6 Adresse X/64 + default<br>Route immernoch bekommen, aber wenn der zweite intracity gateway<br>dann auftaucht, dass dann der Client eine extra Route für Y/64<br>bekäme? Mit radvd kann man ja noch hübsche extra Routen bekannt<br>machen... Oder wie genau verhält sich IPv6 bei mehreren<br>default-Routen und IP-Adressen/Subnetzen? </div></blockquote><div><br></div><div>Es gibt ein Tie-Breaking-Verfahren. RFC hab' ich gerade nicht im Kopf. </div><div>Je nach Verfahren (last-wins) hätte das nervige Folgen. Ich meine aber irgendwo im Hinterkopf zu haben, dass die OSI-2 Distanz mit einbezogen wird. Das wäre dann wieder besser.</div><div><br></div><br><blockquote type="cite"><div>Matthias, eigentlich<br>unser Layer 3 Spezi hier in Lübeck, hatte mir immer stark von<br>mehreren Adressen abgeraten... aber hmm, ich frage mich, ob die<br>ganzen Verfügbarkeitserkennungsmechanismen, wie ich meine sie im<br>stateless autoconfiguration RFC gelesen zu haben, in der Praxis<br>auch so funktionieren könnten.<br></div></blockquote><div><br></div><div>Ich denke, IPv6 ist hier praktisch kaum erprobt. Also das ideale Feld für Freifunk-Spielerreien.</div><div><br></div><blockquote type="cite"><div><br>und b) war ich noch am überlegen, ob es noch eine etwas andere<br>Möglichkeit zu unseren beiden aktuellen Vorschlägen gäbe. Nämlich<br>das man die DHCP Server für die Mesh-Wolken ganz in die Rechenzentren<br>verlagert. Und ein WLAN-Router, ein intracity gateway, dann nur<br>noch ein oder mehrere Tunnel zu jeweils ein oder mehreren<br>DHCP-Servern aufbaue. Dadurch würde man sich im Vergleich zu<br>meinem ersten Vorschlag das ganze DHCP-Server/batman-adv gateway<br>ein/ausschalten sparen, es würde dann "nur" noch um das dynamische<br>Tunnel auf und abbauen gehen. Wobei aber genau wie bei deinem<br>Vorschlag das Auf- und Abbauen zeitlich unkritisch sein sollte,<br>da auch hier wieder batman-adv das auf der ganzen Strecke, inklusive<br>den Rechenzentren-DHCP-Servern, regeln würde. Wenn du meinst es<br>könnte Sinn machen, diesen Ansatz noch ein wenig<br>auszuformulieren/diagrammisieren, kann ich das gerne noch machen.<br>Oder klingt das in deinen Ohren jetzt schon immernoch zu wackelig<br>oder hat schon ne Menge Nachteile, sodass wir doch lieber auf dem<br>alten Pfad, dem Umsetzen + ein paar Verfeinerungen deines letzten<br>Ansatzes, setzen sollten?<br></div></blockquote><div><br></div><div>Puh - ich denke, dieser Ansatz ist komplex. An sich ist - so wie ich dich verstehen - die Idee nur noch ausgewählte Netzteilnehmer DHCP machen zu lassen. (ob sie nun auf Nodes dezentral oder in einem RZ zentral betrieben werden) spielt imho keine große Rolle.</div><div>Ich finde es wird schwierig ein Verfahren zu finden, dass</div><div>a) Ausreichend Robust ist: auch ein Server in einem RZ kann ausfallen.</div>b) Nicht-Komplex ist: Es muss ohne großes Handshaking / Tie-Breaking erkennbar sein, wer wann einen DHCP fährt.</div><div><br></div><div>Ob wir hinterher einzelnes, die Probleme machen nicht mehr DHCP spielen lassen oder nur einige wenige DHCP-Nodes/Server identifizieren führt imho zum gleichen Ergebnis.</div><div><br></div><div>Ich würde uns ungern von diesen Bedenken aufhalten lassen - das instabile Nodes (egal in welcher Topologie) ein Problem sein, ist imho kaum verhinderbar (zumindest dann, wenn der wlan-Link mangels Strom oder durch Störung ausfällt). </div><div>Wichtig für den Anfang ist imho vor allem eine geringe Komplexität. Dann können wir Probleme identifizieren (z.B. instabile Nodes, Links, etc.) und nachsteuern.</div><div><br></div><div><blockquote type="cite"><div><br><br>Hrm, hehe, mal wieder viel Text geworden. Aber na ja, ich glaube<br>wir sind auf dem richtigen Weg.<br></div></blockquote></div><br><div>Ich auch :-) - evtl. könnten wir ja mal eine Hackathon machen um die ganzen Dinge zu versuchen.</div><div><br></div><div>Alles Gute</div><div>Jan</div><div><br></div></body></html>