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