Schmetterhand
Anmeldungsdatum: 16. Mai 2015
Beiträge: 126
|
In meinem Heimnetzwerk sind verschiedene Linux-Rechner mittels Devolo-Adaptern (auch dLAN oder Powerline genannt) miteinander verbunden, und der zentrale Router ist eine Fritzbox. Nun habe ich mehrmals täglich ein paar wenige Minuten lang so eine Art „DNS-Ausfall“, wo ich dann bei frischen Verbindungsversuchen die anderen lokalen Rechner und auch Internet-Seiten nicht mehr per Domänen-Namen erreichen kann, nur noch über ihre direkte IP-Adresse. Während so einer Ausfallszeit ist aber die Fritzbox weder per Name noch mehr IP-Adresse erreichbar. Die vor so einem DNS-Ausfall gestarteten Daten-Verbindungen, wie z.B. das Herunterladen einer Datei, laufen aber auch während des DNS-Ausfalls uneingeschränkt weiter. Es ist also „nur“ ein DNS-Problem in diesen paar Minuten. Nach ein paar Minuten funktioniert dann wieder alles. Ich habe bereits versucht, die verschiedenen Devolo-Adapter zu vertauschen oder ein neueres Modell mit einem älteren zu ersetzen, was aber keine Wirkung zeigte. Diese störenden Ausfälle kommen zwischen ein- bis zehnmal pro Tag vor. Kann mir jemand hier vielleicht weiterhelfen? Gruß P.S.: Übrigens waren die gleichen Ausfälle auch mit einem älteren Fritzbox-Modell zu beobachten, falls dies jemandem weiterhilft.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Schmetterhand schrieb: […] der zentrale Router ist eine Fritzbox.
Welche Type? Wie alt? Ist diese Fritzbox auch der DNS-Server? Zeige bitte die Ausgaben dieser Befehle als Codeblock formatiert: networkctl status
systemd-resolve --status | grep -i server -A3
[…] Während so einer Ausfallszeit ist aber die Fritzbox weder per Name noch mehr IP-Adresse erreichbar.
Fritzbox nicht erreichbar ⇒ DNS-Server nicht erreichbar (falls die Fritzbox diese Aufgabe wahrnimmt) ⇒ keine Namensauflösung
[…] Übrigens waren die gleichen Ausfälle auch mit einem älteren Fritzbox-Modell zu beobachten
Tausche Deine Fritzbox mit einem jüngeren Exemplar! (Elektronik ist irgendwann kaputt.)
|
Schmetterhand
(Themenstarter)
Anmeldungsdatum: 16. Mai 2015
Beiträge: 126
|
kB schrieb: Welche Type? Wie alt?
Es ist eine Fritzbox 7360 aus dem Jahre 2016, also noch ziemlich neu.
Tausche Deine Fritzbox mit einem jüngeren Exemplar! (Elektronik ist irgendwann kaputt.)
Leider hatte ich mich unklar ausgedrückt. Ich meinte, daß mit meiner Vorgänger-Fritzbox der gleiche gelegentliche DNS-Ausfall kam wie mit der neuen. Allerdings passiert der DNS-Ausfall nicht generell bei allen Linux-Rechnern im Heimnetzwerk, sondern nur einzeln bei einem meiner x86-Rechner. Also nie zeitgleich im ganzen Heimnetz, und auch nie auf einem Raspberry Pi oder einem alten "iBook"-Mac (auch beide mit Ubuntu-Linux 16 LTS betrieben).
2. Ist diese Fritzbox auch der DNS-Server? Zeige bitte die Ausgaben dieser Befehle als Codeblock formatiert: networkctl status
systemd-resolve --status | grep -i server -A3
Ja, das ist sie. Wie gesagt, ist von solch einem Ausfall immer nur ein x86-Rechner gleichzeitig im Heimnetzwerk betroffen, nie mehrere. So kann es am ersten Rechner auftreten, und dann ein paar Stunden später am anderen, aber z.B. nie an erwähntem Pi oder Mac. Daher kann das Problem nicht am DNS der Fritzbox generell liegen, sodern „irgendwie“ am Zusammenspiel Linux-x86-PC, Devolo, Fritzbox. Als ich vor wenigen Jahren auf beiden x86-Rechnern noch Windows hatte, traten die Ausfälle übrigens nicht auf. Hier die gewünschten Ausgaben: $ networkctl status
WARNING: systemd-networkd is not running, output will be incomplete.
● State: n/a
Address: 192.168.2.12 on enp0s25
fe80::21a:a0ff:fe91:266 on enp0s25
Gateway: 192.168.2.1 (AVM GmbH) on enp0s25 $ systemd-resolve --status | grep -i server -A3
DNS Servers: 192.168.2.1
DNS Domain: fritz.box Gruß
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Schmetterhand schrieb: […] Allerdings passiert der DNS-Ausfall nicht generell bei allen Linux-Rechnern im Heimnetzwerk, sondern nur einzeln bei einem meiner x86-Rechner.
Das ist extrem bizarr.
[…]
$ networkctl status
WARNING: systemd-networkd is not running, output will be incomplete.
● State: n/a
Address: 192.168.2.12 on enp0s25
fe80::21a:a0ff:fe91:266 on enp0s25
Gateway: 192.168.2.1 (AVM GmbH) on enp0s25
Also hast Du an der Fritzbox herum gespielt! Damit endet die Gewährleistung aus Sicht des Herstellers. Welchen DHCP-Bereich hast Du auf der Fritzbox eingestellt? Werden die Rechner per DHCP konfiguriert? Alle? Bitte zeige die Ausgabe dieses Befehls, wenn das Netzwerk eines betroffenen Rechners funktioniert und von demselben Rechner, wenn es gestört ist. In diesem Fall poste den Inhalt der Datei Diagnose.txt später oder nach Übertragung zu einem anderen Rechner.
( ip -br link ; echo ; ip -4 route ; echo ; ip -4 addr; grep -v '#' /etc/resolv.conf ) | tee Diagnose.txt
|
Schmetterhand
(Themenstarter)
Anmeldungsdatum: 16. Mai 2015
Beiträge: 126
|
kB schrieb: Also hast Du an der Fritzbox herum gespielt! Damit endet die Gewährleistung aus Sicht des Herstellers.
Nein, es wurde nichts an der Fritzbox manipuliert, sondern lediglich per Browser in der Fritzbox-Oberfläche Einstellungen vorgenommen, wie z.B., daß die IP-Adressen des Heimnetzes bei 192.168.2.1 beginnen.
Welchen DHCP-Bereich hast Du auf der Fritzbox eingestellt?
Meine Fritzbox vergibt IPv4-Adressen von 192.168.2.10 bis 192.168.2.50 .
Werden die Rechner per DHCP konfiguriert? Alle?
Ja, das werden sie; und nachträglich habe ich für jeden Rechenr in der Fritzbox-Oberfläche das Häkchen „Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen“ aktiviert.
Bitte zeige die Ausgabe dieses Befehls, wenn das Netzwerk eines betroffenen Rechners funktioniert und
2. von demselben Rechner, wenn es gestört ist. In diesem Fall poste den Inhalt der Datei Diagnose.txt später oder nach Übertragung zu einem anderen Rechner.
( ip -br link ; echo ; ip -4 route ; echo ; ip -4 addr; grep -v '#' /etc/resolv.conf ) | tee Diagnose.txt
1. Bei funktionierendem Netzwerk (meine Mac-Adresse anonymisiert) :
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s25 UP 01:02:03:04:05:06 <BROADCAST,MULTICAST,UP,LOWER_UP>
default via 192.168.2.1 dev enp0s25 proto dhcp metric 100
169.254.0.0/16 dev enp0s25 scope link metric 1000
192.168.2.0/24 dev enp0s25 proto kernel scope link src 192.168.2.12 metric 100
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.2.12/24 brd 192.168.2.255 scope global dynamic noprefixroute enp0s25
valid_lft 2643508sec preferred_lft 2643508sec
nameserver 127.0.0.53
search fritz.box 2. Das werde ich hier schreiben, sobald ich mal wieder einen Ausfall habe. Danke und Gruß
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16458
|
kB schrieb: Also hast Du an der Fritzbox herum gespielt! Damit endet die Gewährleistung aus Sicht des Herstellers.
Mit Verlaub, das ist Humbug! Zum bestimmungsgemäßen Gebrauch (m)einer Fritz!Box gehört es, die Benutzeroberfläche zu starten und dort Einstellungen vorzunehmen, wie sie im Handbuch erläutert sind. Dazu gehört auch eine Änderung der IPV4-Adresse der Fritz!Box.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Schmetterhand schrieb: Während so einer Ausfallszeit ist aber die Fritzbox weder per Name noch mehr IP-Adresse erreichbar.
Wie sind während der Ausfallzeit die Ausgaben von:
arp -av
ip n s
?
Mit welchem Protokoll (tcp, udp, icmp, arp) ist die IP-Adresse der FritzBox, während der Ausfallzeit, nicht erreichbar?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Schmetterhand schrieb: kB schrieb:
[…] Nein, es wurde nichts an der Fritzbox manipuliert, sondern lediglich per Browser in der Fritzbox-Oberfläche Einstellungen vorgenommen
Das erste wollte ich Dir nicht unterstellen, sondern ich meinte mit meinem flapsigen „herum gespielt“ das zweite.
[…] Bitte zeige die Ausgabe dieses Befehls, wenn das Netzwerk eines betroffenen Rechners funktioniert und von demselben Rechner, wenn es gestört ist. […]
1. Bei funktionierendem Netzwerk […]
Soweit OK.
2. Das werde ich hier schreiben, sobald ich mal wieder einen Ausfall habe.
Also warten wir.
|
Schmetterhand
(Themenstarter)
Anmeldungsdatum: 16. Mai 2015
Beiträge: 126
|
Vielen Dank für Eure Antworten. lubux schrieb: Wie sind während der Ausfallzeit die Ausgaben von:
arp -av
ip n s
?
Mit welchem Protokoll (tcp, udp, icmp, arp) ist die IP-Adresse der FritzBox, während der Ausfallzeit, nicht erreichbar?
Ich denke, daß es TCP/IP ist (Netzwerk ist nicht mein Thema), da während eines DNS-Ausfalls (was 1-2min dauert) alle Adreßauflösungen des betroffenen x86-PCs nicht funktionieren: Im Browser, E-Mail, usw.; diese benutzen ja TCP/IP. Die anderen Protokolle sind für mich schwer zu überprüfen. kB schrieb: Soweit OK.
Wenigstens etwas von der Konfiguration stimmt schonmal ☺
Also warten wir.
Die DNS-Ausfälle kommen ja häufiger vor, als ich feststelle, da ich genau in den 1-2min des Ausfalls eine Adresse auflösen lassen muß, um das Problem zu bemerken. Bereits bestehende TCP/IP-Verbindungen (Dateiherunterladung) laufen ja uneingeschränkt weiter und zeigen also den DNS-Ausfall gar nicht an. lubux und kB: Beim nächsten DNS-Ausfall bringe ich jedenfalls die Ausgaben der Befehle. Gruß
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Schmetterhand schrieb: Ich denke, daß es TCP/IP ist (Netzwerk ist nicht mein Thema), da während eines DNS-Ausfalls (was 1-2min dauert) alle Adreßauflösungen des betroffenen x86-PCs nicht funktionieren: Im Browser, E-Mail, usw.; diese benutzen ja TCP/IP. Die anderen Protokolle sind für mich schwer zu überprüfen.
D. h. Du hast keinen Ping (icmp) auf die IP-Adresse der FritzBox gemacht? Für DNS (Namensauflösung) wird i. d. R. UDP benutzt. Geht aber auch mit TCP. Du kannst beim nächsten DNS-Ausfall Alles testen. Mit Linux (als OS) geht das z. B. so:
sudo tcpdump -c 300 -vvveni <Interface> arp or icmp or port 53
ping -c 3 <IP-Adresse-FritzBox>
sudo apt-get install iputils-arping
sudo arping -c 3 -I <Interface> -s <IP-Adresse-Laptop> <IP-Adresse-FritzBox>
dig +short heise.de @<IP-Adresse-FritzBox>
dig +short +tcp heise.de @<IP-Adresse-FritzBox>
(ohne spitze Klammern).
Für andere Betriebssysteme gibt es gleichwertige tools/Befehle für die Kommandozeile/Konsole.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Schmetterhand schrieb: […] Bereits bestehende TCP/IP-Verbindungen (Dateiherunterladung) laufen ja uneingeschränkt weiter und zeigen also den DNS-Ausfall gar nicht an.
Wirklich auch auf dem einen vom DNS-Ausfall konkret betroffenen Rechner?
|
Schmetterhand
(Themenstarter)
Anmeldungsdatum: 16. Mai 2015
Beiträge: 126
|
kB schrieb: Wirklich auch auf dem einen vom DNS-Ausfall konkret betroffenen Rechner?
Ja, wenn das Herunterladen schon vor dem DNS-Ausfall begonnen wurde. lubux schrieb: D. h. Du hast keinen Ping (icmp) auf die IP-Adresse der FritzBox gemacht? Für DNS (Namensauflösung) wird i. d. R. UDP benutzt. Geht aber auch mit TCP.
Achso, dann habe ich doch einen icmp-Ping gemacht, ich ließ mich nur durch "TCP/IP" dazu verleiten, daß ein Ping dann das TCP/IP-Protokoll benutzen würde.
Du kannst beim nächsten DNS-Ausfall Alles testen.
Genau. Eben hatte ich wieder einen DNS-Ausfall. Hier alle gewünschten Ausgaben, mit folgenden anonymisierten Mac-Adressen:
"01:02:03:04:05:06" betroffener Rechner, an dem ich die Befehle ausgeführt habe. "09:08:07:06:05:04" ein anderer Rechner im Netzwerk "0a:0b:0c:0d:0e:0f" Fritzbox
$ ( ip -br link ; echo ; ip -4 route ; echo ; ip -4 addr; grep -v '#' /etc/resolv.conf ) | tee Diagnose.txt
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s25 UP 01:02:03:04:05:06 <BROADCAST,MULTICAST,UP,LOWER_UP>
default via 192.168.2.1 dev enp0s25 proto dhcp metric 100
169.254.0.0/16 dev enp0s25 scope link metric 1000
192.168.2.0/24 dev enp0s25 proto kernel scope link src 192.168.2.12 metric 100
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.2.12/24 brd 192.168.2.255 scope global dynamic noprefixroute enp0s25
valid_lft 2659078sec preferred_lft 2659078sec
nameserver 127.0.0.53
search fritz.box
$ arp -av
? (192.168.2.10) auf 09:08:07:06:05:04 [ether] auf enp0s25
? (192.168.2.1) auf 0a:0b:0c:0d:0e:0f [ether] auf enp0s25
Einträge: 2 Ignoriert: 0 Gefunden: 2
$ ip n s
192.168.2.10 dev enp0s25 lladdr 09:08:07:06:05:04 STALE
192.168.2.1 dev enp0s25 lladdr 0a:0b:0c:0d:0e:0f DELAY
fe80::922b:34ff:fe50:7a70 dev enp0s25 lladdr 09:08:07:06:05:04 STALE tcpdump gab eine riesige Liste mit 300 Paketen aus, die ich etwas zurechtgeschnitten habe. Die Zeilen, welche sich voneinander unterschieden, z.B. die normalen Pakete und die "who-has" sowie "is-at", habe ich drin gelassen.
$ sudo tcpdump -c 300 -vvveni enp0s25 arp or icmp or port 53
tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
13:14:07.265959 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 85: (tos 0x0, ttl 64, id 45339, offset 0, flags [DF], proto UDP (17), length 71)
192.168.2.12.52963 > 192.168.2.1.53: [bad udp cksum 0x85a2 -> 0x2dfe!] 32016+ A? apis.google.com.fritz.box. (43)
13:14:18.663794 0a:0b:0c:0d:0e:0f > 01:02:03:04:05:06, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.12 tell 192.168.2.1, length 46
13:14:18.663817 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.12 is-at 01:02:03:04:05:06, length 28
13:14:19.274322 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 89: (tos 0x0, ttl 64, id 46725, offset 0, flags [DF], proto UDP (17), length 75)
192.168.2.12.56071 > 192.168.2.1.53: [bad udp cksum 0x85a6 -> 0x61af!] 40381+ AAAA? support.mozilla.org.fritz.box. (47)
13:14:19.274359 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 79: (tos 0x0, ttl 64, id 46726, offset 0, flags [DF], proto UDP (17), length 65)
192.168.2.12.35924 > 192.168.2.1.53: [bad udp cksum 0x859c -> 0xd49e!] 55481+ AAAA? support.mozilla.org. (37)
13:14:19.274382 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 79: (tos 0x0, ttl 64, id 46727, offset 0, flags [DF], proto UDP (17), length 65)
192.168.2.12.53286 > 192.168.2.1.53: [bad udp cksum 0x859c -> 0x6be7!] 6303+ A? support.mozilla.org. (37)
13:14:19.274404 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 89: (tos 0x0, ttl 64, id 46728, offset 0, flags [DF], proto UDP (17), length 75)
192.168.2.12.43802 > 192.168.2.1.53: [bad udp cksum 0x85a6 -> 0x94da!] 46463+ A? support.mozilla.org.fritz.box. (47)
13:14:19.304429 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 46733, offset 0, flags [DF], proto UDP (17), length 63)
192.168.2.12.40310 > 192.168.2.1.53: [bad udp cksum 0x859a -> 0x5076!] 53059+ A? fritzchen.fritz.box. (35)
13:14:19.304466 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 46734, offset 0, flags [DF], proto UDP (17), length 60)
192.168.2.12.40348 > 192.168.2.1.53: [bad udp cksum 0x8597 -> 0x5db4!] 37416+ A? discordapp.com. (32)
13:14:19.304489 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 46735, offset 0, flags [DF], proto UDP (17), length 63)
192.168.2.12.45185 > 192.168.2.1.53: [bad udp cksum 0x859a -> 0xb6b0!] 15102+ AAAA? fritzchen.fritz.box. (35)
13:14:19.304511 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 84: (tos 0x0, ttl 64, id 46736, offset 0, flags [DF], proto UDP (17), length 70)
192.168.2.12.46105 > 192.168.2.1.53: [bad udp cksum 0x85a1 -> 0xf83f!] 48300+ A? discordapp.com.fritz.box. (42)
13:14:19.663790 0a:0b:0c:0d:0e:0f > 01:02:03:04:05:06, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.12 tell 192.168.2.1, length 46
13:14:19.663815 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.12 is-at 01:02:03:04:05:06, length 28
[…]
300 packets captured
315 packets received by filter
11 packets dropped by kernel Diese Passage, welche in jeder Zeile vorkommt, sieht seltsam aus [bad udp cksum 0x85a2 -> 0x2dfe!] . Dann wäre es doch UDP? Und wer korrumpiert die Pakete, daß die Prüfsumme nicht mehr stimmt? Ich habe das gleiche Kommando bei funktionierender Verbindung getestet; es kam zwar auch ein paar mal dieses [bad udp cksum] , aber meistens hieß es [udp sum ok] . $ dig +short heise.de 192.168.2.1
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
dig +short +tcp heise.de 192.168.2.1
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached Zu diesem letzten Kommando… sudo arping -c 3 -I enp0s25 -s 192.168.2.12 192.168.2.1 … bin ich leider nicht mehr gekommen, solange der DNS-Ausfall war. Gruß
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Schmetterhand schrieb: Achso, dann habe ich doch einen icmp-Ping gemacht, ich ließ mich nur durch "TCP/IP" dazu verleiten, daß ein Ping dann das TCP/IP-Protokoll benutzen würde.
Und wie war das Ergebnis des Ping? Schmetterhand schrieb: "01:02:03:04:05:06" betroffener Rechner, an dem ich die Befehle ausgeführt habe. "0a:0b:0c:0d:0e:0f" Fritzbox
$ ip n s
192.168.2.10 dev enp0s25 lladdr 09:08:07:06:05:04 STALE
192.168.2.1 dev enp0s25 lladdr 0a:0b:0c:0d:0e:0f DELAY
fe80::922b:34ff:fe50:7a70 dev enp0s25 lladdr 09:08:07:06:05:04 STALE
$ sudo tcpdump -c 300 -vvveni enp0s25 arp or icmp or port 53
tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
13:14:07.265959 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 85: (tos 0x0, ttl 64, id 45339, offset 0, flags [DF], proto UDP (17), length 71)
192.168.2.12.52963 > 192.168.2.1.53: [bad udp cksum 0x85a2 -> 0x2dfe!] 32016+ A? apis.google.com.fritz.box. (43)
13:14:18.663794 0a:0b:0c:0d:0e:0f > 01:02:03:04:05:06, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.12 tell 192.168.2.1, length 46
13:14:18.663817 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.12 is-at 01:02:03:04:05:06, length 28
13:14:19.274322 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 89: (tos 0x0, ttl 64, id 46725, offset 0, flags [DF], proto UDP (17), length 75)
192.168.2.12.56071 > 192.168.2.1.53: [bad udp cksum 0x85a6 -> 0x61af!] 40381+ AAAA? support.mozilla.org.fritz.box. (47)
13:14:19.274359 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 79: (tos 0x0, ttl 64, id 46726, offset 0, flags [DF], proto UDP (17), length 65)
192.168.2.12.35924 > 192.168.2.1.53: [bad udp cksum 0x859c -> 0xd49e!] 55481+ AAAA? support.mozilla.org. (37)
13:14:19.274382 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 79: (tos 0x0, ttl 64, id 46727, offset 0, flags [DF], proto UDP (17), length 65)
192.168.2.12.53286 > 192.168.2.1.53: [bad udp cksum 0x859c -> 0x6be7!] 6303+ A? support.mozilla.org. (37)
13:14:19.274404 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 89: (tos 0x0, ttl 64, id 46728, offset 0, flags [DF], proto UDP (17), length 75)
192.168.2.12.43802 > 192.168.2.1.53: [bad udp cksum 0x85a6 -> 0x94da!] 46463+ A? support.mozilla.org.fritz.box. (47)
13:14:19.304429 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 46733, offset 0, flags [DF], proto UDP (17), length 63)
192.168.2.12.40310 > 192.168.2.1.53: [bad udp cksum 0x859a -> 0x5076!] 53059+ A? fritzchen.fritz.box. (35)
13:14:19.304466 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 46734, offset 0, flags [DF], proto UDP (17), length 60)
192.168.2.12.40348 > 192.168.2.1.53: [bad udp cksum 0x8597 -> 0x5db4!] 37416+ A? discordapp.com. (32)
13:14:19.304489 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 77: (tos 0x0, ttl 64, id 46735, offset 0, flags [DF], proto UDP (17), length 63)
192.168.2.12.45185 > 192.168.2.1.53: [bad udp cksum 0x859a -> 0xb6b0!] 15102+ AAAA? fritzchen.fritz.box. (35)
13:14:19.304511 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype IPv4 (0x0800), length 84: (tos 0x0, ttl 64, id 46736, offset 0, flags [DF], proto UDP (17), length 70)
192.168.2.12.46105 > 192.168.2.1.53: [bad udp cksum 0x85a1 -> 0xf83f!] 48300+ A? discordapp.com.fritz.box. (42)
13:14:19.663790 0a:0b:0c:0d:0e:0f > 01:02:03:04:05:06, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.12 tell 192.168.2.1, length 46
13:14:19.663815 01:02:03:04:05:06 > 0a:0b:0c:0d:0e:0f, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.2.12 is-at 01:02:03:04:05:06, length 28
$ dig +short heise.de 192.168.2.1
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
dig +short +tcp heise.de 192.168.2.1
;; connection timed out; no servers could be reached
;; connection timed out; no servers could be reached
Die Kommunikation zwischen dem Rechner mit der IP-Adresse 192.168.2.12 und der FritzBox funktioniert. Nur die FritzBox antwortet nicht, mit ihrem source-Port 53 (DNS, per UDP und TCP). Mach mal jetzt und bei einem DNS-Ausfall, einen Portscan auf den TCP-Port 53 der FritzBox:
ip n s
nc -zv 192.168.2.1 53 EDIT: Ich sehe gerade, dass Du dig nicht richtig angewendet hast:
dig +short heise.de 192.168.2.1
statt
dig +short heise.de @192.168.2.1
dig +short +tcp heise.de @192.168.2.1 EDIT 2: Wie sind jetzt die Ausgaben von:
host -T dns.fritz.box 192.168.2.1
cat /etc/resolv.conf
? EDIT3: Mach mal als _Test_ und temporär (ca. 1 Woche), in die systemweite "/etc/crontab" folgenden Eintrag (als letzte Zeilen):
*/2 * * * * root /usr/bin/arping -q -c 3 -w 10 -b -f -I enp0s25 -s 192.168.2.12 192.168.2.1 > /dev/null 2>&1
# -----
Die Wirksamkeit des Eintrags kannst Du mit:
sudo tcpdump -c 30 -vvveni enp0s25 arp
testen/feststellen.
|
Schmetterhand
(Themenstarter)
Anmeldungsdatum: 16. Mai 2015
Beiträge: 126
|
lubux schrieb: Und wie war das Ergebnis des Ping?
Er hat nicht funktioniert: Nach ca. 10s Wartezeit sagt der Ping "Destination host not found". Das genaue Ergebnis kann ich nachliefern.
Die Kommunikation zwischen dem Rechner mit der IP-Adresse 192.168.2.12 und der FritzBox funktioniert. Nur die FritzBox antwortet nicht, mit ihrem source-Port 53 (DNS, per UDP und TCP).
Mach mal jetzt und bei einem DNS-Ausfall, einen Portscan auf den TCP-Port 53 der FritzBox:
ip n s
nc -zv 192.168.2.1 53
Jetzt:
$ ip n s
192.168.2.10 dev enp0s25 lladdr 09:08:07:06:05:04 STALE
192.168.2.1 dev enp0s25 lladdr 0a:0b:0c:0d:0e:0f REACHABLE
fe80::922b:34ff:fe50:7a70 dev enp0s25 lladdr 09:08:07:06:05:04 STALE
$ nc -zv 192.168.2.1 53
Connection to 192.168.2.1 53 port [tcp/domain] succeeded!
Ich sehe gerade, dass Du dig nicht richtig angewendet hast:
Da hätte ich genauer lesen müssen. Beim nächsten Ausfall dann…
Wie sind jetzt die Ausgaben von:
host -T dns.fritz.box 192.168.2.1
cat /etc/resolv.conf
$ host -T dns.fritz.box 192.168.2.1
Using domain server:
Name: 192.168.2.1
Address: 192.168.2.1#53
Aliases:
dns.fritz.box has address 217.237.150.188
dns.fritz.box has address 217.237.151.142
$ cat /etc/resolv.conf
nameserver 127.0.0.53
search fritz.box Nachtrag: Ich sah gerade erst Deine letzte Bearbeitung, lubux. Was macht denn das Kommando genau? Ich habe versucht es zu rekonstruieren, aber das ging über meine Fähigkeiten. Ansonsten werde ich es mal eintragen in die Crontab. Gruß
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Schmetterhand schrieb: […] Diese Passage, welche in jeder Zeile vorkommt, sieht seltsam aus [bad udp cksum 0x85a2 -> 0x2dfe!] . Dann wäre es doch UDP?
Ja, das ist eine Fehlerquelle. Konkret handelt es sich um DNS-Anfragen, die in UDP-Paketen transportiert werden. Installiere bitte das Paket ethtool! Zeige die aktuellen Einstellungen der Ethernet-Schnittstellen-Hardware: sudo ethtool --show-features enp0s25 und die Art der PCI-Karte: lspci -s 00:19 -nnk
Möglicherweise hilft es, die Prüfsummenbildung in der Hardware abzuschalten.
|