Bug in netfilter_conntrack stört Tunneldigger-Betrieb (Kernel 5.0.20+ und 5.1.6+)

Betreibt hier jemand Tunneldigger bereits auf einem Kernel 5.1.x oder neuer?

Ich habe vorhin unsere Gateways auf 5.1.11 geupgraded (von 5.0.9). Seitdem funktioniert Tunneldigger auf allen Gateways nicht mehr. Downgrade auf 5.1.8 brachte auch nichts. Erst das Downgrade zurück auf 5.0.9 brachte Linderung. 5.0.17 tut auch.
Hat jemand ähnliche Erfahrungen? Ich debugge das morgen mal.

Aktueller Stand:
Client:
td-client: Connection with broker not established after 15 seconds, restarting broker selection...
Broker erstellt laufend neue Tunnel für den Client, anscheinend ohne dem Client die korrekten Keepalive Pakete zu senden. Die alten, toten Tunnel werden vom Tunneldigger nicht abgeräumt.

Hallo,

bei uns ging der Tunneldigger ab Kernel 4.13 nicht mehr.

Bitte schreibe doch mal was für ein System du genau nutzt damit wir nicht spekulieren müssen

(Beitrag wurde vom Nutzer nachträglich editiert)

Fedora 30 mit aktuellsten Paketen.

Es scheint allerdings am Kernel zu liegen. Daher wäre ich zunächst daran interessiert ob Nutzer anderer Distributionen ähnliche Probleme haben.
Debian Nutzer werde ich wohl erstmal keine finden die derart aktuelle Kernel betreiben, daher hoffe ich vielleicht auf ein paar Arch User.

Es ist nicht das Unique ID Problem, das in der 4er Kernel Serie zugeschlagen hat. Meinen ersten Recherchen nach scheint es entweder mit dem L2TP Treiber zusammenzuhängen oder mit der Art wie UDP Pakete verarbeitet werden.
Ich schaue mal ob ich heute einen git bisect an den Start bekomme, wenn es zeitlich passt.
Ich habe alles was ich brauche um das Problem zu debuggen. Dieser Post soll mir nur helfen in die richtige Richtung zu gehen.

1 Like

Was Du jetzt meinst ist das Problem mit Kernel neuer „4.10.0-26“ mit den Tunnelnummern/IDs im „gluon2016/ffrl“-Paket, siehe L2TP/Tunneldigger Serverdoku-Thread

Hier geht’s dem Felix aber um ein Issue, das anders gelagert ist.

Die Arch-User hier nutzen fastd, Nixos ebenfalls.

Kurzes Statusupdate: Der Fehler tritt beim Wechsel von 5.0.19 auf 5.0.20 auf.
Ich hatte jetzt noch nicht genügend Zeit und Gelegenheit einen tatsächlichen Git Bisect vorzunehmen, aber im ChangeLog konnte ich jetzt auch nicht wirklich einen commit ausmachen, der hier ursächlich sein könnte.
Ein Kandidat wäre

79bade500ab07e69f20d853535b8e47c5878bf4d netfilter: ctnetlink: Resolve conntrack L3-protocol flush regression

Ist aber auch eher unwahrscheinlich.

Bei Gelegenheit gehe ich dem mal weiter nach. Spätestens wenn die anderen Communities ihre Gateways auf Kernel neuer als 5.0.19 upgraden hab ich ein paar mehr Mitstreiter, die mir beim Suchen helfen :wink:

2 Likes
root@l2tp-ber01 ~ # uname -a
Linux l2tp-ber01 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Viel aktueller wird’s die nächsten Jahre nicht (18.04 LTS => Ruhe bis mindestens 2020).

1 Like

Ich sollte häufiger Lotto spielen.

[felix@x1 linux]$ git bisect good
79bade500ab07e69f20d853535b8e47c5878bf4d is the first bad commit
commit 79bade500ab07e69f20d853535b8e47c5878bf4d
Author: Kristian Evensen <kristian.evensen@gmail.com>
Date:   Fri May 3 17:40:07 2019 +0200

    netfilter: ctnetlink: Resolve conntrack L3-protocol flush regression
    
    commit f8e608982022fad035160870f5b06086d3cba54d upstream.
    
    Commit 59c08c69c278 ("netfilter: ctnetlink: Support L3 protocol-filter
    on flush") introduced a user-space regression when flushing connection
    track entries. Before this commit, the nfgen_family field was not used
    by the kernel and all entries were removed. Since this commit,
    nfgen_family is used to filter out entries that should not be removed.
    One example a broken tool is conntrack. conntrack always sets
    nfgen_family to AF_INET, so after 59c08c69c278 only IPv4 entries were
    removed with the -F parameter.
    
    Pablo Neira Ayuso suggested using nfgenmsg->version to resolve the
    regression, and this commit implements his suggestion. nfgenmsg->version
    is so far set to zero, so it is well-suited to be used as a flag for
    selecting old or new flush behavior. If version is 0, nfgen_family is
    ignored and all entries are used. If user-space sets the version to one
    (or any other value than 0), then the new behavior is used. As version
    only can have two valid values, I chose not to add a new
    NFNETLINK_VERSION-constant.
    
    Fixes: 59c08c69c278 ("netfilter: ctnetlink: Support L3 protocol-filter on flush")
    Reported-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Suggested-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
    Tested-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 b062d8079168411b165bd10be2ccafac43caa19c c356ed6689f386c135a095120b80815070e2f4c7 M	net
2 Likes

Das klingt für mich so, als würden da auch noch andere Dinge als der Tunneldigger kaputtgehen.
Ich habe jetzt aber auch gerade keine Motivation herauszufinden, warum diese Flush-Methode geändert wurde.

Tun sie auch. Der Bug ist in der Testsuite von libnetfilter_conntrack, welches tunneldigger verwendet, ebenfalls sichtbar. Der entsprechende test zum Löschen eines Eintrags schlägt fehl.

Gefahr erkannt, Gefahr gebannt.
https://marc.info/?l=netfilter-devel&m=156147939530167

Ganzer Thread: '[PATCH 08/13] netfilter: ctnetlink: Resolve conntrack L3-protocol flush regression' thread - MARC

8 Likes

Ich glaube zwar nicht dass außer mir jemand Fedora für Gateways einsetzt, aber ab 5.1.16 ist der Fix bei Fedora drin: 1724357 – nf_conntrack_netlink: deleting conntrack entry fails, patch attached

Upstream schlängelt sich der Patch gerade noch durch die Instanzen:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=e7600865db32b69deb0109b8254244dca592adcf

2 Likes

Fixed in 5.1.20 und 5.2.3.

5 Likes

Debian Sid/Bullseye (buster backports): linux-image-5.2.0-2-amd64 (5.2.9-2)
Dort ist es noch (/wieder) defekt.

1 Like