Pihole an FB7590ax dauerhaftes DNS Problem

Kartoffel · October 7, 2023, 7:33pm

Hallo zusammen,
ich kenne mich leider recht wenig aus, versuche aber möglichst nachvollziehbar mein Setup zu beschreiben. Ich habe bei meiner Suche viele Ähnliche, aber eben nicht das gleiche Problem gefunden. Spoiler: Es folgt eine Textwall.

Ich habe eine FB7590ax und einen Raspi 4 gemäß Anleitung von c´t3003 (utube-Kanal) installiert. DHCP macht bei meinem Setup die Fritzbox (aka Fritte oder FB) und lokaler DNS der Pi. PiPi hängt per Kabel an der FB.
Abweichend von oben erwähnter Anleitung habe ich:

dem pi bei Installation einen individuellen Hostnamen (nennen wir ihn Pi55box) gegeben und
dem pi bei Installation eine Statische IP ausserhalb des DHCP Adressbereichs vergeben.
KEIN IPv6 eingerichtet.

Einstellungen FB:

OS 7.56 (nach u.a. Stromausfall später dann Update auf OS 7.57)
IPv6 ist komplett deaktiviert.
Internet->Zugangsdaten->DNS-Server (=Upstream DNS?):
--- Andere DNSv4-Server verwenden (dns2.digitalcourage.de mit der 46.182.19.48 und dns.digitale-gesellschaft.ch mit IP 185.95.218.42) aktiv
--- Öffentlicher DNS-Server: Bei Störungen auf öffentliche DNS-Server zurückgreifen aktiv
--- DNS over TLS (DoT) Verschlüsselte Namensauflösung im Internet, Zertifikatsprüfung und Fallback auf unverschlüssselte Namensauflösung zulassen aktiv
Heimnetz->Netzwerk->Netzwerkeinstellungen->
--- DHCP aktiv -> Range xx.20 bis xx.200 (ich habe diverse Geräte in den Bereichen xx.10 bis xx.19 sowie xx.201 bis xx.220 noch Geräte mit statischen IP-Adressen). Lease: 1 Tag
--- Lokaler DNS-Server: xx.4 (=statische IP des Pi, wird von der FB an die Clients als DNS ausgeliefert lt. ipconfig /all)
Internet->Filter->Listen->Netzwerkanwendungen:
--- Regel "DNS" angelegt, Protokoll UDP + TCP: Quell-sowie Zielports 53 + 853 bei beiden Protokollen hinterlegt
Internet->Filter->Zugangsprofile:
--- Profil "Alles ausser DNS" angelegt und dort als "gesperrte Anwendungen" die o.g. Regel "DNS" hinterlegt.
Allen Netzwerkgeräten im "normalen" LAN o.g. Profil zugewiesen mit Ausnahme des pi, der darf alles.

Einstellungen PI (am Anfang):
-Settings->DNS
--- Upstream DNS 2x Haken unter IVv4 bei Cloudflare (DNSSEC)
--- Allow only local requests aktiv
--- Never forward non-FQDN aktiv
--- Never forward reverse lookups aktiv

Das lief so Monatelang Problemlos, Werbung wurde im "normalen" LAN blockiert, Webinterface aufrufen od. per ssh aufschalten aufs pi ging alles.

->> Plötzlich Problem:
Dann mussten wir an einem Tag mehrfach für eine längere Dauer im Haus Strom abstellen. Danach ging nur noch mein Gastnetz. Pi war zwar noch Aufrufbar über Web-UI + ssh, die DNS-Anfragen der Clients kamen auch laut Log rein und wurden weitergereicht oder eben geblockt aber an den Clients selbst ließ sich nichts mehr aufrufen oder anpingen. Pihole ließ sich nicht mehr updaten, Update Gravity z.B. brachte Fehlermeldung "DNS resolutuion is currently unavailable" und nach Zeit dann "DNS resolution is not available". Alle möglichen Settings bzgl. DNS im pi geändert, alles mehrfach neugestartet, zigmal probiert. Nichts. Kein Ping raus, kein nslookup möglich bzw. ohne Antwort egal wohin. Dann ist mir aufgefallen, dass die Uhrzeit im Log des Pi von der Uhrzeit der tatsächlichen Anfrage des Clients abwich, später sogar um Tage. Nach zig Versuchen, dies zu korrigieren (btw: die FB fungiert lokal als NTP, interessiert den pi leider null weil ich vermutlich zu blöd bin das einzustellen) habe ich erstmal aufgegeben.

->> Folge: Pi abgeklemmt, lokal DNS an der FB wieder auf die Fritte gestellt, alles geht wieder (bis auf pihole).

->> Dann: Ehrgeiz.
Nach diversem Lesen und erfolgloser rumprobiererei wie neuverbinden d. Clients / Netzwerkadapter deaktivieren+aktivieren, div. Settings an der Fritte u. pihole erstmal SD karte platt gemacht u. Pihole via Imager komplett neu draufgespielt. Aktuell folgende Versionsstände: Pi-Hole V5.17.1, FTL V5.23, WebInterface V5.20.1.
Am pi noch folgendes eingestellt:
-Settings->DNS
--- die beiden Häkchen beim Upstream DNS (Cloudflare) rausgemacht
--- Custom1 IPv4 -> die IP der FB eingetragen und aktiviert
--- Use Conditional Forwarding aktiviert (Eingetragen: IP meines LANs xx.0/24, IP der FB, Domäne: fritz.box)

Siehe da: Hurra es läuft. Einen halben Tag ungefähr. Dann das gleiche wie nach dem Stroausfall, Webseiten lassen sich aus "normalem" LAN nicht mehr öffnen, Gastnetz geht natürlich. Nur dieses Mal gabs keinen Stromausfall.
Jetzt hab ich als lokalen DNS wieder die Fritte und Problem lässt sich einfach an- und wieder abstellen, indem ich am PC in den Adapteroptionen unter IPv4 -> DNS mal von automatisch auf manuell stelle und statisch die IP des PI eintrage, Adapter kurz deaktiviere u. wieder aktiviere -> im Pihole Log erscheint die Anfrage grün, aber Website öffnet sich nicht, stelle ich DNS wieder auf automatisch beziehen (also DNS=FB) geht wieder alles, aber wird halt nix geblockt.

->> Resultat: Überteuert gekaufter Raspberry4 (170 Tacken mit Gehäuse u. NT!!) dient nun als Briefbeschwerer.

Hatte nun vor lauter Frust den pi abgeklemmt und stromlos gemacht, eben nochmal angeklemmt-> Hunderte wenn nicht mehr Einträge im Log vom Client "pi.hole" (und nicht wie bei Installation festgelegter Hostname "Pi55box") mit Ziel diverser NTP wie z.B. "3.debian.pool.ntp.org.fritz.box" oder "2.debian.pool.ntp.org", alles grün aber Zeitstempel falsch und bei Reply steht überall "N/A".

Hilfe. Bitte. Gerne auch Teams Session o.ä.

->> Debug-Log:
Das mit dem Debug Log bzw. "nur Token-URL hochladen" habe ich nicht verstanden, ich kann aus der Pi55box nichts hochladen aus Gründen und ich bekomme auch keine "Token - URL", zumindest sehe ich keine.

Fehlermeldungen im Log / Auszug aus der Log:
*** [ DIAGNOSING ]: Operating system
[i] Distro: Debian
[i] Version: 11
[✗] dig return code: 10
[✗] dig response: dig: couldn't get address for 'ns1.pi-hole.net': failure
[✗] Error: dig command failed - Unable to check OS

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
xx.4/24

[✓] IPv6 address(es) bound to the eth0 interface:
xx.:890b:4218/64

[i] Default IPv4 gateway(s):
xx.1

Pinging first gateway xx.1...
[✗] Gateway did not respond. (Why is a default gateway important for Pi-hole?)

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

Bucking_Horn · October 7, 2023, 10:59pm

Ausgeführt auf dem RPi4, was geben folgende Kommandos zurück:

cat /etc/resolv.conf

dig heise.de

dig heise.de @8.8.8.8

dig heise.de @192.168.178.1

wobei 192.168.178.1 der Adresse Deiner FritzBox entsprechen sollte.

Kartoffel · October 7, 2023, 11:45pm

Huhu,
Ausgabe:

piadmin@MYDEVICEPI1:~ $ cat /etc/resolv.conf
# Generated by resolvconf
domain fritz.box
nameserver xxx.xxx.xxx.4

piadmin@MYDEVICEPI1:~ $ dig heise.de

; <<>> DiG 9.16.44-Debian <<>> heise.de
;; global options: +cmd
;; connection timed out; no servers could be reached

piadmin@MYDEVICEPI1:~ $ dig heise.de @8.8.8.8

; <<>> DiG 9.16.44-Debian <<>> heise.de @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached

piadmin@MYDEVICEPI1:~ $ dig heise.de @xxx.xxx.xxx.1

; <<>> DiG 9.16.44-Debian <<>> heise.de @xxx.xxx.xxx.1
;; global options: +cmd
;; connection timed out; no servers could be reached

Ich kann vom Pi nichtmal mehr die FB anpingen, von meinem PC aus geht beides, nslookup des Pi sowie FB und ping auch ohne Probleme (habe aktuell die FB wieder als lokalen DNS weil sonst nichts mehr geht). Es wirkt fast so, als hätte der Pi null Internet. Uhrzeit ist um etliche Stunden versetzt, ich bekomme nicht einmal die Uhrzeit gestellt. Ich bin da über einen älteren Beitrag hier und diverse andere Beiträge die Uhrzeit am Pi betreffend gestolpert, weshalb ich mich so an der Uhrzeit festbeisse.

Folgendes habe ich gerade eben (Sonntag, 8.10.2023 um ca. 1:38 Uhr gestartet (die IP dort ist die IP meiner FB, welche so konfiguriert ist, dass sie lokal als Zeitserver fungiert):

piadmin@MYDEVICEPI1:~ $ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2023-10-07 21:37:13 CEST; 21min ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 317 (systemd-timesyn)
     Status: "Idle."
      Tasks: 2 (limit: 8755)
        CPU: 387ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─317 /lib/systemd/systemd-timesyncd

Oct 07 21:37:12 MYDEVICEPI1 systemd[1]: Starting Network Time Synchronization...
Oct 07 21:37:13 MYDEVICEPI1 systemd[1]: Started Network Time Synchronization.
Oct 07 21:37:56 MYDEVICEPI1 systemd-timesyncd[317]: Timed out waiting for reply from xxx.xxx.xxx.1:123 (xxx.xxx.xxx.1).
Oct 07 21:39:10 MYDEVICEPI1 systemd-timesyncd[317]: Timed out waiting for reply from xxx.xxx.xxx.1:123 (xxx.xxx.xxx.1).
Oct 07 21:41:29 MYDEVICEPI1 systemd-timesyncd[317]: Timed out waiting for reply from xxx.xxx.xxx.1:123 (xxx.xxx.xxx.1).
Oct 07 21:45:55 MYDEVICEPI1 systemd-timesyncd[317]: Timed out waiting for reply from xxx.xxx.xxx.1:123 (xxx.xxx.xxx.1).
Oct 07 21:54:38 MYDEVICEPI1 systemd-timesyncd[317]: Timed out waiting for reply from xxx.xxx.xxx.1:123 (xxx.xxx.xxx.1).
piadmin@MYDEVICEPI1:~ $

Bucking_Horn · October 8, 2023, 12:07am

Die nslookups über Googles DNS-Server und die Fritzbox schlagen fehl.
Dein RPi4 kann keine DNS-Anfragen stellen, weil die angesprochenen DNS-Server samt und sonders nicht erreichbar sind.

Das verhindert auch den Zeitabgleich mit einem NTP-Server. Da ein RPi keine batteriegepufferte Echtzeituhr hat, würde ein Stromausfall die stark abweichende Zeit auch erklären.

Die Zeit könntest Du mit folgendem Kommando einstellen:

sudo timedatectl set-time '2023-10-08 02:00:00'

Sofern Du Pi-holes DNSSEC-Validierung aktiviert hast, könnte die falsche Zeit die DNS-Auflösung tatsächlich verhindern, weil die Validierung nur mit korrekter Zeit erfolgreich sein kann.

Allerdings würde es in diesem Fall zu einer Fehlermeldung in der DNS-Antwort kommen.

In Deinem Fall kann Dein RPi aber überhaupt keine DNS-Server erreichen.
Das deutet in der Regel auf eine blockierende Firewall hin.

Du solltest also auch nochmal Deine FritzBox-Konfiguration prüfen:

Es spricht vieles dafür, dass DNS auch für Deinen RPi4 blockiert wird.

Kartoffel · October 8, 2023, 1:20am

In der FB ist dem Pi das Standard-Profil "unbeschränkt" zugeordnet, da gibt es keine Sperre / Gesperrte Anwendung. Ich habe jetzt noch den Pi "Echtzeitpriorisiert", mehr kann ich dort AFAIK nicht einstellen.
DNSSEC-Validierung habe ich testweise auch kurz in der FB deaktiviert und dig auf heise erneut versucht, keine Veränderung.
Der Versuch, die Zeit einzustellen wurde mit "Failed to set time: Automatic time synchronization is enabled" quittiert.
Vorgestern lief noch alles für etliche Stunden, ohne Änderung an Regeln o.ä. funktioniert es nicht mehr, das spricht m.E. nicht für eine fehlerhafte Regel / Firewallsetting sonst hätte es doch direkt schon nicht funktionieren dürfen oder übersehe ich etwas?

Bucking_Horn · October 8, 2023, 8:48am

Mir ist keine solche Funktion in der FritzBox bekannt.
Wie bzw. wo hast Du das eingestellt?

Dann versuch's mal mit

sudo date --set '2023-10-08 11:00:00'

Was geben folgende Kommandos auf dem RPi4 zurück:

ip -4 address

ip route

Kartoffel · October 8, 2023, 5:08pm

Hallo, danke für Deine Unterstützung soweit.

DNSSEC-Validierung in der FB: HAbe ich wohl verwechselt mit DNS over TLS unter "Zugangsdaten->DNS-Server-> DNS over TLS (DoT)", dort gibt es eine Option "Zertifikatsprüfung für verschlüsselte Namensauflösung im Internet erzwingen". Auf dem Pi ist unter den DNS-Einstellungen der Punkte "Use DNSSEC" NICHT aktiv gesetzt.
Die Zeit konnte ich mit "sudo date --set '2023-10-08 11:00:00'" (bzw. der zum Zeitpunkt der Eingabe aktuellen Zeit natürlich) anpassen, wird nun im Pi - Log korrekt angezeigt.

Ausgabe von "ip -4 address" und "ip route":

piadmin@MYDEVICEPI1:~ $ ip -4 address
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet xxx.xxx.xxx.4/24 brd xxx.xxx.xxx.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever

piadmin@MYDEVICEPI1:~ $ ip route
default via xxx.xxx.xxx.1 dev eth0 src xxx.xxx.xxx.4 metric 202
xxx.xxx.xxx.0/24 dev eth0 proto dhcp scope link src xxx.xxx.xxx.4 metric 202

Wobei "xxx.xxx...." für meinen lokalen ip-adressbereich steht, der passt soweit.[/spoiler]

Edit: Ich habe einmal alle Ausgaben der Kommandozeile zur besseren Übersicht in Spoiler gefasst.

Bucking_Horn · October 9, 2023, 6:25pm

Soweit man dass anhand der lesbaren Informationen ableiten kann, sehen die ip-Ausgaben ok aus.
(Private Adressbereiche können im allgemeinen bedenkenfrei geteilt werden, da diese nicht öffentlich erreichbar sind.).

Stimmt die IP-Adresse des Clients mit der in der FritzBox gelisteten IP für diesen RPi4 überein?

In diesem Fall hat eine eventuelle falsche Zeit keine direkte Auswirkung auf Pi-holes DNS-Server.

Hat sich durch die Aktualisierung der Zeit irgendeine Änderung ergeben?

Kartoffel · October 10, 2023, 5:52pm

Ja, statische IP des Pi stimmt mit der IP des Pi in der Netzwerkübersicht der FB überein.
Aktualisierung der Zeit im Pi inklusive Neustart des DNS - Resolver brachte leider auch keinen Erfolg, auch nicht nach komplettem Reboot.
Ich habe dann auch im Pi nochmal die DNS-Einstellungen geändert (IP der FB als Upstream DNS im Pi raus und statt dessen die Cloudflare IPv4 DNS angehakt und Conditional Forwarding deaktiviert+reboot). Mit gleichem negativem Ergebnis
Ich bin echt ratlos.

Mit den lokalen IP stimmt, da habe ich es wohl etwas übertrieben. Netzwerk ist 172.23.248.0/24

Bucking_Horn · October 10, 2023, 7:39pm

Gescheiterte pings würden ebenfalls auf ein Netzwerkproblem hindeuten.
Wie genau sehen Kommando und Ausgabe hier aus?

Kartoffel · October 11, 2023, 4:22pm

Aber nur vom Pihole aus, umgekehrt geht es problemlos:
C:\Users\CSM-GAMES>ping csmpi1

Ping wird ausgeführt für csmpi1.fritz.box [172.23.248.4] mit 32 Bytes Daten:
Antwort von 172.23.248.4: Bytes=32 Zeit<1ms TTL=64
Antwort von 172.23.248.4: Bytes=32 Zeit<1ms TTL=64
Antwort von 172.23.248.4: Bytes=32 Zeit<1ms TTL=64
Antwort von 172.23.248.4: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 172.23.248.4:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\Users\CSM-GAMES>nslookup 172.23.248.4
Server: fritz.box
Address: 172.23.248.1

Name: CSMPI1.fritz.box
Address: 172.23.248.4

Edit: Nachfolgend noch die Ausgabe wenn ich vom Pi die FB anpinge, darunter wenn ich vom PC aus die FB anpinge:
Pi an FB:
piadmin@CSMPI1:~ $ ping 172.23.248.1
PING 172.23.248.1 (172.23.248.1) 56(84) bytes of data.
From 172.23.248.4 icmp_seq=1 Destination Host Unreachable
From 172.23.248.4 icmp_seq=2 Destination Host Unreachable
From 172.23.248.4 icmp_seq=3 Destination Host Unreachable
From 172.23.248.4 icmp_seq=4 Destination Host Unreachable
From 172.23.248.4 icmp_seq=5 Destination Host Unreachable
From 172.23.248.4 icmp_seq=6 Destination Host Unreachable
From 172.23.248.4 icmp_seq=7 Destination Host Unreachable
From 172.23.248.4 icmp_seq=8 Destination Host Unreachable
From 172.23.248.4 icmp_seq=9 Destination Host Unreachable
^C
--- 172.23.248.1 ping statistics ---
12 packets transmitted, 0 received, +9 errors, 100% packet loss, time 11243ms
pipe 3
piadmin@CSMPI1:~ $

PC an FB:
C:\Users\CSM-GAMES>ping 172.23.248.1

Ping wird ausgeführt für 172.23.248.1 mit 32 Bytes Daten:
Antwort von 172.23.248.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 172.23.248.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 172.23.248.1: Bytes=32 Zeit<1ms TTL=64
Antwort von 172.23.248.1: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 172.23.248.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

EDIT 2: Ping Pi an FB via Hostname:
piadmin@CSMPI1:~ $ ping csm-fb1.fritz.box
ping: csm-fb1.fritz.box: Temporary failure in name resolution

wd9895 · October 11, 2023, 8:12pm

Ich habe da mal eine vielleicht naive Frage.
172.23.248.1 ist etwas unkonventionell für ein Heimnetzwerk.

Versucht der DNS nicht, das extern aufzulösen?

Bucking_Horn · October 11, 2023, 10:38pm

Da 172.23.248.4 -also der RPi selbst- hier direkt Destination Host Unreachable meldet, verlassen die ping-Pakete den Rechner überhaupt nicht.

Läuft auf dem RPi vielleicht eine Firewall, die ausgehenden Netzwerkverkehr filtert?

Und was steht auf dem RPi zu Deinem Router 172.23.248.1 in der Ausgabe von

arp -a

Vorsicht: Die Einträge enthalten die MAC-Adressen, die Du bedarfsweise aus der Ausgabe entfernen kannst.

Kartoffel · October 12, 2023, 5:51pm

Wüsste nicht wieso das extern aufgelöst werden sollte, ist doch auch privater IP-Adressbereich laut Wiki

Kartoffel · October 12, 2023, 6:09pm

Ausgabe:
piadmin@CSMPI1:~ $ arp -a
? (172.23.248.31) at HierDieMac PC [ether] on eth0
? (172.23.248.201) at HierDieMac Drucker [ether] on eth0
? (172.23.248.1) at on eth0
piadmin@CSMPI1:~ $

Bei FB "incomplete". Warum ist dort mein Drucker aber keins von den anderen ca. 25 Geräten ? Seltsam. Aber letzteres ist andere Baustelle vermutlich. Letzter Eintrag liest sich für mich als unwissenden jedenfalls "verdächtig". Heisse Spur?

Bucking_Horn · October 12, 2023, 7:36pm

Die arp-Tabelle enthält nur Einträge zu Geräten auf demselben Link, zu denen Dein RPi bereits Kontakt hatte (ein ping reicht dafür aus). Es wäre also normal, dass dort nicht alle Geräte auftauchen.

incomplete würde darauf hindeuten, dass von der FritzBox bislang keine Antwort kam.

Ich nehme an, dann gibt es auch in ip neigh keinen router REACHABLE-Eintrag für die FB?

$ ip neigh
(...)
fe80::<entfernt> dev eth0 lladdr 44:<entfernt> router REACHABLE

Das kann auch mit einem Hardware-Defekt zusammenhängen - Du solltest ggf. mal ein anderes Netzwerk-Kabel probieren.

Verwendest Du ggf. zusätzliches Netzwerk-Equipment (Router, Switch,...), das hier eine Rolle spielen könnte?

Kartoffel · October 12, 2023, 7:43pm

Die FB antwortet zumindest anderen Rechnern im Netz, auch denen, die am gleichen Switch wie der Pi hängen.
Den Pi habe ich bereits an diversen Switches mit diversen NW-Kabeln angeschlossen, überall das gleiche. Könnte höchstens noch direkt an die FB gehen aber hielte ich jetzt für recht unwahrscheinlich, dass 3 verschiedene NW-Kabel und just die Ports an den 3 Switches defekt sein sollten, wo ich den Pi eingesteckt habe.

Sorry, die Frage ist mir durchgegangen. Ich habe da zumindest nichts wissentlich zusätzlich installiert. Pihole via Imager auf Karte gezogen, die oben genannten Einstellungen im Installationsprozess gemacht, das wars.

EDIT:

Router ist meine FB

piadmin@CSMPI1:~ $ ip neigh
172.23.248.31 dev eth0 lladdr MacPC REACHABLE
172.23.248.201 dev eth0 lladdr MacDrucker STALE
172.23.248.1 dev eth0 FAILED

Bucking_Horn · October 12, 2023, 8:03pm

Die FritzBox ist von Deinem RPi aus nicht erreichbar.

Neben fehlerhafter Hardware könnte das evtl. auch noch an einer falschen Netzwerkmaske liegen, wenn RPi und Fritzbox nicht auf demselben liegen würden.

Aktuell geht der RPi davon aus, dass er die FB direkt erreichen kann (on link).
Layer-2-Switches auf der Strecke zwischen RPi und FB sind dabei kein Problem, aber sofern eines Deiner Netzwerk-Geräte als Layer-3-Switch agiert, müsste der Kontakt stattdessen über die MAC dieses Geräts laufen.

Wird Dein Netzwerk durch die Switches ggf. segmentiert, so dass sich nicht alle Geräte in demselben Subnetz befinden?

Kartoffel · October 12, 2023, 8:09pm

Nein "leider" kein segmentiertes Netzwerk. ICh wollte evtl. zukünftig mal zwei Vlans einrichten, habe damit aber noch nicht angefangen. Die aktuellen Switches wo der Pi hinter hängt sind unmanaged, mein L3 ist noch nicht in Betrieb.
Aber auch hier: Es lief ja erst Monatelang ohne Probleme, dann Stromausfall und Ende, nach vollständigem Neuaufsetzen des Pi lief er wieder ca. 16 Std. lang problemlos, bis er irgendwann über Nacht ausgestiegen ist .

Ich werde das Wochenende über relativ wenig Zeit haben, daher kann es sein, dass meine Antworten mit etwas mehr Verzögerung kommen.

Bucking_Horn · October 12, 2023, 8:16pm

Mir gehen auch gerade die Ideen aus.

Den Pi-hole-Bereich haben wir ja bereits seit einigen Posts verlassen.
Und da es sich anscheinend um ein ausgewachsenes Netzwerkproblem handelt, werde ich Dir leider nicht mehr allzuviel weiterhelfen können.