Tunneldigger updates - Ihr Handeln ist erforderlich!

Technik
1

Hallo zusammen,

im Zuge der Umbauten und Modernisierungen am Tunneldigger für den IPv6 Support (Kenner lesen Tunneldigger IPv6 support) 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.
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. 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. Hier ist der Status noch unverändert, dass wir noch Hilfe beim Testing brauchen.

12 „Gefällt mir“
2

Mega cool :grinning:. Danke für die Arbeit!

3

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.

4

Das hatten wir auch mal gemerkt. Bei uns reichte es glaube ich einen recht aktuellen Kernel einzuspielen.

5

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…

6

Dann stelle ich die Sinnfrage. Solange es mit Standarddistributionskerneln nicht tut, ist der Umbau verfrüht.

7

Ich würde da zustimmen, zumal ja Debian/Ubuntu LTS mit seinen LTS Kerneln sehr verbreitet im Freifunk Umfeld ist.

8

Daher ja meine Frage vorhin!
Ubuntu18.04 ist mit dem HWE-Stack inzwischen bei 5.3 angekommen. Reicht das oder eben nicht?

9

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.

2 „Gefällt mir“
10 
commit 82369aa61ec7f3a006f8e687dd0b80c5782f8a83
Author: Willem de Bruijn <willemb@google.com>
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 <willemb@google.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Acked-by: Craig Gallek <kraig@google.com>
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Dieser Fix ist in 5.2.17 und 4.19.75. Sollte also auch irgendwann in Debian und Ubuntu LTS landen.

8 „Gefällt mir“
11

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

12

Das ist alles schon längst geschehen.

13

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.

5 „Gefällt mir“
14

Es gibt leider weitere Probleme mit dem Entfernen des NAT-hacks. :frowning:
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 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.

15

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.

16

SO_REUSEPORT wurde 2013 hinzugefügt. „Recht neu“ würde ich das nicht nennen. :wink: