Wir debuggen das gerade, Fehler ist gefunden, ist die Frage, wie man es sauber umprogrammiert.
Das wird aufwändiger. Der Tunneldigger parst Rohpakete indem er Bytes von der Anzahl der Headergröße wegwirft. Das muss an vielen Stellen geändert werden. Es gibt dazu ein Issue bei den Sloweniern.
Ja das Problem ist, das die Slowenen auch jemanden suchen der sich des Themas annimmt.
Leider kann ich hier nicht so gut Supporten sonst hätte ich das Thema schon mal angegangen.
Wäre aber schön, wenn sich jemand fähiges dem Thema annimmt. Es wäre auch für die DSLite Kunden von vorteil 
Bei uns funktioniert das auch an Unitymediaanschlüssen, die nur eine genattete IPv4 haben. Bei euch nicht?
Wir werden uns am Mittwoch erstaml die Logik vom l2tp_client.c anschauen. Das Ding ist einfach völliges Chaos und es gibt jede Menge Funktionen, die komische Seiteneffekte haben(z. B. setzt die Funktion is_timeout den Timeout zurück). Deswegen kann man an der Struktur nur schwer was ändern, ohne was kaputt zu machen.
Wir haben jetzt ein notdürftigen Patch, der usage für deutlich mehr Broker ermöglicht, aber zu viele Pakete rumschickt. Sauber ist was anderes.
Für IPV6 müsste man sich mal überlegen, ob man nicht eine kleine Bibliothek nimmt, oder ob man das wirklich alles hart kodiert lassen will.
„Funktionieren“ vs. „mehr als nur 1364er MTU fahren können“, dann geht nämlich auch 1406, wenn man keine Rücksicht auf DSLite nehmen muss. Ja, auch bei L2TP bringt das nochmal ordentlich was.
Wobei natürlich das Szenario „Routerkaskade an DSLite mit TC7200 ohne Prefix-Delegation“ dann hinten herunterfallen würde.
Batman kann doch nicht verschiedene MTU-Größen. Der Tunneldigger kann die sogar automatisch aushandeln, das Problem dürfte unser liebes Batman sein.
Klar geht das aber schön und schnell ist anders. Zumal es aktuell an reinen v6 Anschlüssen nicht geht.
Getreu dem Motto „schön ist anders“
Schön stimme ich dir zu, aber 60 Mbit/s über Unitymedia sind kein Problem eigentlich. Das reicht doch an Durchsatz.
Moin,
du hast aber schon. Verstanden, das der Durchsatz nichts mit dem tunneldigger zu tun hat?
Das ist ja nur ein helperscript was dafuer sorgt, das eine l2tp Verbindung aufgebaut werden kann die normalerweise zwischen statischen ips mit einer fixen Konfiguration aufgebaut wird.
Es ging mit eher darum das man doch sinnigerweise direkt ipv6 sprechen kann als erst noch durch ein völlig überfrachtet Nat zu gehen. Das geht auf die Latenz und damit letzten Endes auch auf die Bandbreite aber, wer will schon Saugen über Freifunk. Ich fuer meinen Teil würde lmir ieber ein hoch optimiertes Netz wünschen, da wir immer noch von der Latenz der Provider abhängig sind.
Alles volle Zustimmung, bei uns war es bisher einfach nie langsam, daher wunderte ich mich.
Grüße
Matthias
Dann würde natives IPv6 (statt DSlite-CGN) dem L2TP also wirklich etwas bringen, weil der V4-in-V6-Overhead eingespart würde.
Bei den Knoten mit 400MHz-CPU scheint das Limit für L2TP deutlich unterhalb dessen zu liegen, was man eigentlich an einem VDSL50 erwarten könnte.
Ja, im Vergleich zu Fastd ist das alles „Jammern auf hohem Niveau“. Aber wir sind ja auch für die Forschung hier… Ein Hoch auf die Wissenschaft!</pete>
Ich habe eine Version von l2tp_client auf mein Rechner kompiliert und die Verbindung zur Test GW ist spitze, ich kann fast die gesammte Bandbreute meinen Anschuss 50.000 nutzen.
Was mir stört ist dass IPv6 nicht unterstützt wird. Ist mittlerweile eine nicht gluon Version mir IPv6 Unterstützung vorhanden ?
Afaik nicht.
Zumindest sehe ich hier seit 3 Jahren keine Bewegung.
Und am Gluon-Ticket hat sich auch nichts sichtbares getan. Vielleicht hat @MPW ja dazu was bei der „Planung“ herausgekommen ist.
Ich vermute schlicht, dass wir eher Wireguard haben werden, aber hier offtopic.
Mir ist keine neue Entwicklung bekannt. Die Wlan-Slowenija-Mailingliste ist relativ tot.
Grüße
Matthias
Vielleicht noch ergänzend: So viel Arbeit schien das nicht zu sein. Man muss halt das Parsing der Pakete neu implementieren, das ist derzeit fest auf IPV4, z. B. ist die Paketkopfgröße fest eincodiert im Quellcode. Und man muss sich noch überlegen, wie man das mit der Port-Translation abbildet. Ich meine, da war noch unklar, ob das mit V6 und dem Linuxkernel geht.
Also per Python und C kann und Bock drauf hat, nur zu :).
Das Problem ist eher, dass die Upstreamversion derzeit nicht richtig läuft. Daher nutzen glaube ich alle Communities die ältere vom FFRL geforkte.
IPv6 support for Tunneldigger has been selected as Google Summer of Code project this year. So work on https://dev.wlan-si.net/ticket/1187 will start soon.
This is because we use chat for mostly everything: https://chat.wlan-si.net/ Feel free to join it.
Especially if you would like to help with testing the new IPv6 changes. This would be a good time to participate and contribute.
Gab es hier zwischenzeitlich eine Weiterentwicklung?
3 Beiträge wurden in ein neues Thema verschoben: WireGuard als zukünftige VPN-Lösung?
Takt und ich hatten das mit gbAcs Hilfe bei der OKFN als OPF-Projekt eingereicht, wurden aber nicht angenommen.
Wir hatten uns grob für den Juli vorgenommen, mal trotzdem privat ein paar erste Tests zu machen.
Jugend forscht: Get it working with IPv6 · Issue #75 · wlanslovenija/tunneldigger · GitHub
@MPW Wenn ihr noch plant da irgendwas implementieren zu wollen sprecht mich gerne an. Ich kenn den Tunneldigger sowie den Linux L2TP Treiber jetzt in und auswendig 
Ich sag aber mal so: Das geringste Problem ist das Umschreiben der geparsten und generierten Header 
Wir sind leider noch zu nichts gekommen. Gerade so viel um die Ohren.
Das ist ja mega, dass du schon funktionierenden Code hast. Ich kann dich nur ermutigen, den zu teilen. Und vllt. kann man den noch etwas refraktoren.
Evtl. können wir dazu mal ein Mumble-Treffen machen und ein paar Sachen durchsprechen?