Tunneldigger IPv6 support

MPW · 26. Oktober 2019 um 11:26

@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.

Felix · 26. Oktober 2019 um 12:05

Hast du verwendete Distribution, Kernelversion und Pythonversion für mich?
Wird das Ganze in einem virtualenv ausgeführt?
Dann versuche ich das mal lokal zu reproduzieren.

MPW · 26. Oktober 2019 um 12:14

Siehe Telegramm. Aber hier auch die Details:

root@corny ~ # cat /etc/*release*
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@corny ~ # uname -a
Linux corny 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux
root@corny ~ # python3 --version
Python 3.7.3

Ja, wird im virtualenv ausgeführt. In dem virtualenv was per apt von Debian 10 kommt.

root@corny ~ # virtualenv --version
15.1.0

MPW · 26. Oktober 2019 um 12:40

@Felix, wir stellen uns gerade die Frage, ob wir vllt. etwas falsch gemacht haben: Läuft der neue Broker von dir mit dem alten Client auf den Knoten?

Soweit ich dich verstanden habe, müsste das erstmal gehen. Nur um Missverständnisse auszuschließen.

PS: Ich habe gerade mal ein bisschen Statistiken angeschaut.

Ich habe hier 120 verbundene Knoten mit altem Client und neuem Broker. Das scheint also erstmal zu laufen. Da gehen auch gut 100 Mbit/s durch.

Allerdings habe ich über 375 verschiedene Mac-Adressen die obigen Fehler verursachen.

Felix · 26. Oktober 2019 um 12:55

Ja, so betreibe ich es in Leverkusen. Ich hab nur 3 Knoten auf dem neuen Client.

Danke für’s Testen, den Fehler hab ich bei uns noch nicht gesehen. Vielleicht liegt es an unterschiedlichen Kernelversionen (wir verwenden 5.3). Ich gehe da mal investigativ vor.

MPW · 26. Oktober 2019 um 14:52

Gerade mal mit dem Kernel 5.2 aus den Debian-Backports getestet. Da scheint das Problem nicht aufzutreten.

Wir haben jetzt nur noch alte Gluons ohne gepatchten Tunneldigger, die das Session-ID-Problem haben. Aber das soll mir egal sein, wenn die Leute ihre Knoten nicht aktualisieren.

MPW · 26. Oktober 2019 um 16:46

PS: Für mich brauchst du da keine Zeit reinstecken. Wie nehmen einfach den aktuellen Kernel und jut is.

MPW · 26. Oktober 2019 um 20:37

@Felix, nachdem ich erst vergessen hatte V6 auf den Knoten zu schalten, geht es jetzt leider trotzdem nicht:

root@ffmsd04-tdv6:/# /etc/init.d/tunneldigger start
Not starting tunneldigger - missing uuid
Starting tunneldigger on mesh-vpn
root@ffmsd04-tdv6:/# logread -f
Sat Oct 26 22:34:00 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:34:05 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:34:06 2019 daemon.info td-client: Trying broker [2a01:4f8:191:8224::56] on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:34:16 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:34:21 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:34:22 2019 daemon.info td-client: Trying broker [2a01:4f8:191:8224::56] on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:34:32 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:34:37 2019 daemon.info td-client: Performing broker selection...
^Croot@ffmsd04-tdv6:/# ping6 2a01:4f8:191:8224::56
PING 2a01:4f8:191:8224::56 (2a01:4f8:191:8224::56): 56 data bytes
64 bytes from 2a01:4f8:191:8224::56: seq=0 ttl=59 time=0.619 ms
64 bytes from 2a01:4f8:191:8224::56: seq=1 ttl=59 time=0.390 ms
^C
--- 2a01:4f8:191:8224::56 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.390/0.504/0.619 ms
root@ffmsd04-tdv6:/# uci show|grep address
tunneldigger.mesh_vpn.address='[2a01:4f8:191:8224::56]:20004'

Ping zum Gateway geht. Aber der baut den Tunnel nicht auf.

Hat vllt. der Patch nicht geklappt? Kann ich irgendwie abfragen, ob ich wirklich die gepatchte Version eingebaut habe?

Ist ein x86-Gluon.

PS: Auch mit DNS geht es nicht.

Sat Oct 26 22:39:03 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:39:03 2019 daemon.info td-client: Trying broker ipv6-td.servers.ffmsl.de on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:39:14 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:39:19 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:39:20 2019 daemon.info td-client: Trying broker ipv6-td.servers.ffmsl.de on IP 2a01:4f8:191:8224::56
Sat Oct 26 22:39:30 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sat Oct 26 22:39:35 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:39:36 2019 daemon.info td-client: Trying broker ipv6-td.servers.ffmsl.de on IP 2a01:4f8:191:8224::56

PPS: Da sich ein definitiv ungepatchtes, altes Gluon wie folgt verhält, denke ich schon, dass ich den Patch korrekt angewendet habe.

Fri Oct 25 16:28:19 2019 daemon.info td-client: Tunnel successfully established.
Sat Oct 26 22:46:10 2019 daemon.warn td-client: Got termination signal, shutting down tunnel...
Sat Oct 26 22:46:11 2019 daemon.info td-client: Performing broker selection...
Sat Oct 26 22:46:11 2019 daemon.err td-client: Failed to resolve hostname '[2a01'.
Sat Oct 26 22:46:27 2019 daemon.info td-client: Reinitializing tunnel context.
Sat Oct 26 22:46:27 2019 daemon.err td-client: Failed to resolve hostname '[2a01'.
Sat Oct 26 22:46:32 2019 daemon.info td-client: Selected [2a01:4f8:191:8224::56]:20004 as the best broker.
Sat Oct 26 22:46:33 2019 daemon.warn td-client: Failed to send() control packet (errno=89, type=1)!

Felix · 26. Oktober 2019 um 22:06

Am Tunneldigger Broker entsprechend auch die Konfiguration angepasst damit der auch auf der IPv6 lauscht?

MPW · 26. Oktober 2019 um 22:19

Ähm ja, da sagst du was. Ich hatte das in der Beispielkonfig gesehen aber verpeilt, dass wir natürlich unsere eigene Konfig per Ansible auf die Gateways schieben.

Sun Oct 27 00:16:14 2019 daemon.info td-client: Selected ipv6-td.servers.ffmsl.de:20004 (IPv6) as the best broker.
Sun Oct 27 00:16:14 2019 daemon.info td-client: Tunnel successfully established.

Felix · 26. Oktober 2019 um 22:22

Interessant. Dann müsste man mal triangulieren bei welcher Kernelversion man Einsteigen kann ins IPv6-Vergnügen.

Vielen Dank für’s Testen!

MPW · 26. Oktober 2019 um 22:23

Vielen Dank dir für’s Bauen. Denke das wird recht schnell produktiv gehen hier bei uns.

Wir sollten uns noch die letzten zwei Bugs angucken und dann ab ins Gluon damit…

Felix · 27. Oktober 2019 um 04:28

So. Das hab ich jetzt mal gemacht.
Bug #1 ist damit definitiv Geschichte.
Bug #2 muss ich noch schauen.

Hier ist der neue Code: client: Implement IPv6 · kaechele/tunneldigger@b20ba68 · GitHub
Im patch für Gluon also einfach den commit mit diesem ersetzen: b20ba68c263345a82de1c910956df524bee78a59

Was mir noch aufgefallen ist: Tunneldigger verbindet sich per IPv4, wenn die IPv6 Adressierung (SLAAC/DHCPv6) etwas länger dauert als IPv4 DHCP. Wenn noch keine v6 Adresse anliegt, dann geht die Verbindung natürlich per v4 raus. Das wäre dann eine Race condition, die sich nur über warten lösen ließe. Sie tritt bei mir auf dem Knoten direkt nach dem Reboot auf.

adorfer · 27. Oktober 2019 um 05:34

Impact könnte man dadurch reduzieren, dass man 4 Stück AAAA-only einträgt (die alle auf den gleichen zeigen) und nur nur einen Dual (A/AAAA)-DNS-Record.

wusel · 27. Oktober 2019 um 08:57

Ich bin generell gegen solche Würgarounds, welches reale Problem soll damit umgangen werden?

Felix · 4. November 2019 um 03:31

So. Die Tests bei uns in Leverkusen sind zufriedenstellend verlaufen. Ich rolle gerade Firmware Version 7.0.0 (Gluon 2019.1) mit dem IPv6 Tunneldigger-Client bei uns aus (siehe Map). Soweit keine nennenswerten Verluste.
Die Anzahl der IPv6 Tunnel auf unseren Gateways steigt fast mit jedem Knoten der updatet

Die Zeit bis das Feature upstream im Tunneldigger landet ist unbestimmt, denn die Testumgebung ist leider Defekt. Somit kann das Zusammenspiel mit älteren Broker Versionen nicht getestet werden. Und bevor das nicht passiert landet der Code nicht im offiziellen Repository.
Für FF Leverkusen ist das irrelevant, da ich sowohl broker- als auch clientseitig stets aktuellen Code betreibe. Rein vom Code her sollte es da auch keine Inkompatibilitäten geben, aber es ist eben ungetestet.
Insofern habe ich da ehrlich gesagt auch keine Motivation das Test-Setup zu fixen, zumal ich aktuell wieder eher weniger Zeit übrig hab. Ich bin froh, dass ich wenigstens das IPv6 geraffel in einen working state bekommen habe.

Felix · 4. November 2019 um 17:04

Hier mal ein paar Stats bzgl. IPv4 vs. IPv6:

[felix@gw1 ~]$ sudo ip l2tp show tunnel | grep 89.163.129.84 | wc -l
26
[felix@gw1 ~]$ sudo ip l2tp show tunnel | grep :: | wc -l
43
[felix@gw3 ~]$ sudo ip l2tp show tunnel | grep 89.163.241.62 | wc -l
29
[felix@gw3 ~]$ sudo ip l2tp show tunnel | grep :: | wc -l
39

137 Tunnel, davon 82 IPv6 (knapp 60%). Nicht schlecht

MPW · 4. November 2019 um 20:44

Klingt mega gut.

Hast du vor den Client-Code als Patch im Gluon einzureichen? Der TD ist ja dort offiziell drin inzwischen.

Wir sind noch nicht weitergekommen, aber nur aus Zeitmangel. Meine Testumgebung (ein Haufen x86-libvirt Gluons) mag nicht mit IPV6 auf WAN. Ich habe mir irgendwie immer die Defaultroute weggeschossen, als sich der Knoten mit dem Freifunk-Netz verbunden hat und von dort eine bekam. Das hatte aber nichts mit dem TD zu tun, denke ich.

Felix · 5. November 2019 um 13:03

Es tauchen allerdings die ersten Meldungen auf, dass es nicht ganz rund läuft. IPv6 ist halt nochmal was anderes. Andere Headergrößen, andere MTUs.

Zudem haben wir auf manchen Mesh-only Knoten seit dem Update hohe Auslastungen. Der Tunneldigger rotiert dort zeitweise bei 100% CPU.
Ich bleibe also dran

adorfer · 5. November 2019 um 16:14

Ein Tunneldigger-thread oder ganz, ganz viele?