PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
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).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:
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.
Zuletzt bearbeitet:
