[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Also hier mal eine Anleitung zum Nachvollziehen des "Ping-Bug" und die benötigten Tools (für Windows):
Erstmal benötigt man einen Ping-Befehl, bei welchem man die Pause zwischen den gesendeten Echo-Requests einstellen kann. Der Standard Windows Ping-Befehl kann das leider nicht, zudem ist der noch sehr ungenau. Deshalb habe ich mir mal eigene Tools gebastelt, PINGPRO und TRACEPRO. Die habe ich hier mal zum Download bereitgestellt:
http://user.cs.tu-berlin.de/~normanb/PINGPRO_TRACEPRO.ZIP
Zum Nachvollziehen des Bugs muss man erst einmal den ersten Gateway hinter dem BRAS ermitteln. Das kann man mit tracert oder auch gleich mit TRACEPRO machen:
C:\>tracepro -v
www.t-online.de
Tracing route to
www.t-online.de [217.6.164.162]
over a maximum of 16 hops:
1 0.712 ms 0.364 ms 0.343 ms fritz.box [192.168.178.1]
2 18.443 ms 18.576 ms 18.527 ms 217.0.119.1
3 19.063 ms 19.023 ms 18.767 ms 87.190.165.174
4 28.193 ms 28.515 ms 28.057 ms 194.25.10.73
5 28.647 ms 28.274 ms 29.215 ms 217.89.74.2
6 62.709 ms 63.780 ms 30.112 ms 172.29.2.194
7 29.160 ms 28.434 ms 28.667 ms
www.t-online.de [217.6.164.162]
Trace complete.
Der erste Hop auf Telekom-Seite (hier 217.0.119.1) antwortet nicht auf Pings, also muss man den zweiten nehmen, in meinem Fall also die 87.190.165.174. Die pingt man dann fleissig an:
C:\>pingpro -i 0 -n 1000 87.190.165.174
...
0 bytes from 87.190.165.174: icmp_seq=997 ttl=62 time=18.780 ms
0 bytes from 87.190.165.174: icmp_seq=998 ttl=62 time=18.579 ms
Request timed out.
--- Ping statistics for 87.190.165.174 ---
Packets: Sent = 1000, Received = 980, Lost = 20 (2% loss)
RTT: Minimum = 18.316 ms, Maximum = 79.405 ms, Average = 19.979 ms
Man merkt beim Durchlaufen schon, dass es immer wieder "hakt". Um jetzt herauszufinden, wo die Pakete verlorengehen, verwendet man den Paketmitschnitt der Fritz!Box:
http://fritz.box/html/capture.html
Erstmal macht man einen "Paketmitschnitt auf DSL-Ebene" (ganz oben auf der Seite). Den starten, dann obigen Pingtest durchführen und sich dabei eine oder mehrere icmp_seq merken, die nicht beantwortet wurden. dann auf "Stop" klicken und den gespeicherten Capture mit Wireshark anschauen und nach den fehlenden icmp_seq schauen. Da wird man dann feststellen, dass da nicht nur die Echo_Reply fehlt, sondern der Echo_Request ebenso - die Fritz!Box hat den Ping also gar nicht weitergeschickt.
Dann kann man noch einen Paketmitschnitt auf dem Interface "lan" (ganz unten auf der Seite) machen. Wieder den Pingtest und wieder nach den fehlenden icmp_seq schauen. Diesmal wird man feststellen, dass die fehlenden Requests durchaus in der Fritz!Box angekommen sind...
Wenn man übrigens mal seine LAN-Verkabelung, oder auch sein WLAN testen möchte:
pingpro -t -i 5 fritz.box
Das dann ein paar Minuten/Stunden/Tage laufen lassen und dann mit Strg+C abbrechen. Bei einer LAN-Verkabelung sollte da schon Lost=0 stehen, maximal Lost=1 wenn man gerade Strg+C gedrückt hat, als ein Request gerade unterwegs war. Wenn da grössere Verluste auftreten, ist da möglicherweise etwas defekt...
[Beitrag 2:]
[Edit frank_m24: Sinnfreies Vollzitat vom Beitrag direkt darüber gelöscht, siehe Forumregeln.]
Probier's wenn möglich doch mal bitte mit meinem PINGPRO und "-i 0", denn das schickt die Pings schnellstmöglich los. Erst bei diesem "Lasttest" wird das Problem sichtbar. Mit dem herkömmlichen Windows-Ping, der 1 Sekunde Pause zwischen den Pings macht, kann ich den Fehler auch nicht nachvollziehen. Da ist ja auch die Last viel geringer.
