Fritzbox 6591: Verbindung zum Internet bricht ab - nur Neustart hilft

[PeterPawn]

kann ich mit nicht vorstellen.

Ich sehe tatsächlich nicht, was es an (zusätzlichem) Erkenntnisgewinn bringen soll, wenn man das in dieser Reihenfolge macht (zusätzlich gegenüber dem, was schon getestet wurde). Es geht also nicht darum, daß ich den Sinn der Kommandos nicht verstünde - ich kann nur nicht erkennen, was damit an Schlußfolgerungen zu ziehen wäre, egal wie das Ergebnis ausfällt.

Warum ich das so sehe, habe ich versucht zu erklären - wenn man tatsächlich den ARP-Cache im Verdacht hat, muß man ihm zumindest vor der ersten Abfrage auch die Chance lassen, schon vorhandene Einträge zu invalidieren (siehe o.a. Link zu MS bzgl. der Timings) oder eben genau vor dem ersten arp-Kommando noch einmal das alles machen, was man ansonsten auch getan hat (um eine Wiederholbarkeit zu erreichen) ... irgendwie hat man ja erst mal feststellen müssen, daß das Problem schon wieder aufgetreten ist.

Aber das ist eigentlich auch gar nicht der Kern meiner Aufforderung, die Ideen halt auch dazu zu schreiben, wenn man solche Tests vorschlägt - und die richtet sich ja auch nicht nur an Dich (auch wenn Du hier der "Aufhänger" warst). Ich finde es immer grenzwertig, wenn man irgendeine Idee hat, diese durch Tests (von anderen) verifizieren lassen will und gleichzeitig die "Executive" (ebenso wie alle anderen) aber im Dunklen läßt, wozu das eigentlich gut sein soll. Selbst wenn man am Ende mit seiner These daneben liegt - wen kümmert's?

Beim nächsten Leser kann die dann schon wieder zutreffend sein - auf diesem Weg löst man eben nicht nur das "akute" Problem, sondern im besten Falle auch noch solche, die noch gar nicht aufgetreten sind und wo die Leute erst später über eine Suchmaschine auf die Threads treffen. Und "diskutieren" kann man so eine Idee eben auch nur dann (vielleicht fällt dem Nächsten ja sogar noch eine bessere Möglichkeit ein, wie man etwas überprüfen könnte?), wenn sie auch auf dem Tisch liegt. Nur dann auch können andere begründete(!) Einwände gegen die These vorbringen oder ihrerseits weitere Ideen daraus entwickeln. Außerdem gibt das demjenigen, den man da in die Spur schicken will, zumindest das Gefühl, daß es nicht nur Beschäftigungstherapie oder Stochern im Nebel ist.

Denn auch mit dem vorgeschlagenen Test durch einen Freund (in #36) habe ich so meine Verständnisprobleme, zumindest so wie es dort steht ... ich weiß zwar tatsächlich nicht, ob die 6591 überhaupt den Stealth-Mode unterstützt und schon gar nicht, ob der hier beim TO aktiviert ist oder nicht. Aber ohne diese Informationen ebenfalls zu kennen, könnte niemand ein Ergebnis: "Nein, die Box läßt sich aus dem Internet auch nicht anpingen." auch in jedem Falle richtig einordnen - es sei denn, man macht das schon einmal, BEVOR der Fehler überhaupt auftritt und kann sich damit sicher sein, daß es tatsächlich funktioniert, solange das Problem nicht aufgetreten ist.

Und ich bin mir auf der anderen Seite eigentlich auch ziemlich sicher, daß hier längst nicht jeder verstanden hat/verstehen kann (anhand des bisher dazu Geschriebenen), daß Du mit DEINER These letztlich explizit die Verbindung zwischen dem verwendeten Client und der FRITZ!Box "im Verdacht" hast (egal wohin da dann gepingt wird - ab Gateway ist Schluß mit ARP und allem anderen auf Layer2, also KANN ARP auch nicht die Ursache für Probleme jenseits der FRITZ!Box (in Richtung Internet) sein) - oder zumindest der Ansicht bist, daß die FRITZ!Box auf irgendwelche ARP-Requests nicht antworten würde (oder zumindest nicht schnell genug) und damit Deinerseits VOR dem Provider-Netz suchst.

Was durchaus auch legitim ist (nicht falsch verstehen bitte) - WENN es tatsächlich einen Unterschied macht, ob ein Endpoint für noch funktionierende Verbindungen nun AUF oder HINTER der FRITZ!Box (aus Richtung Internet) liegt ... und DAS müßte man dann ggf. erst einmal richtig prüfen (lassen), denn ich habe immer noch keine passende Erklärung dafür gelesen, warum nun der Aufruf des Speed-Tests von AVM noch funktionieren soll, wenn doch alle anderen Internet-Verbindungen Probleme machen und die erste ausbleibende Antwort beim ping jetzt der Aufhänger für weitere Suchen sein soll.

Es ist ja noch nicht einmal richtig geklärt (sofern ich es nicht übersehen habe), ob diese fehlende Antwort nun daher rührt, daß der Request das Ziel nicht erreicht hat oder ob die Antwort nicht wieder zurück kam. Wenn die ausgehenden Pakete aber doch alle ihr Ziel erreichen sollten (das kann man tatsächlich nur testen, wenn man einen Server im Internet im Zugriff hat, auf dem man auch die eingehenden Requests überwachen kann), dann fehlt mir komplett die Phantasie, was das noch mit dem ARP-Protokoll zu tun haben sollte. Und ich sehe eben nicht, wie die vorgeschlagenen Tests da irgendwie weiter helfen sollten bei der Ermittlung, ob nun der Hin- oder der Rückweg für die ICMP-Pakete nicht funktioniert - beides ergibt dasselbe Fehlerbild bei der Ausgabe des Kommandos.

Ja, ich kann mir sogar noch irgendwelche Umstände vorstellen, bei denen tatsächlich nach einer gewissen Laufzeit (durch Überschreiben von Stellen im Speicher, wo eigentlich die - korrekte - MAC-Adresse liegen sollte) ein Problem mit ARP-Responses der FRITZ!Box auftreten KÖNNTE - nur fehlt mir dann vollkommen die Phantasie, warum sich das danach plötzlich wieder ändern sollte (bzw. das wären schon sehr, sehr seltsame "race conditions"), denn ab dem zweiten ICMP-Request kommt da ja wieder eine Reaktion.

Andererseits habe ich auch Probleme zu verstehen, warum eine FRITZ!Box ihrerseits tatsächlich mittels ARP-Requests nach MAC-Adressen von Clients suchen sollte (macht sie bei Dir ja auch nur ca. alle 25 Sekunden) bzw. was das nun wieder beweisen oder widerlegen soll ... wenn sie ihrerseits hin und wieder nachschaut, ob einer der Clients noch da ist (und das macht sie auch für ältere Geräte, die sie noch von früher kennt - Dein ARP-Protokoll ist da eher ungewöhnlich und ich tippe mal darauf, daß bei Dir die Netzwerkumgebung der FRITZ!Box "sehr aufgeräumt" ist) und/oder einen Service auf Port 80 laufen hat, ist das (wenn sonst nichts passiert im Netz) m.W. das Einzige, was da einen ARP-Request durch die Box auslösen könnte. Und wie sollte dieser Request und die Frage, ob der Client darauf nun antwortet oder nicht, mit den geschilderten Problemen im Zusammenhang stehen? Ich verstehe es halt wirklich nicht - daher ja die Hoffnung, es mit der passenden Erklärung zu begreifen.

Wenn in der Gegenrichtung ein Client etwas von ihr (der Box) oder aus dem Internet will, hat sie dessen Adresse in dem Paket, was vom Client kommt - sowohl die (interne) IP- als auch die MAC-Adresse. Die wird dann auch vom PA in die Session eingetragen (das kann man sich mit Shell-Zugriff auf die Box und showpainfo sehr schön ansehen) und die Antworten aus dem Internet werden dann direkt (von der Hardware) auf die passende MAC-Adresse (des Clients) geändert und vom Switch weitergeleitet - dafür muß die Box nicht erst mittels ARP nach der richtigen MAC-Adresse suchen (das ist eben deutlich anders mit der Hardware-Beschleunigung, als mit irgendeinem Software-Router unter Linux - der KÖNNTE tatsächlich mal in die Verlegenheit kommen, mittels ARP nach dem Ziel für ein eintreffendes Paket zu suchen, wenn er die MAC-Adresse nicht mehr im Cache hat).

---

Nach dem Update auf die 7.29 hat sich das Verhalten weder verschlechtert noch gebessert.

O.K., das war m.E. so deutlich noch nicht zu lesen - ja, ich hatte mich hinsichtlich dessen, daß Du Deinerseits etwas von einem Update auf 07.29 geschrieben hättest, sogar vertan. Das ist ja erst am 01.11.2021 erschienen und der Thread wurde am 29.10.2021 gestartet (inkl. der Feststellung, daß jetzt (also "damals") die 07.28 installiert war).

Nur müßt Ihr (das richtet sich an die beiden, die das Problem auch haben) Euch jetzt mal entscheiden, ob ihr VOR oder HINTER der FRITZ!Box (oder AUF ihr) nach dem Problem suchen wollt (irgendwo muß man halt anfangen bei einer systematischen Suche). Wenn tatsächlich alle Clients betroffen sind und auch dieselben Symptome zeigen, dann ist die Box erst einmal der kleinste gemeinsame Nenner. Dann müßte man feststellen, ob es wirklich nur die Verbindungen betrifft, die DURCH die Box gehen sollen ... wenn sich auch beim zweiten Fall feststellen läßt, daß z.B. die Telefonie immer noch funktioniert. Die braucht zwar auch nur wenig Bandbreite (da sollte das auch mit den schlechteren Werten VOR dem Reset aus #1 noch klappen), aber irgendwie ist ja immer noch nicht so ganz klar, ob da nun die Bandbreite am Anschluß tatsächlich so gering ist oder ob das nur der Art und Weise geschuldet ist, wie gerade der AVM-Test (Zack) mißt (und nur messen kann, wenn er im Browser läuft).

Die Feststellung im zweiten Fall, daß alle internen Verbindungen noch problemlos funktionieren (die bei zwei WLAN-Clients ja auch über die Box müssen, weil jeder Client mit dem AP nur verschlüsselt kommuniziert und nur der AP das entschlüsseln und weiterleiten kann - dann eben wieder für den anderen Client verschlüsselt), sollte eigentlich das Hauptaugenmerk erst mal von der FRITZ!Box auf das CM (oder die Hardware zwischen CM und dem FRITZ!OS) lenken - im optimalen Fall ist es sogar noch möglich, einen Paketmitschnitt auf der FRITZ!Box zu starten (das sind ja beides eigene Boxen, da sollte die Funktion zugänglich sein) und zu schauen, was an das CM rausgeht. Wobei das dann auch wieder das zu beobachtende System beeinflußt - denn damit die Pakete dann auch alle über die CPU (also den ATOM-Prozessor) gehen, müßte eigentlich die Paketbeschleunigung (zumindest die in Hardware) wieder abgeschaltet werden - das macht das FRITZ!OS i.d.R. dann automatisch. Ansonsten enthielte so ein Mitschnitt nur einen Bruchteil der Pakete - nämlich diejenigen, die eine Verbindung aufbauen (und eine PA-Session initiieren) und diejenigen, die sie wieder abräumen (bei TCP).

Ich bin eigentlich nicht mal mehr sicher, daß es bei beiden Boxen tatsächlich dasselbe Problem ist, denn diese Feststellung bei der zweiten Box:

Alle Geräte im Heimnetz haben keinen Internetzugang (Werder Lan noch W-Lan angebundene)

paßt ja nicht dazu, daß offensichtlich beim TO der Windows-PC durchaus noch in der Lage war, die AVM-Seite für einen Speed-Test aufzurufen und zwar auch noch VOR dem Neustart der Box (davon gibt es ja ein "Beweisfoto" in #1) - da kam der Windows-PC also durchaus noch ins Internet. Das wäre ja dann doch ein anderes Fehlerbild.

---

Ich würde als nächstes mal beim Auftreten des Problems die Support-Datei speichern (dann gehen die Infos beim Neustart auch nicht alle verloren) ... das soll ja (bei beiden berichteten Fällen) noch funktionieren. Dort könnte man dann auch den ARP-Cache der Box sehen (glaube ich mich jedenfalls zu erinnern - wenn auch aus dem procfs gelesen und nicht mit arp -a erzeugt), auch wenn ich persönlich hier keinen Zusammenhang sehen würde.

Aber gleichzeitig ist da der DNS-Status zu sehen (ob mit den letzten Cache-Einträgen, weiß ich aber nicht mehr genau - kann man in der /bin/supportdata nachlesen bei den aicmd-Aufrufen für den multid) und üblicherweise auch die Sessions des PA - leider aber auch nur diese (dank Option -x). Andere Angaben (wie die max. genutzten Sessions u.ä.) fehlen in der Support-Datei - aber zumindest würden existierende Einträge in der Session-Table zeigen, daß/ob da noch Verbindungen nach außen vorhanden sind oder nicht ... das ist auf alle Fälle einfacher, als eine Vielzahl von Clients einzeln abzugrasen und zu schauen, ob die noch können oder nicht.

Man darf zwar bei den Puma7-Boxen auch nie aus dem Auge verlieren, daß es da noch das CM auf dem ARM-Core gibt und daß auch dieses System beim Neustart auf Grundstellung geht (das ist ja auch keine Zauberei/Blackbox, sondern nur ein weiteres Linux-System) - aber gegen ein "generelles Problem" auch mit dem CM spricht eben immer noch die Tatsache, daß der AVM-Speed-Test weiterhin erreichbar war nach #1.

BTW ... wenn man die Support-Datei im Problemfall von der Box liest, kann/sollte man ruhig noch ein "Dauer-Ping" nebenher laufen lassen, das auf ein Ziel im Internet gerichtet ist - das sollte dann eine entsprechende PA-Session erzeugen. Diese haben (iirc) bei IPv4+ICMP ein Timeout von 3 Sekunden - man könnte also auch gezielt im Abstand von 5 Sekunden pingen (bei Linux gibt es eine Option dafür, beim Windows-Kommando müßte man das mit einzelnen Paketen (-n 1 als Option) und einer passenden Schleife selbst organisieren) und dabei dann (halbwegs) sicher sein, daß JEDESMAL eine neue PA-Session dafür eröffnet wird. Ob bei der 6591 das Timeout auch 3 ist, kann man dann wieder in der Support-Datei sehen, wenn es dort eine entsprechende Session (pkttype=IPv4+ICMP) gibt - ich kann das nur auf älteren Puma6-Modellen prüfen.

---

Und wenn man sich nicht allzu sehr auf eine einzelne These versteifen will (egal, ob die nun ARP oder PA heißen mag), dann wären (wenn das Problem endlich wieder auftritt) noch ein paar zusätzliche Versuche mit unterschiedlichen Ziel-Hosts (im LAN, im Provider-Netz und jenseits dieses Netzes) nützlich, um differenziertere Aussagen zu erhalten, was nun geht und was nicht. Die DNS-Server des Providers liegen üblicherweise noch im Netz des Providers - und auch den Weg dorthin, sollte man einfach mal mit dem bereits erwähnten traceroute protokollieren (und dabei gleich sicherstellen, daß man tatsächlich im Netz des Anbieters geblieben ist - was heute selbst mit whois nicht mehr ganz so einfach zu ermitteln ist, seitdem die Provider auch kleinere Blöcke verkaufen oder tauschen) und zwar schon zu einem Zeitpunkt, wo das Problem noch gar nicht besteht. Man kann den Fehlerzustand halt nur dann mit dem "Normalzustand" vergleichen, wenn man letzteren zuvor wenigstens einmal festgestellt und festgehalten hat - z.B. indem man sich mal den nächsten Hop im Provider-Netz heraussucht und notiert, damit man den als ersten mit einem ping testen kann, wenn mal wieder gar nichts zu gehen scheint.

Wenn man erst mal nur abwarten will, ob das Problem nicht vielleicht doch schon von alleine verschwunden ist, riskiert man eben auch, daß man weitere (sinnvolle) Tests erst dann wieder vornehmen kann (solange man sich nicht schon vorbereitet hat), wenn das Problem beim übernächsten Mal wieder auftritt, denn manchmal machen nachträgliche Vergleiche (um den Normalzustand zu ermitteln) nach dem Neustart, damit man wieder "ins Internet" kommt, einfach keinen richtigen Sinn mehr, wenn man deren Ergebnis mit Tests vor dem Neustart vergleichen will - das geringste Risiko für Fehlinterpretationen besteht nun mal dann, wenn das alles "aus einem Lauf" ist.

 

[sf3978]

Ich sehe tatsächlich nicht, was es an (zusätzlichem) Erkenntnisgewinn bringen soll, wenn man das in dieser Reihenfolge macht (zusätzlich gegenüber dem, was schon getestet wurde).

Der TO hat lt. seiner Aussage, mit seinem Gerät erstmal keinen Internetzugang und der Ping zeigt auch lt . deiner Aussage, bei der 1. icmp-sequence einen Paket loss. Ich wollte sehen ob dieser Paket loss bei der 1. icmp-sequence, durch einen temporär unvollständigen arp-cache-Eintrag verursacht wird.
Der 1. "arp -a"-Befehl soll zeigen, ob der arp-cache-Eintrag für den Router, in seinem Gerät evtl. (noch) unvollständig ist. Ein Ping ins Internet oder besser zu seinen Router kann dazu führen, dass der arp-cache-Eintrag in seinem Gerät für den Router, wieder vollständig wird/.ist. Der 2. arp-cache-Befehl soll das zeigen oder auch nicht zeigen. Nicht mehr, aber auch nicht weniger, ... eigentlich eine Kleinigkeit/Lappalie/etc., was aber hier anscheinend ein Riesenproblem ist.

EDIT:

Andererseits habe ich auch Probleme zu verstehen, warum eine FRITZ!Box ihrerseits tatsächlich mittels ARP-Requests nach MAC-Adressen von Clients suchen sollte (macht sie bei Dir ja auch nur ca. alle 25 Sekunden) bzw. was das nun wieder beweisen oder widerlegen soll ... wenn sie ihrerseits hin und wieder nachschaut, ob einer der Clients noch da ist (und das macht sie auch für ältere Geräte, die sie noch von früher kennt - Dein ARP-Protokoll ist da eher ungewöhnlich und ich tippe mal darauf, daß bei Dir die Netzwerkumgebung der FRITZ!Box "sehr aufgeräumt" ist) und/oder einen Service auf Port 80 laufen hat, ist das (wenn sonst nichts passiert im Netz) m.W. das Einzige, was da einen ARP-Request durch die Box auslösen könnte

Ich habe jetzt noch mal nachgeschaut:

08:25:23.318004 3c:a6:2f:d3:0a:d6 > ##:##:##:17:62:b4, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.22 tell 192.168.178.1, length 28

Das Gerät mit der IP-Adresse 192.168.178.22 ist ein WLAN-Client z. Zt. an der FritzBox, für den in der FritzBox keine einzige Portweiterleitung konfiguriert ist und er lauscht auch nicht auf dem Port 80. Und trotzdem sendet die FritzBox arp-requests, als unicast direkt an die MAC-Adresse des Clienten.

08:25:25.708213 3c:a6:2f:d3:0a:d6 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.43 tell 192.168.178.1, length 46

Die 192.168.178.43 ist die IP-Adresse eines Clienten der FritzBox, der früher mal mit der FritzBox verbunden war. Keine Portweiterleitung in der FritzBox, für diese IP-Adresse konfiguriert. Hier sendet z. Zt. die FritzBox die arp-requests für diese IP-Adresse als broadcast, weil sie die MAC-Adresse dieses Clienten nicht mehr kennt.

 

[PeterPawn]

er lauscht auch nicht auf dem Port 80. Und trotzdem sendet die FritzBox arp-requests, als unicast direkt an die MAC-Adresse des Clienten.

Trotzdem schaut das FRITZ!OS regelmäßig nach Port 80 (und braucht dafür die MAC-Adresse) - antwortet da ein Service, wird im GUI aus dem Namen unter "Netzwerk" ein Link.

was aber hier anscheinend ein Riesenproblem ist.

Nein, das ist eigentlich auch für mich kein "Riesenproblem". Nur was genau versprichst Du Dir von der weiteren Untersuchung an dieser Stelle als Beitrag zur Lösung des eigentlichen Problems?

DAS zu verstehen, habe ich tatsächlich das erwähnte "Riesenproblem" (auch nach dem letzten Beitrag noch) - zumal die prinzipielle Funktion von ARP ja nicht in Frage gestellt werden kann, wenn überhaupt ein Zugriff auf die Box möglich ist, wofür/wovon es schon in #1 entsprechende Screenshots gab (und solange niemand falsche statische Einträge dort hinzufügt, sollte die dynamische Auflösung dann ja funktionieren - auch deshalb habe ich den Vorschlag, da selbst einen statischen Eintrag zu setzen, nicht verstanden). Denn das ist bei ALLEN Zugriffen dieselbe MAC-Adresse, an welche die Pakete gesendet werden, egal ob es an die Box selbst gerichtet oder nur Transit für sie ist.

Ich verstehe halt nicht, wo die Vermutung entsteht, das fehlende ICMP-Reply (dessen Bedeutung/Verantwortung für das eigentliche Problem mir auch nicht einleuchten will - und das geht ja offenbar nicht nur mir so ... aber man mag es ja als Symptom ansehen) wäre überhaupt relevant oder gar ursächlich für das Problem. (Und noch einmal: Damit will ich das gar nicht ausschließen, ich bettele nur fast um eine Erklärung, WO da ein Zusammenhang bestehen könnte.) Es ist immer noch vollkommen unklar, was genau die erste Antwort verhindert und das wird man mit einem ping auch kaum ermitteln können - und hier bin ich mir ziemlich sicher, daß Du das auch selbst weißt.

Das mag zwar auch interessant sein (und wenn's bei allen Zielen - auch lokalen - auftritt, auch ein zu (er)klärendes Phänomen), aber was zum Teufel soll das - unter Berücksichtigung der anderen Ergebnisse - mit dem ursprünglichen Problem zu tun haben? Da macht ein - auch schon hier von jemandem vorgeschlagenes - längeres Pingen schon deutlich mehr Sinn, weil man mit 5 Requests (Standard unter Windows) noch keine wirklich aussagekräftige Summary erhält.

Und genau das meinte ich auch bei meiner Aufforderung, die Ideen, was mit geforderten Tests ermittelt werden soll, auch anzuführen, weil dann gemeinsam(!) auch Alternativen (manchmal auch bessere) gefunden werden können oder andere vielleicht begründen können, warum etwas nicht sein kann oder zumindest unwahrscheinlich ist. Manchmal übersieht man eben auch selbst irgendwelche Ergebnisse, die nicht zur eigenen Theorie passen und wenn jemand anderes einen selbst davon auch noch überzeugen kann, erspart das den "Versuchskaninchen" sowohl Arbeit als auch Verwirrung, weil jeder etwas anderes von ihnen verlangt.

Wenn man hier anstelle des ping (meinetwegen auch nach Anzeige des ARP-Caches) ein tracert verwendet (unter Windows ist das auch ICMP), dann zeigt schon das ICMP zum ersten Hop (also der FRITZ!Box), ob das erste Paket bei der Box ankommt oder nicht. Wenn das aber gar nicht schon beim ersten Hop verloren geht, hat sich die ARP-These ja dann automatisch erledigt und wenn das doch der Fall sein sollte, dann hätte man das, was bisher nur eine Vermutung ist (s.o.), wenigstens erst einmal geprüft und bestätigt, bevor man da weiteren Aufwand investiert.

Ich will eigentlich nur verhindern, daß sich die weitere Suche (ohne schlüssige Begründung) auf einen Aspekt verengt, dessen Zusammenhang mit den beschriebenen Problemen (zumindest in Form einer plausiblen Theorie) nicht erklärt werden kann (was bisher m.E. auch noch nicht geschehen ist).

 

[Nice]

Nur müßt Ihr (das richtet sich an die beiden, die das Problem auch haben) Euch jetzt mal entscheiden, ob ihr VOR oder HINTER der FRITZ!Box (oder AUF ihr) nach dem Problem suchen wollt (irgendwo muß man halt anfangen bei einer systematischen Suche).

Ich gehe eher etwas prakmatischer an die Dinge ran, da quick & dirty oft schneller zum Ziel führt. Wenn das nichts hilft, kann man immer noch die ausführliche, aber zeitaufwändige Methode nutzen.

Die Modemwerte scheinen in Ordnung zu sein und einen "Wackelkontakt" bei den Steckern kann ich auch ausschließen. Nach einem Neustart der Fritzbox ist das Problem für eine gewisse Zeit auch behoben. Somit bleibt ein Problem im Netz von Kabel Vodafone oder eine nicht korrekte Konfiguration/Fehlfunktion der Frizbox übrig. Zunächst sollten doch die Dinge angegangen werden, die man selbst beeinflussen kann. Und dank der Hinweise auf die DNS-Konfiguration und die fehlende Aktivierung der IPv6-Unterstützung in den Einstellungen der Fritzbox habe ich dort erst einmal etwas experimentiert. Man soll den Tag zwar nicht vor dem Abend loben, aber seit 2 Tagen läuft alles wieder problemlos...

 

[PeterPawn]

Auch das ist ja erst mal wichtig zu wissen - es heißt ja auch, daß hier wohl Sendepause ist bis zum nächsten (Auftreten des) Problem(s) (oder für ewig, dann muß sich @Der D halt einen eigenen Thread aufmachen, wenn er nicht länger nur "zuschauen" will oder er "kapert" dann doch den hier) und dann müssen wir uns auch nicht unbedingt die Köpfe heiß schreiben.

 

[Nice]

[Edit Novize: Völlig überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Interessant wäre ja zu wissen, welche DNS- und IPv6-Einstellungen der zweite User mit diesem Problem derzeit in seiner Fritzbox hat und ob Änderungen ggf. Besserung bringen.

Die Köpfe können ja rauchen, wenn es um die Suche nach der Erklärung für das Phänomen geht ;-)

 

[sf3978]

Ich gehe eher etwas prakmatischer an die Dinge ran, da quick & dirty oft schneller zum Ziel führt.

OK. ... d. h. dein primäres Ziel ist, dass der Fehler nicht mehr vorkommt bzw. beseitigt ist (egal wie) und nicht die Fehlersuche bzw. die Fehlerursache? D. h., ein Erkenntnisgewinn ist für dich nicht so wichtig.

 

[Nice]

[Edit Novize: Völlig überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Natürlich ist es auch interessant, den der Grund für das Problem herauszufinden, aber zunächst geht es natürlich um die schnellstmögliche Beseitigung. Inzwischen ist ein zuverlässiger Internetanschluss ja genauso wichtig wie ein Strom- Gas- oder Wasseranschluss. Und darauf möchte man ja auch ungern verzichten.

 

[sf3978]

..., aber zunächst geht es natürlich um die schnellstmögliche Beseitigung.

Schnell nennst Du das? Dein 1. Beitrag war am 29.10.2021 und am 06.10.2021, 17:03 Uhr hast Du geschrieben:

Bei mit läuft seit gestern Abend übrigens alles wunderbar.

Das waren 7 Tage. Wenn Du mitgemacht hättest, wäre das Problem evtl. viel schneller beseitigt gewesen.

 

[Nice]

Das waren 7 Tage. Wenn Du mitgemacht hättest, wäre das Problem evtl. viel schneller beseitigt gewesen.

Zwischendurch funktioniert die Interverbindung immer mal wieder für einige Zeit, nach dem 29.10. sogar für 5 Tage.

Gestern Abend gab es aber wieder das bekannte Problem und daher habe ich natürlich den hier angeregten Test (arp -a / ping) durchgeführt und angehängt. Auffällig ist wieder, dass beim Pingtest erneut ein Paket verlorengegangen ist. Nach einem Neustart sind immer alle Pakete wieder ok. Heute gab es 2x kurz hintereinander das Problem. Da ich dabei nicht immer anwesend bin und meine Freundin inzwischen unvermittelt den Stecker zieht, war und ist eine genaue Analyse im Akutfall leider nicht immer möglich.

Eine Recherche im Internet hat gezeigt, dass dieses Problem wohl öfters einmal auftritt und dann unvermittelt wieder verschwindet, wenn man Glück hat. Einen konkreten Lösungsweg zur Problembehebung habe ich nirgendwo gefunden. Fast wie bei Herpes ;-)

Da die pragmatische Lösung hier offensichtlich nicht gegriffen hat, wird eine systematische Herangehensweise wohl sinnvoll sein. Falls ihr noch gewillt seid, mit mir die ganze Sache anzugehen, würde ich mich freuen und mein bestes versuchen. Allerdings musste ich bislang noch nie in die Untiefen der Fritzboxen eindringen, so dass eine genaue Beschreibung sehr hilfreich wäre.

 

[PeterPawn]

Meine Vorschläge, was man testen kann/sollte, liegen auf dem Tisch [1]. Da ja nun doch "nur" die von @sf3978 vorgeschlagenen Kommandos ausgeführt wurden, bin ich auf die Interpretation der Ergebnisse und der neu gewonnenen Erkenntnisse um so gespannter. Wenn das tatsächlich alles war, was an Tests gemacht wurde, warten wir ja jetzt offensichtlich erneut auf den nächsten Fehler - das ist mir irgendwie zu mühsam und wenn das in dem Tempo weitergeht, braucht man sich wenigstens keine Gedanken zu machen, was man zwischen Weihnachten und Neujahr macht, wenn's einem langweilig werden sollte.

[1] - falls das nicht mehr präsent sein sollte: Paketbeschleunigung versuchsweise deaktivieren, wenn man wirklich unbedingt lokal etwas unternehmen will - was aber immer noch "Aktionismus" wäre, solange man nicht wenigstens erst einmal geklärt hat, ob das nun wirklich VOR, AUF oder HINTER der Box liegt, wenn wieder mal irgendetwas nicht funktioniert. Daß man dazu schon VOR dem Auftreten des Problems tätig werden muß und nicht einfach abwarten kann, hatte ich weiter oben versucht zu begründen.

EDIT/PS: Man sollte auch "Hoffen und Harren" oder Gesundbeten nicht unbedingt mit Pragmatismus verwechseln - pragmatisch ist eine Lösung halt nur dann, wenn sie sich auch als tragfähig erweist und damit überhaupt erst eine "Lösung" wird. Das wirklich pragmatische Herangehen in diesem Falle wäre es wohl, wenn man einfach weiterhin den Stecker zieht und den Router neu startet, sobald man mal wieder nicht mehr ins Internet kommt - oder interpretieren wir da "Pragmatismus" unterschiedlich? Ich habe nach den Aussagen in #50 den Eindruck, daß die Freundin schon recht pragmatisch an die Sache herangeht.

 

[sf3978]

... (arp -a / ping) durchgeführt und angehängt. Auffällig ist wieder, dass beim Pingtest erneut ein Paket verlorengegangen ist.

Der arp-cache-Eintrag (ohne Ping) ist korrekt bzw. vollständig. Daran liegt es nicht.
Der 2. Ping auf die IP-Adresse der FritzBox, ist aber ohne packet loss. Mach mal beim nächsten Fehler, den 1. Ping auf die IP-Adresse 192.168.178.1 der FritzBox (und nicht auf die 1.1.1.1 bzw. nicht ins Internet).

 

[Nice]

...sobald sich etwas tut, melde ich mich. Seit der letzten Verbindungsaufnahme vor 72 Stunden, 31 Minuten und 15 Sekunden läuft aber alles wieder wie (eigentlich) gewohnt.

 

[Der D]

Hallo zusammen

Sorry dass ich mich erst jetzt wieder melde.
In der vergangenen Zeit hatte ich zwei Ausfälle, musste aber aus Zeitnöten der Router schnell neu starten da ich eine Onlinesitzung via Teams zu diesem Zeitpunt hatte.

Heute jedoch konnte ich den ping Test von meinem Laptop und einem Raspberry ausführen.
Seltsamerweise beide ohne Fehler, das Protokoll vom RPi steht unten:

root@Pi-Ager:~# arp -a
fritz.box (192.xxx.x.x) auf xy:xy:xy:xy:xy:xy [ether] auf wlan0
LAPTOP-1.fritz.box (192.xxx.x.x) auf xy:xy:xy.xy:xy:xy [ether]                                                                              auf wlan0
root@Pi-Ager:~# ping -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=17.7 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=14.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=18.6 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 14.408/16.893/18.588/1.802 ms
root@Pi-Ager:~# ping -c 3 192.xxx.x.x
PING 192.xxx.x.x (192.xxx.x.x) 56(84) bytes of data.
64 bytes from 192.xxx.x.x: icmp_seq=1 ttl=64 time=2.22 ms
64 bytes from 192.xxx.x.x: icmp_seq=2 ttl=64 time=5.58 ms
64 bytes from 192.xxx.x.x: icmp_seq=3 ttl=64 time=5.21 ms

--- 192.xxx.x.x ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 2.218/4.335/5.582/1.505 ms
root@Pi-Ager:~# arp -a
fritz.box (192.xxx.x.x) auf xy:xy:xy:xy:xy:xy [ether] auf wlan0
LAPTOP-1.fritz.box (192.xxx.x.xxx) auf xy:xy:xy:xy:xy:xy [ether]                                                                              auf wlan0

Weiter habe ich meine Fritte via Handy aus dem Mbilfunknetz auf die öffentliche IP angepingt und sie war ebenfalls erreichpar.

Dennoch habe ich via Iphone (mehrere), NAS und Laptop keinen Internetzugang. Im Broser vom Laptop bekomme ich die Meldung "keine Netzwerkverbindung" auf deHandys jeweils beim WLan "kein Internet" und das NAS gibt mir auch an, dass der Netzwerkzugang unterbrochen ist.

Es kann doch nicht sein, dass die Fritte in unregelmässigen Abständen einfach den Netzwerkzugang nicht weiter gibt?

 

[sf3978]

root@Pi-Ager:~# ping -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=17.7 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=14.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=18.6 ms

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 14.408/16.893/18.588/1.802 ms

Es kann doch nicht sein, dass die Fritte in unregelmässigen Abständen einfach den Netzwerkzugang nicht weiter gibt?

Dass der Internetzugang vorhanden ist bzw. weiter gegeben wird, zeigt dir ja der funktionierende Ping zu 1.1.1.1.
Beim nächsten mal, auch einen tcp-Portscan zu 1.1.1.1:53 machen:

:~$ nc -zv 1.1.1.1 53
Connection to 1.1.1.1 53 port [tcp/domain] succeeded!

um zu sehen ob nur icmp funktioniert und tcp ins Internet, evtl. nicht funktioniert?

 

[Der D]

[Edit Novize: Überflüssiges Fullquote auf relevanten Teil reduziert - siehe Forumsregeln]
...welche DNS- und IPv6-Einstellungen der zweite User mit diesem Problem derzeit in seiner Fritzbox hat

Ich denk ihr meint mich damit.
IVP6 habe ich bei mir gar nicht eringestellt,da ich herausgefunden habe, dass ich dadurch des öffteren die Meldung über ungewöhnlichen Datenverkehr von Google erhalte.
DNS habe ich auf beiden (primär und sekundär) 8.8.8.8 eingestellt und bin bis dato gut damit gefahren, bis dato jedenfalls, da nun ja die Internetverbindung zeitweise in meinem Netzwerk nicht zur Verfügung steht.

Hoffe damit geholfen zu haben

Edit: Das die Internetverbindung auf meinen Netwerkgeräter nicht funktioniert / ich die Browsermeldung "keine Netzwerkverbindung" erhalte

 

[sf3978]

..., da nun ja die Internetverbindung zeitweise in meinem Netzwerk nicht zur Verfügung steht.

BTW: Wenn der Ping zu 1.1.1.1 funktioniert, ist es nicht richtig, dass die Internetverbindung nicht funktioniert.

 

[Der D]

Beim nächsten mal, auch einen tcp-Portscan zu 1.1.1.1:53

Alles klar, werd ich machen sobald es wieder hängt.
Aber wie gesagt, es tritt sporadisch auf. Also nicht gleich shitstormen, wenn`s etwas dauert bis ich mich melde.

 

[Der D]

So, melde mich als geplagter Fritzbox-User zurück.
Gerade heim gekommen und die Frau hat reklamiert. Wieder den ganzen Tag kein Internet...

Umgehend den tcp-Portscan zu 1.1.1.1:53 ausgeführt.

Ergebniss ernüchternd: auch das scheint zu funktionieren.

root@Pi-Ager:~# nc -zv 1.1.1.1 53
Connection to 1.1.1.1 53 port [tcp/domain] succeeded!

Ich verzweifle langsam und die Frau is not amused. Ich werde mal AVM anschreiben, was die dazu sagen.

 

[HabNeFritzbox]

Klingt so also als wenn Internet an sich funktioniert, nur eben nicht mehr die DNS Auflösung in der FB.

Kannst ja Testweise mal 1.1.1.1 oder 8.8.8.8 als DNS im Client probieren, also am PC oder Laptop ob es dann geht.

Nicht vergessen wenn Problem besteht ne Supportdatei zu erstellen, diese möchte AVM dann auch haben zur Analyse.