# Tunneldigger updates - Ihr Handeln ist erforderlich! **URL:** \ **Category:** Technik\ **Created:** [15. Januar 2020 um 16:17 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690 "2020-01-15T16:17:55Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [15. Januar 2020 um 16:17 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/1 "2020-01-15T16:17:55Z")
Hallo zusammen, im Zuge der Umbauten und Modernisierungen am Tunneldigger für den IPv6 Support (Kenner lesen [Tunneldigger IPv6 support](https://forum.freifunk.net/t/tunneldigger-ipv6-support/11964)) machen wir gute Fortschritte. Für die, die die neue Version bereits nutzen wollen folgende Hinweise: [Python 3 Support ist kürzlich in den master Branch gemerged worden](https://github.com/wlanslovenija/tunneldigger/pull/110). Bitte lest euch hierzu die Release Notes (in HISTORY.rst) bzw. die aktualisierte Doku durch. Ggf. ist bei eurem serverseitigen Setup ein manuelles upgrade erforderlich. [Das Entfernen des NAT geraffels ist fertig](https://github.com/wlanslovenija/tunneldigger/pull/115). Ich würde mich aber über ein paar mehr Tester freuen. In Leverkusen tut das auf 3 Gateways völlig ohne Probleme. [IPv6 Support kommt dann am Schluss](https://github.com/wlanslovenija/tunneldigger/pull/116). Hier ist der Status noch unverändert, dass wir noch Hilfe beim Testing brauchen. ---
**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\ **Post date:** [15. Januar 2020 um 20:57 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/2 "2020-01-15T20:57:08Z")
Mega cool 😀. Danke für die Arbeit! ---
**Author:** ![ralfj](https://forum.freifunk.net/user_avatar/forum.freifunk.net/ralfj/32/7943_2.png) [@ralfj](https://forum.freifunk.net/u/ralfj)\ **Post date:** [1. Februar 2020 um 12:48 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/3 "2020-02-01T12:48:28Z")
Stellt sich raus dass das mit dem NAT-freien Tunneldigger auf älteren Kerneln (inkl. Debian stable) nicht richtig klappt, und es ist auch nicht ganz klar (zumindest mir) warum es auf neueren funktioniert… siehe [diesen Thread](https://github.com/wlanslovenija/tunneldigger/pull/115#issuecomment-580810619). ---
**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\ **Post date:** [1. Februar 2020 um 18:10 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/4 "2020-02-01T18:10:47Z")
Das hatten wir auch mal gemerkt. Bei uns reichte es glaube ich einen recht aktuellen Kernel einzuspielen. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [2. Februar 2020 um 19:21 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/5 "2020-02-02T19:21:14Z")
Die Grenze liegt also irgendwo zwischen Kernel 4.19 und 5.4… Da wäre es echt spannend, was es mit Kernel 5.0/5.3 tut… ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [3. Februar 2020 um 01:48 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/6 "2020-02-03T01:48:54Z")
> [@MPW](#): > > Bei uns reichte es glaube ich einen recht aktuellen Kernel einzuspielen. Dann stelle ich die Sinnfrage. Solange es mit Standarddistributionskerneln nicht tut, ist der Umbau verfrüht. ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [3. Februar 2020 um 02:25 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/7 "2020-02-03T02:25:34Z")
> [@wusel](#): > > Dann stelle ich die Sinnfrage. Solange es mit Standarddistributionskerneln nicht tut, ist der Umbau verfrüht. Ich würde da zustimmen, zumal ja Debian/Ubuntu LTS mit seinen LTS Kerneln sehr verbreitet im Freifunk Umfeld ist. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [3. Februar 2020 um 03:28 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/8 "2020-02-03T03:28:47Z")
Daher ja meine Frage vorhin! Ubuntu18.04 ist mit dem HWE-Stack inzwischen bei 5.3 angekommen. Reicht das oder eben nicht? ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [3. Februar 2020 um 03:30 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/9 "2020-02-03T03:30:44Z")
Während ich hier schreibe bin ich am bisecten. Bald wissen wir genau welcher commit und damit welche Kernelversion erforderlich ist. Aktuell bin ich bei: 5.2.9 geht nicht, 5.2.21 geht. Nächster Test: 5.2.15 Edit: Der erste Kernel, der nicht broken ist, ist 5.2.17. ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [3. Februar 2020 um 03:56 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/10 "2020-02-03T03:56:21Z")
``` commit 82369aa61ec7f3a006f8e687dd0b80c5782f8a83 Author: Willem de Bruijn Date: Thu Sep 12 21:16:39 2019 -0400 udp: correct reuseport selection with connected sockets [Upstream commit acdcecc61285faed359f1a3568c32089cc3a8329] UDP reuseport groups can hold a mix unconnected and connected sockets. Ensure that connections only receive all traffic to their 4-tuple. Fast reuseport returns on the first reuseport match on the assumption that all matches are equal. Only if connections are present, return to the previous behavior of scoring all sockets. Record if connections are present and if so (1) treat such connected sockets as an independent match from the group, (2) only return 2-tuple matches from reuseport and (3) do not return on the first 2-tuple reuseport match to allow for a higher scoring match later. New field has_conns is set without locks. No other fields in the bitmap are modified at runtime and the field is only ever set unconditionally, so an RMW cannot miss a change. Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection") Link: http://lkml.kernel.org/r/CA+FuTSfRP09aJNYRt04SS6qj22ViiOEWaWmLAwX0psk8-PGNxw@mail.gmail.com Signed-off-by: Willem de Bruijn Acked-by: Paolo Abeni Acked-by: Craig Gallek Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman ``` Dieser Fix ist in 5.2.17 und 4.19.75. Sollte also auch irgendwann in Debian und Ubuntu LTS landen. ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [3. Februar 2020 um 08:48 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/11 "2020-02-03T08:48:14Z")
> [@Felix](#): > > Dieser Fix ist in 5.2.17 und 4.19.75. Sollte also auch irgendwann in Debian und Ubuntu LTS landen. Hmm. `Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-173-generic x86_64)` — denke mal nicht, daß das bis 4.4 rückportiert wird/werden kann. Insofern wäre es wünschenswert, die Python2/Python3-Änderungen unabhängig von den reuseport-Änderungen bereitzustellen. (Ja, ich weiß, daß das doof ist und 16.04 eher kurz vorm Ende des Lebenszyklus’ steht. Aber es ist eben auch noch relativ lange eben nicht EOL.) ---
**Author:** ![ralfj](https://forum.freifunk.net/user_avatar/forum.freifunk.net/ralfj/32/7943_2.png) [@ralfj](https://forum.freifunk.net/u/ralfj)\ **Post date:** [3. Februar 2020 um 11:32 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/12 "2020-02-03T11:32:24Z")
> [@wusel](#): > > Insofern wäre es wünschenswert, die Python2/Python3-Änderungen unabhängig von den reuseport-Änderungen bereitzustellen Das ist alles schon [längst geschehen](https://github.com/wlanslovenija/tunneldigger/commit/a461a11495579d3f95c485a295285564c20d6bb4). ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [3. Februar 2020 um 12:20 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/13 "2020-02-03T12:20:26Z")
> [@wusel](#): > > denke mal nicht, daß das bis 4.4 rückportiert wird/werden kann Wenn ich mir den bug report dazu anschaue scheint es bei 4.4 noch keine Probleme gegeben zu haben. EDIT: Hab gerade mal Ubuntu 16.04 getestet. Läuft out of the box. 18.04 nur wenn man den 5.3er Kernel aus den Repos installiert. #FürSieGetestet EDIT2: Debian 10 stable mit aktuellen Updates läuft jetzt auch. ---
**Author:** ![ralfj](https://forum.freifunk.net/user_avatar/forum.freifunk.net/ralfj/32/7943_2.png) [@ralfj](https://forum.freifunk.net/u/ralfj)\ **Post date:** [7. März 2020 um 19:35 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/14 "2020-03-07T19:35:00Z")
Es gibt leider weitere Probleme mit dem Entfernen des NAT-hacks. ☹ Ich habe unsere Server inzwischen auf Debian stable (buster) gehoben, der oben erwähnte Fix ist also drin. Und trotzdem spinnt der tunneldigger ohne NAT: wenn mehr als nur 1 oder 2 Nutzer verbunden sind, brechen die Verbindungen zusammen (also es kommen keine Daten mehr durch, zumindest in der Client → Server Richtung) und der Server behauptet irgendwann es gäbe einen Timeout. Wenn ich jedoch den Backports-Kernel verwende (v5.4.13), klappt es. Ich habe [diesen Kernel-Commit](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4cdeeee9252af1ba50482f91d615f326365306bd) als Fix in Verdacht. Wenn das stimmt, hieße das, man bräuchte mindestens Kernel 5.0 für diesen Fix… und weil man auch den anderen Fix braucht ist es mindestens 5.3.1 (und mainline ab 5.4). Mit älteren Kerneln ist SO\_REUSEPORT für UDP einfach zu kaputt, und ohne SO\_REUSEPORT gehts nicht (bzw nur mit NAT). Und man fragt sich auch ob man sich auf ein offenbar so fragiles Kernel-Feature überhaupt verlassen will.^^ Siehe auch [den entsprechenden Tunneldigger-Issue](https://github.com/wlanslovenija/tunneldigger/issues/129). ---
**Author:** ![Felix](https://forum.freifunk.net/user_avatar/forum.freifunk.net/felix/32/24989_2.png) [@Felix](https://forum.freifunk.net/u/Felix)\ **Post date:** [7. März 2020 um 20:35 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/15 "2020-03-07T20:35:42Z")
Och nö. Ich denke du hast mit dem genannten commit schon ins Schwarze getroffen. Ich denke nicht, dass das Feature fragil ist, es ist halt nur recht neu. ---
**Author:** ![ralfj](https://forum.freifunk.net/user_avatar/forum.freifunk.net/ralfj/32/7943_2.png) [@ralfj](https://forum.freifunk.net/u/ralfj)\ **Post date:** [7. März 2020 um 21:49 UTC](https://forum.freifunk.net/t/tunneldigger-updates-ihr-handeln-ist-erforderlich/21690/16 "2020-03-07T21:49:55Z")
SO\_REUSEPORT wurde 2013 hinzugefügt. „Recht neu“ würde ich das nicht nennen. 😉