Wireshark Analyse
Hallo zusammen!
Ich brauche eine Erklärung zu Wireshark V1.4.4. Ich arbeite mich grad darin ein...
Ich habe mein Netzwerktraffic aufgezeichnet, da es Probleme mit meiner Internetleitung gibt. Vernünftiges Onlinegaming ist nicht möglich und der Webseitenaufbau ist schleppend.
Hierzu mal der IO Graph.
Wie man sieht habe ich einige Filter benutzt. Jetzt meine Fragen...
Filterauswahl passend?
Kann man sagen, dass ich echte Probleme habe oder sind die eher zu vernachlässigen?
Setze ich den fünften Graph (RST-Flag) ein, verläuft dieser nahezu identisch des schwarzen Graphen.
In anderen Aufzeichnungen ist dem nicht so....
Hinzu kommt, dass JEDES Paket von mir abgehend die IP Checksum nicht korrekt ist. Liegt dies am NAT vom Router?
Vielen Dank!
easyfisi
Ich brauche eine Erklärung zu Wireshark V1.4.4. Ich arbeite mich grad darin ein...
Ich habe mein Netzwerktraffic aufgezeichnet, da es Probleme mit meiner Internetleitung gibt. Vernünftiges Onlinegaming ist nicht möglich und der Webseitenaufbau ist schleppend.
Hierzu mal der IO Graph.
Wie man sieht habe ich einige Filter benutzt. Jetzt meine Fragen...
Filterauswahl passend?
Kann man sagen, dass ich echte Probleme habe oder sind die eher zu vernachlässigen?
Setze ich den fünften Graph (RST-Flag) ein, verläuft dieser nahezu identisch des schwarzen Graphen.
In anderen Aufzeichnungen ist dem nicht so....
Hinzu kommt, dass JEDES Paket von mir abgehend die IP Checksum nicht korrekt ist. Liegt dies am NAT vom Router?
Vielen Dank!
easyfisi
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 163972
Url: https://administrator.de/contentid/163972
Ausgedruckt am: 26.11.2024 um 07:11 Uhr
8 Kommentare
Neuester Kommentar
Ohne das man deinen Messaufbau genau kennt ist eine Benatwortung dieser Frage unmöglich um nicht im freien Fall raten zu müssen. Wenn dir das reicht..OK ?!
Wichtig ist die Klärung folgender Punkte:
Allerdings sind eine derart hohe Rate an Duplicate ACKs und Retransmission schon ziemlich bedenklich. Irgendwas ist also definitv faul bei dir. Ob das ggf an L2 oder sogar L1 Fehlern liegt kann man anhand der o.a. oberflächlichen Messadten unmöglich sagen.
Man muss nun anhand der Mac Adressen oder der IPs herausbekommen WER denn diese ACKs und Retrans. verursacht.
Da musst du den Hai nun mal aufs Eingemachte ansetzen....
Wichtig ist die Klärung folgender Punkte:
- WO misst du ? Mirror Port an einem Switch? (Was mirrorst du) , Bridge Probe ?
- WAS genau willst du messen bzw. herausfinden ?
- Die o.a. Filter zeigen dir allein TCP Fehler auf in dem Segment, Port oder wo auch immer du misst. L2 Fehler sind ausgeklammert bzw. nicht sichtbar.
Allerdings sind eine derart hohe Rate an Duplicate ACKs und Retransmission schon ziemlich bedenklich. Irgendwas ist also definitv faul bei dir. Ob das ggf an L2 oder sogar L1 Fehlern liegt kann man anhand der o.a. oberflächlichen Messadten unmöglich sagen.
Man muss nun anhand der Mac Adressen oder der IPs herausbekommen WER denn diese ACKs und Retrans. verursacht.
Da musst du den Hai nun mal aufs Eingemachte ansetzen....
Deine Messung ist auch unsinnig sofern du den gesamten Traffic via Router erfassen willst, denn du kannst lediglich einzig und allein deinen eigenen Traffic messen der vom PC kommt der auch den Wireshark installiert hat.
Der restliche Traffic bleibt dem Sniffer verborgen weil der interne Switch der FB diesen nicht auf diesen Port leitet. Wenn das aber OK so ist dann kann man das natürlich so machen
Die FB kann auch keinen Mirror Port mit dem man sowas machen könnte.
Bedenke das also immer bei deiner Messung !
Das Vorgehen zum korrekten Messen ist hier für Anfänger in dem Metier erklärt:
http://www.heise.de/netze/artikel/Fehler-erschnueffeln-221587.html
http://www.heise.de/netze/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22 ...
Ob deine Telekom Leitung OK ist kann man aus einem Forum nicht beurteilen, denn diese Leitung misst du mit dem Wireshark ja gar nicht, sondern lediglich dein lokales LAN ! Also NICHT die WAN/DSL Seite.
Der Router terminiert aber pro Interface ja den IP Traffic und schleift nix durch (dafür ist er ja ein Router !) Folglich bist du auf dem WAN Interface blind mit deiner Messung.
Ebenso teilst du uns nicht mit ob du über ISDN mit der FB telefonierst oder ob du einen Vollanschluss hast mit VoIP also Telefonie übers Internet mit der FB. Deshalb ist eine hilfreiche Aussage dazu nicht möglich.
Natürlich ist es möglich das das Problem an deiner Heimverkabelung liegt. Die zahllosen Retransmissions, TCP Segment Losses und ACK Wiederholungen lassen so einen Schluss zu. Aber dafür müsste man eben wieder Details wissen die du nicht lieferst. Bleibt also nur wieder raten was dir nicht wirklich hilft.
Normal ist das nicht. In einen simplen und popeligen hausnetz mit um die 10-20 Komponenten sollte es bei einer sauberen Verkabelung und funktionstüchtigen Komponenten keinerlei dieser Fehler im Netz geben...nicht mal die erlaugten 1% da die Last einfach viel zu gering ist.
Irgendwas ist also erheblich faul in deinem Netzwerk !
Interessant wäre mal zu wissen ob diese Fehler auch bei lokalen Verbindungen nur innerhalb des lokalen LANs auftreten.
Wenn nicht, dann kann schon vermuten das es nur die ISP Verbindung ist.
Der Sniffer Trace oben zeigt diese heftigen Fehler ja nur für externe IP Verbindungen...
Weiter wichtig wäre mal zu sehen ob diese Fehler auch auftreten wenn du mit einem anderen Gerät Laptop, Smartphone usw. mit externen IPs kommunizierst.
Wenn dem so wäre würde das den Schluss einer gestörten ISP Leitung erhöhen. Dazu müsstest du aber mal mit einem Hub oder Mirror Port Sniffern. Hilfreich wär solche Messung aber um den Fehler einzugrenzen.
Der restliche Traffic bleibt dem Sniffer verborgen weil der interne Switch der FB diesen nicht auf diesen Port leitet. Wenn das aber OK so ist dann kann man das natürlich so machen
Die FB kann auch keinen Mirror Port mit dem man sowas machen könnte.
Bedenke das also immer bei deiner Messung !
Das Vorgehen zum korrekten Messen ist hier für Anfänger in dem Metier erklärt:
http://www.heise.de/netze/artikel/Fehler-erschnueffeln-221587.html
http://www.heise.de/netze/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22 ...
Ob deine Telekom Leitung OK ist kann man aus einem Forum nicht beurteilen, denn diese Leitung misst du mit dem Wireshark ja gar nicht, sondern lediglich dein lokales LAN ! Also NICHT die WAN/DSL Seite.
Der Router terminiert aber pro Interface ja den IP Traffic und schleift nix durch (dafür ist er ja ein Router !) Folglich bist du auf dem WAN Interface blind mit deiner Messung.
Ebenso teilst du uns nicht mit ob du über ISDN mit der FB telefonierst oder ob du einen Vollanschluss hast mit VoIP also Telefonie übers Internet mit der FB. Deshalb ist eine hilfreiche Aussage dazu nicht möglich.
Natürlich ist es möglich das das Problem an deiner Heimverkabelung liegt. Die zahllosen Retransmissions, TCP Segment Losses und ACK Wiederholungen lassen so einen Schluss zu. Aber dafür müsste man eben wieder Details wissen die du nicht lieferst. Bleibt also nur wieder raten was dir nicht wirklich hilft.
Normal ist das nicht. In einen simplen und popeligen hausnetz mit um die 10-20 Komponenten sollte es bei einer sauberen Verkabelung und funktionstüchtigen Komponenten keinerlei dieser Fehler im Netz geben...nicht mal die erlaugten 1% da die Last einfach viel zu gering ist.
Irgendwas ist also erheblich faul in deinem Netzwerk !
Interessant wäre mal zu wissen ob diese Fehler auch bei lokalen Verbindungen nur innerhalb des lokalen LANs auftreten.
Wenn nicht, dann kann schon vermuten das es nur die ISP Verbindung ist.
Der Sniffer Trace oben zeigt diese heftigen Fehler ja nur für externe IP Verbindungen...
Weiter wichtig wäre mal zu sehen ob diese Fehler auch auftreten wenn du mit einem anderen Gerät Laptop, Smartphone usw. mit externen IPs kommunizierst.
Wenn dem so wäre würde das den Schluss einer gestörten ISP Leitung erhöhen. Dazu müsstest du aber mal mit einem Hub oder Mirror Port Sniffern. Hilfreich wär solche Messung aber um den Fehler einzugrenzen.
Was meinst du mit analoger Telefonie. Anaolg via Splitter über den Amtsanschluss oder analog am Router und dann via VoIP übers Internet ?
Wenn du de facto eine Relation zw. Regen buw. Feuchtigkeit und Fehlerhäufigkeit herstellen kannst ist das Ergebnis dann wirklich eindeutig auf der ISP Seite.
Du solltest aber sicher messen im lokalen Netz, das du die Fehler de facto auf externen IP Sessions klar eingrenzen kannst. Nicht das diese Fehler auch lokal im LAN auftreten.
Du solltest dann besser mit Fakten gewappnet sein wenn du dem ISP gegenübertrittst !!
Wenn du de facto eine Relation zw. Regen buw. Feuchtigkeit und Fehlerhäufigkeit herstellen kannst ist das Ergebnis dann wirklich eindeutig auf der ISP Seite.
Du solltest aber sicher messen im lokalen Netz, das du die Fehler de facto auf externen IP Sessions klar eingrenzen kannst. Nicht das diese Fehler auch lokal im LAN auftreten.
Du solltest dann besser mit Fakten gewappnet sein wenn du dem ISP gegenübertrittst !!