Tunneldigger IPv6 support

Zu welchen Tageszeiten kannst du denn (bei dir)? Gut funktionieren könnte z. B. bei dir Freitag spät abends und bei uns Samstag Vormittag.

Alternativ mal bei dir vormittags und bei uns abends.

Ich denke bei mir vormittags und bei euch Abends wäre am besten.
Bis auf Donnerstag und Dienstag vor 19 Uhr geht bei mir nächste Woche alles ab 18 Uhr deutscher Zeit.

Ich frage mal den @takt, ob er Lust hat dabei zu sein. Montag geht bei mir nicht, Mittwoch ist schlecht, ginge zur Not. Meine erste Wahl wäre Freitag.

Freitag passt auch bei mir.

Ok, evtl. hat ja der @ralfj auch Lust uns zu unterstützen?

Ich melde mich bei dir, @Felix, wegen eines finalen Termins.

Apropos Zeitverschiebung, ich muss mal schlafen gehen. Gn8.

1 „Gefällt mir“

@Felix, @takt kann nur MIttwoch. Ich würde dann Mittwoch 20:30 Uhr vorschlagen.

mumble.ffrl.de

Bis dann
Matthias

2 „Gefällt mir“

DAS gibt es so meines Wissens nicht.

Ah jup danke. .de ist es.

Sorry, Mittwoch Abend geht bei mir nicht. Aber ich helfe gerne mit Reviews oder so!

@ralfj, wir würden uns Samstag 19 Uhr zusammen den L2TP-Treiber im Linuxkernel anschauen. Wenn du da Zeit hättest, Expertise ist gefragt :slight_smile: .

Dieser Samstag Abend ist schlecht. :confused: Die WEs sind bis Weihnachten quasi alle voll.^^
Vom Linuxkernel habe ich aber sowieso ziemlich wenig Ahnung.

Im Topfschlagen um den IPv6 Support im Tunneldigger konnte ich ein erstes Klirren vernehmen: broker: Allow listening on IPv6 addresses · kaechele/tunneldigger@63182ff · GitHub

Der Durchbruch ist aber eigentlich das hier: broker: Remove NAT logic · kaechele/tunneldigger@9a683d3 · GitHub
Das ist das Kernel-Problem, was eigentlich gar keines ist.

Die o.g. Variante des Tunneldiggers läuft bereits auf einem unserer Gateways ohne Probleme und ohne IPTables NAT regeln, allerdings nur mit IPv4 Clients, da ich die Änderungen am C Client noch nicht fertig umgesetzt habe.
Mit einer ersten Testversion, die nur mit expliziter Angabe des Brokers als IPv6 Adresse funktioniert, kann ich bereits einen IPv6-basierten Tunnel aufbauen und nutzen. Es fehlt das korrekte Dual Stack DNS handling.

Wir sind ganz ganz nah dran.

11 „Gefällt mir“

Wow, das klingt super. :slight_smile:

Aktuell hat tunneldigger, wie du sicher gemerkt hast, ein paar Infrastrukturprobleme – die CI ist kaputt. Das sollten wir IMO lösen bevor wir neue Dinge landen. Ich hoffe ich habe morgen oder an Wochenende mal etwas Zeit dafür. Danach kann ich mir endlich mal deine PRs näher anschauen. :smiley:

2 „Gefällt mir“

Ich stimme dir zu.
Ich habe da schon mal ein bisschen Debugging geleistet: Die pip/OS Version, die in den Testing Containern verwendet wird ist zu alt um erfolgreich die Python Pakete herunterzuladen. Bei PyPI hat sich einiges getan (z.B. HTTPS enforced und mind. TLSv1.2). Möglich, dass das eingesetzte Ubuntu 14.04 es einfach nicht unterstützt.
Upgraded man die Travis Config auf Xenial oder Bionic dann funktioniert der LXC Kram nicht mehr um die einzelnen Broker und Clients gegeneinander zu testen.
Möglicherweise wäre es an der Zeit das Testing auf etwas wie Vagrant umzubauen.

Nachtrag:
Wie es aktuell steht werde ich wohl zunächst kein Happy Eyeballs implementieren. Heißt: Hat der Knoten eine globale IPv6 Adresse, dann geht Tunneldigger davon aus, dass darüber eine Kommunikation stattfinden kann. Ein gleichzeitiges Testen von IPv4 erfolgt nicht, sodass bei Vorhandensein von IPv6 kein Fallback auf IPv4 erfolgt.

Weiterhin sind durch meine PRs auch mehr Testfälle für die Testmatrix dazugekommen. Mindestens sind das:

  • Broker auf Python 2 (wobei ich eigentlich gerne ASAP Python 2 komplett droppen will)
  • Broker auf Python 3
  • Client auf Dual Stack
  • Client auf IPv4-only
  • Client auf IPv6-only

https://github.com/kaechele/tunneldigger/commit/640e2a6849e5be1472d46e184d47a5d5c8664a4b

Damit wäre die Gleichung vollständig.

Ich wäre sehr dankbar wenn sich jemand mit besseren C Skills als den meinen die Sache mal anschaut.
Das ist offen gesagt das komplexeste, was ich bisher in C gemacht habe. Insofern nehme ich gerne Feedback entgegen.

3 „Gefällt mir“

Die o.g. Version funktioniert leider nicht sehr gut in Netzwerken ohne IPv6. Muss ich nochmal ran.

EDIT:
Fixed: client: Implement IPv6 · kaechele/tunneldigger@e0fa525 · GitHub
Jetzt funktioniert alles so, wie ich mir das vorstelle. Nächster Schritt: Gluon Test Build meiner Freifunk Leverkusen Firmware.

Ich finde man sollte in auf dieses IPv6 Tunneldigger ein bischen von diesem Geld drauf werfen,oder zumindest die Zinsen die sich ja ansammeln:

:grinning::+1::+1::+1::+1::+1:

1 „Gefällt mir“

Zinsen hat mir gefallen.

1 „Gefällt mir“

Erfolg!
Auf beiden Endpunkten läuft: client: Implement IPv6 · kaechele/tunneldigger@276772a · GitHub

Knoten: https://map.fflev.de/#!/de/map/a42bb0eeae12

Sat Jul 20 13:15:27 2019 daemon.info td-client: Performing broker selection...
Sat Jul 20 13:15:27 2019 daemon.info td-client: Trying broker gw1.fflev.de on IP 2001:4ba0:fff9:1a7:ff::1
Sat Jul 20 13:15:27 2019 daemon.debug td-client: Broker usage of gw1.fflev.de:10076: 2751
Sat Jul 20 13:15:27 2019 daemon.info td-client: Selected gw1.fflev.de:10076 (IPv6) as the best broker.
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Sat Jul 20 13:15:28 2019 daemon.info td-client: Tunnel successfully established.
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Network device 'mesh-vpn' link is up
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Sat Jul 20 13:15:28 2019 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Sat Jul 20 13:15:29 2019 daemon.notice netifd: Interface 'mesh_vpn' is now up

Server: Freifunk Leverkusen - loading...

Tunnel 160, encap UDP
  From 2001:4ba0:fff9:1a7:ff::1 to 2607:fea8:5df:fe4a:872:bfff:fe67:1ef8
  Peer tunnel 1
  UDP source / dest ports: 10076/37008
  UDP checksum: enabled

Edit:
Zum selber ausprobieren:

  1. Server auf neuen Broker-Code aus dem o.g. Repo updaten
  2. Diesen Patch ins Gluon verzeichnis unter patches/packages/gluon packen.
  3. make update
  4. Gluon neu bauen
  5. ???
  6. Profit!

Edit2:
So. Endlich daheim und direkt mal den Router in Natura getestet. Läuft gut!

Edit3:
Zwei bugs hat der code noch:

  • Wenn ein Broker eingetragen ist, der DNS-seitig NXDOMAIN zurückliefert (also im DNS nicht eingetragen ist) wird in kurzer zeit häufig versucht den Namen erneut aufzulösen, der Client verbindet darauf mit einem IPv4 Broker, egal ob IPv6 auch ginge.
  • Nach einem Abbruch des Tunnels verbindet der Client mit einem IPv4 Broker.
11 „Gefällt mir“

@Felix, ich bin gerade dabei das mal zu testen.

Bei mir laufen im Syslog mehrere 100 solcher Zeilen pro Sekunde auf:

Oct 26 13:23:48 corny systemd-udevd[7741]: Could not generate persistent MAC address for l2tp9218-9218: No such file or directory
Oct 26 13:23:48 corny kernel: [50642.577497] br04: port 3(l2tp9218-9218) entered blocking state
Oct 26 13:23:48 corny kernel: [50642.577498] br04: port 3(l2tp9218-9218) entered disabled state
Oct 26 13:23:48 corny kernel: [50642.577652] device l2tp9218-9218 entered promiscuous mode
Oct 26 13:23:48 corny kernel: [50642.577824] br04: port 3(l2tp9218-9218) entered blocking state
Oct 26 13:23:48 corny kernel: [50642.577825] br04: port 3(l2tp9218-9218) entered forwarding state
Oct 26 13:23:54 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:54 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (f4f26ddcdc5c) while processing prepare request.
Oct 26 13:23:55 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:55 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (10feedc466c6) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (c46e1f978f3a) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (60e3275a0076) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (c46e1fe80eb2) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (50c7bf7b0f70) while processing prepare request.
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.broker] Creating tunnel (18d6c78ff854) with id 9219.
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.tunnel] Set tunnel 9219 MTU to 1364.
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.hooks] Running hook 'session.up' via script '/srv/tunneldigger/broker/scripts/addif_domain04.sh'.
Oct 26 13:23:56 corny systemd-udevd[7821]: Using default interface naming scheme 'v240'.
Oct 26 13:23:56 corny systemd-udevd[7821]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 13:23:56 corny systemd-udevd[7821]: Could not generate persistent MAC address for l2tp9219-9219: No such file or directory
Oct 26 13:23:56 corny python[7644]: [INFO/tunneldigger.broker] Rejecting tunnel (ec086bf7d9a8) due to rate limiting
Oct 26 13:23:56 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (ec086bf7d9a8) while processing prepare request.
Oct 26 13:23:56 corny kernel: [50650.568144] br04: port 4(l2tp9219-9219) entered blocking state
Oct 26 13:23:56 corny kernel: [50650.568146] br04: port 4(l2tp9219-9219) entered disabled state
Oct 26 13:23:56 corny kernel: [50650.568240] device l2tp9219-9219 entered promiscuous mode
Oct 26 13:23:56 corny kernel: [50650.568295] br04: port 4(l2tp9219-9219) entered blocking state
Oct 26 13:23:56 corny kernel: [50650.568296] br04: port 4(l2tp9219-9219) entered forwarding state
Oct 26 13:23:59 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:23:59 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (c4e9845b1086) while processing prepare request.
Oct 26 13:24:00 corny python[7644]: [INFO/tunneldigger.broker] Creating tunnel (647002aabbac) with id 9220.
Oct 26 13:24:00 corny python[7644]: [INFO/tunneldigger.tunnel] Set tunnel 9220 MTU to 1364.
Oct 26 13:24:00 corny python[7644]: [INFO/tunneldigger.hooks] Running hook 'session.up' via script '/srv/tunneldigger/broker/scripts/addif_domain04.sh'.
Oct 26 13:24:00 corny systemd-udevd[7821]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 13:24:00 corny systemd-udevd[7821]: Could not generate persistent MAC address for l2tp9220-9220: No such file or directory
Oct 26 13:24:00 corny kernel: [50653.797136] br04: port 5(l2tp9220-9220) entered blocking state
Oct 26 13:24:00 corny kernel: [50653.797137] br04: port 5(l2tp9220-9220) entered disabled state
Oct 26 13:24:00 corny kernel: [50653.797298] device l2tp9220-9220 entered promiscuous mode
Oct 26 13:24:00 corny kernel: [50653.797412] br04: port 5(l2tp9220-9220) entered blocking state
Oct 26 13:24:00 corny kernel: [50653.797413] br04: port 5(l2tp9220-9220) entered forwarding state
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (8416f9c89d26) while processing prepare request.
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.tunnel] Protocol error: tunnel endpoint has changed.
Oct 26 13:24:01 corny python[7644]: [WARNING/tunneldigger.protocol] Failed to create tunnel (98ded03c24ba) while processing prepare request.

Hast du eine Idee, was da schief läuft?

Ich führe deinen TD-IPV6-Zweig mit Python3 aus.