# Bug in netfilter\_conntrack stört Tunneldigger-Betrieb (Kernel 5.0.20+ und 5.1.6+)

**URL:** <https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711>\
**Category:** Technik\
**Created:** [21. Juni 2019 um 03:33 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711 "2019-06-21T03:33:01Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**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:** [21. Juni 2019 um 03:33 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/1 "2019-06-21T03:33:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MisterCrumble](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/m/f1d935/32.png) [@MisterCrumble](https://forum.freifunk.net/u/MisterCrumble)\
**Post date:** [21. Juni 2019 um 09:40 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/2 "2019-06-21T09:40:07Z")

</div>

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)

---

<div class="post-metadata">

**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:** [21. Juni 2019 um 11:33 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/3 "2019-06-21T11:33:12Z")

</div>

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.

---

<div class="post-metadata">

**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:** [21. Juni 2019 um 12:33 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/4 "2019-06-21T12:33:19Z")

</div>

> [@MisterCrumble](#):
>
> bei uns ging der Tunneldigger ab Kernel 4.13 nicht mehr.

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 - #32 von adorfer](https://forum.freifunk.net/t/l2tp-tunneldigger-serverdoku-thread/11621/32)

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

> [@Felix](#):
>
> daher hoffe ich vielleicht auf ein paar Arch User.

Die Arch-User hier nutzen fastd, Nixos ebenfalls.

---

<div class="post-metadata">

**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:** [21. Juni 2019 um 19:20 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/5 "2019-06-21T19:20:09Z")

</div>

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

```auto
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 😉

---

<div class="post-metadata">

**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:** [22. Juni 2019 um 00:25 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/6 "2019-06-22T00:25:32Z")

</div>

> [@Felix](#):
>
> Spätestens wenn die anderen Communities ihre Gateways auf Kernel neuer als 5.0.19 upgraden hab ich ein paar mehr Mitstreiter,

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

---

<div class="post-metadata">

**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:** [24. Juni 2019 um 02:03 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/7 "2019-06-24T02:03:02Z")

</div>

Ich sollte häufiger Lotto spielen.

```auto
[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

```

---

<div class="post-metadata">

**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:** [24. Juni 2019 um 08:04 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/8 "2019-06-24T08:04:30Z")

</div>

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.

---

<div class="post-metadata">

**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:** [24. Juni 2019 um 10:58 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/9 "2019-06-24T10:58:27Z")

</div>

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.

---

<div class="post-metadata">

**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:** [25. Juni 2019 um 16:21 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/10 "2019-06-25T16:21:12Z")

</div>

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

Ganzer Thread: [https://marc.info/?t=156135371500007&r=1&w=4](https://marc.info/?t=156135371500007&r=1&w=4)

---

<div class="post-metadata">

**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. Juli 2019 um 15:17 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/12 "2019-07-03T15:17:22Z")

</div>

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: [https://bugzilla.redhat.com/show\_bug.cgi?id=1724357](https://bugzilla.redhat.com/show_bug.cgi?id=1724357)

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](https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=e7600865db32b69deb0109b8254244dca592adcf)

---

<div class="post-metadata">

**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. August 2019 um 20:45 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/13 "2019-08-03T20:45:45Z")

</div>

Fixed in 5.1.20 und 5.2.3.

---

<div class="post-metadata">

**Author:** ![wlankabel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wlankabel/32/20322_2.png) [@wlankabel](https://forum.freifunk.net/u/wlankabel)\
**Post date:** [4. September 2019 um 11:18 UTC](https://forum.freifunk.net/t/bug-in-netfilter-conntrack-stoert-tunneldigger-betrieb-kernel-5-0-20-und-5-1-6/20711/14 "2019-09-04T11:18:24Z")

</div>

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