Leute, schreibt doch Eure Vermutungen und was die vorgeschlagenen Tests dann zeigen oder auch nicht zeigen sollen, jeweils dazu. Ich gebe ehrlich zu, daß auch mir nicht so ganz klar ist, was mit
Code:
arp -a
ping 1.1.1.1
ping 192.168.178.1
arp -a
festgestellt werden soll.
Angenommen, die MAC-Adresse der FRITZ!Box (bzw. der Routers, weil's hier ja nicht um das konkrete Modell geht - wobei die Tatsache, daß es 2x 6591 ´sind und jeweils noch mit 07.29, ja auch bemerkenswert wäre) wäre nicht im ARP-Cache zu finden (das würde das
arp -a ja zeigen), dann wäre für die Suche nach dem Gateway (mal angenommen, daß das tatsächlich die FRITZ!Box ist, was bisher auch noch nicht wirklich "abgefragt" oder "gezeigt" wurde - allerdings ist die Wahrscheinlichkeit für falsche DHCP-Konfigurationen sicherlich gering), welches über seine IP-Adresse identifiziert wird, ein ARP-Request erforderlich und die Antwort würde dann auch - für eine begrenzte Zeit, aber das sind immerhin auch zwischen 15 und 45 Sekunden bei einem Windows-Client:
https://docs.microsoft.com/de-de/tr...ress-resolution-protocol-arp-caching-behavior - im ARP-Cache vorgehalten. Steht da ohnehin noch ein gültiger Eintrag drin, gehen die auszuliefernden Pakete auf Layer2 automatisch an die noch gespeicherte MAC-Adresse.
Nur ist das "auslösende"
ping (bzw. das von ihm generierte ICMP-Paket) ja mit hoher Wahrscheinlichkeit gar nicht das erste Paket, was an die FRITZ!Box/das Gateway zu senden ist ... wenn das erst dann erfolgen soll, wenn die Internet-Verbindung zumindest "gefühlt" nicht mehr funktioniert (wie gesagt, der Speed-Test aus #1 spricht genauso dagegen, wie die noch funktionierende Telefonie irgendwann später, daß es ein kompletter Ausfall ist), dann muß da ja irgendeine andere Aktion schon schiefgegangen sein (damit man's überhaupt bemerkt) ... meinetwegen bis hin zur DNS-Auflösung, wobei es da schon einen Unterschied macht, ob ein Name nicht aufgelöst werden kann (was kein
ping mit IP-Adressen wirklich zeigen wird, das prüft nur die Erreichbarkeit des Hosts - hier wäre dann ein
nslookup (unter Windows) wieder sinnvoller) oder ob anschließend die Pakete nicht bis zum Ziel durchdringen oder die Antworten den Rückweg nicht finden.
Nur wird dabei ein
ping auch nur eine Schwarz-/Weiß-Antwort liefern ... in dessen Ausgabe kann man nun mal nicht sehen, WO das Paket verworfen wird, es sei denn, man verwendet zusätzliche Optionen beim Aufruf (record route - unter Linux üblicherweise mittels
-R und unter Windows als
-r [I]n[/I], wobei
n nicht größer als 9 sein darf), was beim kompletten Verlust einer Antwort aber auch nichts hilft (weil die Hops ihre Adressen jeweils als zusätzliche Header-Info einfügen und das Ziel den kompletten Inhalt dann erst zurück sendet - da muß das Paket für die Auswertung dann aber erst mal den Absender (des ursprünglichen Requests) wieder erreichen).
Wenn man so einen Test wie oben also machen lassen will, dann sollte man noch Wert darauf legen, daß unmittelbar davor (und zwar zwischen den schon erwähnten 15 und 45 Sekunden) entweder KEIN anderer Traffic erzeugt wurde oder eben gerade erst einmal irgendwelchen Traffic erzeugen und dann unmittelbar das
ping anschließen - je nachdem, was man damit eigentlich feststellen und/oder beweisen will. Aber ohne die Kenntnis der "Rahmenbedingungen" (solange die FRITZ!Box auch noch DNS-Server ist, könnte es sogar fast unmöglich sein, zuvor allen Traffic zur FRITZ!Box zu vermeiden - und auch dafür wäre ja schon eine MAC-Adresse der Box erforderlich) kann man die Ergebnisse/Ausgaben der Kommandos ja noch nicht einmal richtig einordnen.
Was noch denkbar ist (und in meinen Augen auch ein valider Test), wäre die Prüfung, ob der Paketverlust für den jeweils ersten ICMP-Request auch mit der FRITZ!Box auftritt (da macht das
ping 192.168.178.1 dann Sinn) - nur warum fragt man dann den ARP-Cache ab und vor allem, warum fragt man ihn nicht auch noch zwischen den beiden
ping-Aufrufen ab, um sich zu vergewissern, welches der beiden Kommandos am Ende eine Veränderung im ARP-Cache (so es überhaupt eine gibt) bewirkt hätte. Außerdem sagt uns ein
ping-Kommando (in der bisher vorgeschlagenen Form) eben auch nicht, ob nun der Request schon sein Ziel nicht erreicht hat oder ob erst die Antwort auf dem Rückweg Probleme machte.
Aber die zweite Meldung mit demselben Modell und demselben Fehlerbild, aber einem anderen Provider, deutet ja fast schon wieder darauf hin, daß es sich vielleicht doch um einen Fehler handelt, der erst mit dem Firmware-Update eingeschleppt wurde. Das ist aber auch relativ leicht zu überprüfen - meines Wissens funktioniert auch bei der 6591 (zumindest bei passenden Bootloader-Versionen) die Umschaltung auf das alternative Partition-Set (
https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md) und da müßte sich bei beiden Boxen ja noch die vorhergehende Version befinden. Wenn diese dieselben Probleme macht, ist die Update-Theorie ebenfalls zu verwerfen - aber wenn's doch damit im Zusammenhang steht, muß man die Umschaltung ohnehin "lernen" (es sei denn, man wartet lieber auf das nächste Update), weil es ja keine andere Möglichkeit - wie ein Recovery-Programm von AVM - gäbe (oder man installiert eine ältere Version selbst über den Loader, s. Link oben).
Sollte die Box auf der Support-Seite das Deaktivieren/Aktivieren der Paketbeschleunigung anbieten und die Änderung (wenn man sie erst macht, sobald der Fehler auftritt) auch ohne Neustart möglich sein, wäre das noch ein Test, den man machen könnte (ob es auch ohne Neustart "repariert werden" kann) - die Annahme/These dabei wäre, daß AVM am PA herumgeändert hat (da gab es wohl Probleme im Upload für irgendwelche Konstellationen bei den Puma7-Modellen) und sich jetzt irgendein Fehler eingeschlichen hat, der ein Aufräumen in den Tabellen der Hardware der PPE verhindert oder irgendwann zu wenige freie Einträge vorhanden sind. Das wäre zumindest auch noch eine Erklärung, warum die Zeiträume, innerhalb derer das Problem auftritt, so variieren - wenn das "nutzungsabhängig" ist, kann es eben - je nach Auslastung in den letzten Minuten - entweder sehr lange gar nicht oder auch mal 10 Minuten nach dem letzten Neustart direkt wieder auftreten. Nur sollte sich das dann eigentlich (nach einiger Zeit der "Nichtnutzung", wenn z.B. UDP-Verbindungen wieder abgeräumt werden durch Timeout) irgendwann wieder einkriegen - was waren denn die längsten Zeiten, die hier mit Warten, ob es sich wieder von selbst behebt, verbracht wurden?
Man verliert zwar beim Deaktivieren der Beschleunigung etwas an Durchsatz, aber es wäre zumindest ein Indiz (wenn's ohne den PA besser läuft - man kann den ja auch direkt beim nächsten Neustart mal abschalten und MUSS nicht bis zum Auftreten der Probleme warten), daß die Ursache dort irgendwo zu suchen ist. Zumindest würde dazu auch noch ein Paketverlust beim ersten ICMP-Request passen, falls die Box erst mal irgendeinen Eintrag "frei machen" muß, um die neue Verbindung einzurichten - die weiteren Pakete gehen bei aktivierter Beschleunigung ja gar nicht mehr durch die CPU der Box (zumindest nicht den ATOM-Core), sondern werden direkt vom CM an den Client weitergereicht. Denkbar wäre auch (wenn tatsächlich das erste ICMP-
Reply nicht durchkommen sollte zum Client), daß zwar ein Eintrag für die Antwortpakete eingerichtet wird (in internen "Spiegeln" der Tabellen), aber irgendein Update der Hardware-Tabellen zunächst einmal nicht stattfindet und erst im zweiten Anlauf (dann für das zweite Paket, was erneut über die CPU geht - das wäre bei korrekt eingerichtetem Beschleuniger ja auch nicht der Fall) dann tatsächlich die Updates erfolgen.
Das natürlich dann alles erst im Fehlerfall (durch "pressure"), wenn es erst einmal eine ganze Weile funktioniert. Gleichzeitig paßt das aber auch dazu, daß Basisfunktionen des FRITZ!OS (wie die IP-Telefonie) weiterhin funktionieren sollen (bei der zweiten Box fehlt diese Aussage aber) - denn diese Pakete MÜSSEN ohnehin über die CPU der Box verarbeitet werden und haben mit dem Packet-Accelerator nicht wirklich etwas zu tun (außer daß Antworten zur CPU durchgelassen werden müssen, wofür üblicherweise - zumindest nach den Ausgaben der Dienstprogramme von AVM in der Support-Datei zu urteilen - auch entsprechende Einträge in den Hardware-Tabellen angelegt werden, die aber eher einen "dauerhaften" Charakter haben und nicht "on demand" erst erstellt werden, weil sie im Rahmen der erforderlichen Portfreigaben - für die internen Dienste - automatisch eingerichtet werden).
Das wären die Vorschläge, die ich hier unterbreiten kann/würde (samt Begründung) ... entweder auf die ältere Version wechseln (wobei ich beim TO nicht genau verstanden habe, ob das nun vor oder nach dem Update auftrat, beim zweiten Fall war es ja explizit nach dem Update, wenn man #34 liest) oder (wenn machbar, ich kenne die 6591-Retail-Boxen nicht selbst) die Paketbeschleunigung mal testweise deaktivieren. Man kann natürlich trotzdem die Routine-Tests im Netzwerk machen (das ist selten falsch, erst recht, wenn das Problem dennoch auftritt) - nur was man sich davon verspricht, sollte man schon deshalb auch "ansagen", damit der Testende wenigstens eine Idee davon kriegt, was er da warum machen soll und nicht nur "Ausführender" ist. Gleichzeitig kriegen dann die "Mitleser" auch eine Vorstellung davon, worauf man mit seinen Vermutungen/Bitten um weitere Tests überhaupt hinaus will - wie gesagt, ich habe auch erst mal eine Weile gegrübelt, was die vier Kommandos oben in Abhängigkeit von bestimmten Fehlern wohl als Ergebnis liefern sollten und was man damit ermitteln könnte.
