Neue Mails nicht ladbar

Es gibt ein paar Auffälligkeiten im Wireshark Trace:

[tmdebutton]TCP SpuriousRetransmission[/tmdebutton]

zeigt an, dass ein Paket nochmals empfangen wurde, obwohl dessen Empfang bereits per ACK bestätigt wurde. Der Sender hatte also das ACK noch nicht bekommen.

Schlimmer ist dies:

[tmdebutton]TCP ZeroWindow[/tmdebutton]

Es besagt, das der TCP-Puffer aufgebraucht ist. Das sieht man auch sehr schön daran, dass der Wert Win von 64256 stetig abnimmt, bis eben zu Win=0.
In dieser Situation signalisiert die eine Partei der anderen, dass der Puffer aufgebraucht ist und deshalb keine weiteren Pakete mehr empfangen werden können. Folglich werden auch keine mehr gesendet, bis der Empfänger wieder bereit ist und Puffer zur Verfügung steht.

Beides deutet also auf ein in diesem Moment langsames Netzwerk hin. Es gab es eine Komponente im Netzwerk, welche die Pakete in diesem Moment nicht so schnell verarbeiten konnte, wie sie angekommen sind.
Das kann ein Fehler im Netzwerk sein oder auch ein sog. Slow Drain Device. Auch ein Virenscanner, der den Datenstrom untersucht, könnte dazu führen, dass der Puffer aufgrund der Verzögerung volläuft und er Rechner somit zum Slow Drainer wird.

-> Zeig die Logs mal dem Netzwerkadmin.

Nachtrag: 172.25.10.16 ist der Rechner, richtig? Hier ist der Puffer leer. Das spricht dafür, dass er das Bottleneck, der Slow Drainer ist.

Fangen wir mal mit dem Trace an ...

Vorab: Ich weiß, wie TCP-Verbindungen auf- und abgebait werden, aber das Lesen solcher Traces ist nicht mein täglich Brot. Außerdem ist der Trace ein wenig kurz und enthält Acknowledments zu Paketen, die der Wireshark nicht "gecaptured" hat (unseen).

Zwei Dinge fallen mir auf:

- Der Client sendet dem Server ein FIN/ACK, ohne dass vorher ein FIN vom Server zu sehen ist. Das kann normal sein, weil entweder das vorherige FIN vom Server in dem kurzen Ausschnitt nicht zu sehen ist, oder weil es in einem der Pakete enthalten war, die der Wireshark nicht gesehen hat.
(Das Beenden einer TCP-Verbindung ist nicht trivial, weil ja noch Pakete unterwegs sein können, und erfordert normalerweise ein FIN/ACK/FIN/ACK.)

- Der Client sendet dem Server einen Reset ([RST]). So ein RST wird normalerweise nur dann gesendet, wenn etwas unerwartetes passiert ist. Ich habe aber schon gelesen, dass MS-Clients so einen Reset auch dann senden, wenn sie eine SSL-Verbindung beenden wollen. Die haben wohl keine Lust, den kompletten Handshake abzuwarten. Das ist meines Wissens nicht regelkonform, aber das wäre im Falle MS nichts neues.

Das kann also ebenfalls normales MS-Verhalten sein. Wenn Du sicher gehen willst, beherzige meinen Hinweis von oben. Der Netzwerkadmin sollte diese Traces lesen können.

Zitat von Bubu_S24

Augenscheinlich klinkt sich Avira auch als LSP in die Kommunikation zwischen Client (IP: 172.20.10.16) und Server (IP: 172.25.3.230) ein.

Ja, das machen diese Produkte und erzeugen damit oft genug Probleme. Wie bereits oben erwähnt:

Zitat von SusiTux

Auch ein Virenscanner, der den Datenstrom untersucht, könnte dazu führen, dass der Puffer aufgrund der Verzögerung volläuft ...

Kommen wir zum nächsten Punkt ...

Zitat von Bubu_S24

Eine Wechselwirkung zwischen dem Online-Scan des Profilordners und dem Datenaustausch erschließt sich mir zunächst nicht.

Ein Erklärungsversuch: Wenn der AV-Scanner eine Datei untersucht, dann kann in dieser Zeit nicht in diese Datei geschrieben werden. Wenn in dieser Zeit aber weitere Pakete für diese Datei eintreffen, müssen sie irgendwo gepuffert werden. Das kann in einer temporären Datei erfolgen, im RAM oder eben im Netzwerkpuffer. Letzterer war laut den Traces oben in Deinem Fall augenscheinlich vollgelaufen.

Ein solcher Scan kann Dir u.U. auch den Profilordner gründlich zerlegen, bis hin zum Verlust der lokal gespeicherten E-Mails. Deshalb lautet der dringende Rat, den Profilordner nicht scannen zu lassen.
Schau Dich dazu am besten ein wenig im Forum um. Dort findest Du ausreichend "tragische" Beispiele.