staging.inyokaproject.org

Hallo zusammen,

am letzten Wochenende habe ich auf meinen Router/Server (Shorewall FW + Synergy + dhcp) ein Upgrade von 18.04 auf 22.04 durchgeführt, seitdem frieren die angeschlossenen Clients alle 9 Minuten für ein paar Sekunden ein.

Beispiel Client 1 (Linux PC (Ubuntu Budbie 20.04)) ein ping jede Sekunde.

Mi 7. Dez 16:31:59 CET 2022
PING ubuntuusers.de (87.79.26.37) 56(84) Bytes Daten.

--- ubuntuusers.de ping-Statistik ---
1 Pakete übertragen, 0 empfangen, 100% Paketverlust, Zeit 0ms

Mi 7. Dez 16:32:00 CET 2022
PING ubuntuusers.de (87.79.26.37) 56(84) Bytes Daten.
64 Bytes von ha.ubuntu-de.org (87.79.26.37): icmp_seq=1 ttl=55 Zeit=11.3 ms

--- ubuntuusers.de ping-Statistik ---
1 Pakete übertragen, 1 empfangen, 0% Paketverlust, Zeit 0ms
rtt min/avg/max/mdev = 11.339/11.339/11.339/0.000 ms
Mi 7. Dez 16:32:01 CET 2022
PING ubuntuusers.de (87.79.26.37) 56(84) Bytes Daten.

--- ubuntuusers.de ping-Statistik ---
1 Pakete übertragen, 0 empfangen, 100% Paketverlust, Zeit 0ms

Mi 7. Dez 16:32:12 CET 2022
PING ubuntuusers.de (87.79.26.37) 56(84) Bytes Daten.
64 Bytes von ha.ubuntu-de.org (87.79.26.37): icmp_seq=1 ttl=55 Zeit=11.5 ms

--- ubuntuusers.de ping-Statistik ---
1 Pakete übertragen, 1 empfangen, 0% Paketverlust, Zeit 0ms
rtt min/avg/max/mdev = 11.457/11.457/11.457/0.000 ms
Mi 7. Dez 16:32:13 CET 2022
PING ubuntuusers.de (87.79.26.37) 56(84) Bytes Daten.
64 Bytes von ha.ubuntu-de.org (87.79.26.37): icmp_seq=1 ttl=55 Zeit=10.8 ms

--- ubuntuusers.de ping-Statistik ---
1 Pakete übertragen, 1 empfangen, 0% Paketverlust, Zeit 0ms
rtt min/avg/max/mdev = 10.786/10.786/10.786/0.000 ms

syslog und network-config im Anhang

Hat jemand eine Idee woran das liegen könnte?

Gruß Waldecker

waldecker schrieb:

..., seitdem frieren die angeschlossenen Clients alle 9 Minuten für ein paar Sekunden ein.

Was genau meinst Du mit "einfrieren"? Können die Clients nicht benutzt werden oder haben diese nur keine Verbindung zum Router?

lubux schrieb:

waldecker schrieb:

..., seitdem frieren die angeschlossenen Clients alle 9 Minuten für ein paar Sekunden ein.

Was genau meinst Du mit "einfrieren"? Können die Clients nicht benutzt werden oder haben diese nur keine Verbindung zum Router?

Da hab ich wohl nicht richtig ausprobiert, durch die Nutzung von Synergy kam es mir vor als wären die Clients eingefroren, aber es ist nur die Verbindung zum Router die unterbrochen ist.

waldecker schrieb:

... es ist nur die Verbindung zum Router die unterbrochen ist.

Wie hast Du gemerkt bzw. getestet, dass die Verbindung zum Router (kurz) unterbrochen ist? Versuch mal in dieser Zeit (d. h. wenn die Verbindung kurz unterbrochen ist) mit arping, ping und mit einem tcp-ping auf einen lauschenden TCP-Port des Routers. Das geht nicht alles auf einmal und muss auch vorher schon in der Kommandozeile vorbereitet sein.

waldecker schrieb:

[…] frieren die angeschlossenen Clients alle 9 Minuten für ein paar Sekunden ein.

Wenn Du an die Clients die IP-Adressen nur für 533 Sekunden verleihst, ist das zu erwarten. Was soll dieser Unfug?

[…] syslog und network-config im Anhang

Textausgaben bitte direkt im Beitrag, als Codeblock formatiert.

lubux schrieb:

Wie hast Du gemerkt bzw. getestet, dass die Verbindung zum Router (kurz) unterbrochen ist? Versuch mal in dieser Zeit (d. h. wenn die Verbindung kurz unterbrochen ist) mit arping, ping und mit einem tcp-ping auf einen lauschenden TCP-Port des Routers. Das geht nicht alles auf einmal und muss auch vorher schon in der Kommandozeile vorbereitet sein.

Zuerst bemerkt habe ich es in einer Citrix Session weil eine Meldung erschien von der Art "Verbindung unterbrochen, versuche Wiederherstellung". Da ich Synergy verwende waren Maus und Tastatur zur gleichen Zeit kurzzeitig eingefroren. Im Syslog habe ich entdeckt das alle 9 Minuten eine Meldung erscheint vom Typ "net_ratelimit: 6 callbacks suppressed" wobei die Zahl schwankt zwischen 2 und 129, meistens lag sie um die 30. Hab dann per ping versucht herauszufinden wie lange der "Ausfall" anhält.

Ping zum Router (seq 25-28 fehlen):

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) Bytes Daten.
64 Bytes von 192.168.0.1: icmp_seq=1 ttl=64 Zeit=0.297 ms
64 Bytes von 192.168.0.1: icmp_seq=2 ttl=64 Zeit=0.257 ms
64 Bytes von 192.168.0.1: icmp_seq=3 ttl=64 Zeit=0.255 ms
64 Bytes von 192.168.0.1: icmp_seq=4 ttl=64 Zeit=0.208 ms
64 Bytes von 192.168.0.1: icmp_seq=5 ttl=64 Zeit=0.217 ms
64 Bytes von 192.168.0.1: icmp_seq=6 ttl=64 Zeit=0.249 ms
64 Bytes von 192.168.0.1: icmp_seq=7 ttl=64 Zeit=0.813 ms
64 Bytes von 192.168.0.1: icmp_seq=8 ttl=64 Zeit=0.280 ms
64 Bytes von 192.168.0.1: icmp_seq=9 ttl=64 Zeit=0.273 ms
64 Bytes von 192.168.0.1: icmp_seq=10 ttl=64 Zeit=0.232 ms
64 Bytes von 192.168.0.1: icmp_seq=11 ttl=64 Zeit=0.199 ms
64 Bytes von 192.168.0.1: icmp_seq=12 ttl=64 Zeit=0.204 ms
64 Bytes von 192.168.0.1: icmp_seq=13 ttl=64 Zeit=0.201 ms
64 Bytes von 192.168.0.1: icmp_seq=14 ttl=64 Zeit=0.227 ms
64 Bytes von 192.168.0.1: icmp_seq=15 ttl=64 Zeit=0.213 ms
64 Bytes von 192.168.0.1: icmp_seq=16 ttl=64 Zeit=0.237 ms
64 Bytes von 192.168.0.1: icmp_seq=17 ttl=64 Zeit=0.221 ms
64 Bytes von 192.168.0.1: icmp_seq=18 ttl=64 Zeit=0.280 ms
64 Bytes von 192.168.0.1: icmp_seq=19 ttl=64 Zeit=0.304 ms
64 Bytes von 192.168.0.1: icmp_seq=20 ttl=64 Zeit=0.300 ms
64 Bytes von 192.168.0.1: icmp_seq=21 ttl=64 Zeit=0.214 ms
64 Bytes von 192.168.0.1: icmp_seq=22 ttl=64 Zeit=0.970 ms
64 Bytes von 192.168.0.1: icmp_seq=23 ttl=64 Zeit=0.269 ms
64 Bytes von 192.168.0.1: icmp_seq=24 ttl=64 Zeit=0.286 ms
64 Bytes von 192.168.0.1: icmp_seq=29 ttl=64 Zeit=0.202 ms
64 Bytes von 192.168.0.1: icmp_seq=30 ttl=64 Zeit=0.302 ms
64 Bytes von 192.168.0.1: icmp_seq=31 ttl=64 Zeit=0.236 ms
64 Bytes von 192.168.0.1: icmp_seq=32 ttl=64 Zeit=0.205 ms
64 Bytes von 192.168.0.1: icmp_seq=33 ttl=64 Zeit=0.216 ms
64 Bytes von 192.168.0.1: icmp_seq=34 ttl=64 Zeit=0.245 ms
64 Bytes von 192.168.0.1: icmp_seq=35 ttl=64 Zeit=0.205 ms
64 Bytes von 192.168.0.1: icmp_seq=36 ttl=64 Zeit=0.824 ms
64 Bytes von 192.168.0.1: icmp_seq=37 ttl=64 Zeit=0.282 ms
64 Bytes von 192.168.0.1: icmp_seq=38 ttl=64 Zeit=0.218 ms
64 Bytes von 192.168.0.1: icmp_seq=39 ttl=64 Zeit=0.228 ms
64 Bytes von 192.168.0.1: icmp_seq=40 ttl=64 Zeit=0.230 ms
64 Bytes von 192.168.0.1: icmp_seq=41 ttl=64 Zeit=0.294 ms
64 Bytes von 192.168.0.1: icmp_seq=42 ttl=64 Zeit=0.300 ms
64 Bytes von 192.168.0.1: icmp_seq=43 ttl=64 Zeit=0.236 ms
64 Bytes von 192.168.0.1: icmp_seq=44 ttl=64 Zeit=0.219 ms
64 Bytes von 192.168.0.1: icmp_seq=45 ttl=64 Zeit=0.244 ms
64 Bytes von 192.168.0.1: icmp_seq=46 ttl=64 Zeit=0.266 ms
64 Bytes von 192.168.0.1: icmp_seq=47 ttl=64 Zeit=0.284 ms
64 Bytes von 192.168.0.1: icmp_seq=48 ttl=64 Zeit=0.252 ms
64 Bytes von 192.168.0.1: icmp_seq=49 ttl=64 Zeit=0.248 ms
64 Bytes von 192.168.0.1: icmp_seq=50 ttl=64 Zeit=0.299 ms
64 Bytes von 192.168.0.1: icmp_seq=51 ttl=64 Zeit=0.273 ms
64 Bytes von 192.168.0.1: icmp_seq=52 ttl=64 Zeit=0.273 ms
64 Bytes von 192.168.0.1: icmp_seq=53 ttl=64 Zeit=0.245 ms
^C
--- 192.168.0.1 ping-Statistik ---
53 Pakete übertragen, 49 empfangen, 7,54717% Paketverlust, Zeit 53220ms
rtt min/avg/max/mdev = 0.199/0.286/0.970/0.153 ms

kB schrieb:

waldecker schrieb:

[…] frieren die angeschlossenen Clients alle 9 Minuten für ein paar Sekunden ein.

Wenn Du an die Clients die IP-Adressen nur für 533 Sekunden verleihst, ist das zu erwarten. Was soll dieser Unfug?

Mit verleihen meinst du die lease-time in der dhcpd.config? Die steht auf dem default Wert von 600. Keine Ahnung wo die 533 herkommt.

default-lease-time 600;
max-lease-time 7200;
interface enp3s0;

waldecker schrieb:

Ping zum Router (seq 25-28 fehlen):

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) Bytes Daten.
--- 192.168.0.1 ping-Statistik ---
53 Pakete übertragen, 49 empfangen, 7,54717% Paketverlust, Zeit 53220ms

Teste mal auch mit arping:

sudo apt install iputils-arping

sudo arping -c 53 -I enp3s0 192.168.0.1

(Interface evtl. anpassen).

waldecker schrieb:

[…] lease-time in der dhcpd.config […] steht auf dem default Wert von 600

Bei welchem Programm soll dieser Unfug Standard sein?

600 wären dann 10 Minuten. Genauso unsinnig wie 533. Während der Erneuerung der Ausleihe kommt es natürlich zur Unterbrechung der IP-Verbindung.

Keine Ahnung wo die 533 herkommt.

Forsche nach. Konfiguriere den DHCP-Server sinnvoll.

kB schrieb:

Bei welchem Programm soll dieser Unfug Standard sein?

Steht so im wiki, z.B. hier: ISC-DHCPD (Abschnitt „Konfiguration“) in der Beispielkonfiguration

Habe den Wert auf 6000 hoch gesetzt. Jetzt steht im syslog

Dec  8 17:53:19 server dhcpcd[1149]: enp3s0: leased 192.168.0.129 for 5343 seconds

Die Verbindung zum Client wird aber dennoch unterbrochen, nur seltener.

lubux schrieb:

Teste mal auch mit arping:

sudo apt install iputils-arping

sudo arping -c 53 -I enp3s0 192.168.0.1

(Interface evtl. anpassen).

Da ich die lease time verlängert habe tritt die Störung nicht mehr so oft auf, werde es am Wochenende nochmal mit kürzerer Zeit probieren und dir dann den output liefern.

lubux schrieb:

Teste mal auch mit arping:

sudo arping -c 53 -I enp3s0 192.168.0.1

(Interface evtl. anpassen).

Hier der output vom Client:

$ date; arping -c 60 -I eno1 192.168.0.1;date
Fr 9. Dez 11:40:14 CET 2022
ARPING 192.168.0.1 von 192.168.0.3 eno1
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.752ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.729ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.748ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.775ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.763ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.768ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.728ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.764ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.728ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.764ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.741ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.747ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.729ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.771ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.760ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.753ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.742ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.776ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.793ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.762ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.741ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  1.378ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.778ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.769ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.766ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.764ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.780ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.764ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.765ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.753ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.760ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.744ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.752ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.751ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.744ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.836ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.758ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.719ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.743ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.760ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.747ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.742ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.765ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.762ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.696ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.786ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.757ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.739ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.760ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.757ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.752ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  1.355ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  1.389ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.761ms
Unicast antworten von 192.168.0.1 [A8:A1:59:42:92:B3]  0.755ms
Sende 60 Proben (1 Broadcast(s))
55 Antwort(en) erhalten
Fr 9. Dez 11:41:14 CET 2022

syslog Server:

Dec  9 11:41:01 server dhcpcd[1149]: enp3s0: leased 192.168.0.129 for 5333 seconds

waldecker schrieb:

Hier der output vom Client:

$ date; arping -c 60 -I eno1 192.168.0.1;date
Fr 9. Dez 11:40:14 CET 2022
Sende 60 Proben (1 Broadcast(s))
55 Antwort(en) erhalten
Fr 9. Dez 11:41:14 CET 2022

OK, ... ähnlich wie beim ping (icmp), auf 5 von den 60 arp-requests, hat er nicht mit einem arp-reply geantwortet.

lubux schrieb:

OK, ... ähnlich wie beim ping (icmp), auf 5 von den 60 arp-requests, hat er nicht mit einem arp-reply geantwortet.

ja. Bleibt die Frage warum wird die Verbindung für ca. 5 Sekunden unterbrochen?

Hat den niemand eine Idee warum die Verbindung unterbrochen wird?

Inzwischen hat es sich noch verschlimmert, immer wenn die erste Ethernet-Karte von der Fritzbox eine neue IP-Lease bekommt (aktuell alle 24h) unterbricht die 2. Ethernet-Karte sämtliche Verbindungen und lässt sich nur durch einen Reboot wieder aktivieren.

Normalerweise wird eine DHCP-Lease vor Ablauf derselben verlängert, wenn Client und Server sich erreichen. Der Client bekommt also im Normalfall keine neue IP-Adresse und es gibt keine Netzwerkunterbrechung, selbst wenn die Leasedauer nur auf unsinnigen 60s stehen würde. Hier ist das recht gut erklärt.

So wie du das schilderst, fallen mir folgende Möglichkeiten ein:

• Eine Firewall (am Client oder am Server) verhindert die Lease-Verlängerung.

• Dein DHCP-Server ist falsch konfiguriert.

• Die neue DHCP-Server-Version kommt mit übernommenen alten Konfigurationsdateien nicht zurecht.

• Sowohl auf der Fritzbox und deinem Server ist ein DHCP-Server aktiv, beide verteilen im gleichen DHCP-Scope

immer wenn die erste Ethernet-Karte von der Fritzbox eine neue IP-Lease bekommt (aktuell alle 24h) unterbricht die 2. Ethernet-Karte sämtliche Verbindungen und lässt sich nur durch einen Reboot wieder aktivieren.

Auch so ein Nonsens, siehe oben. In deiner Konfiguration stimmt irgendwas ganz und gar nicht. Wieso stehen die Netzwerkkarten des Servers überhaupt auf DHCP? Setze beide auf eine feste IP des jeweiligen Netzbereiches. DHCP nur für die Clients im LAN.

Internet ←→ Fritzbox (DHCP-Server aus) ←→ Dein Multifunktions-Server mit DHCP-Server ←→ Clients