Verfasst am: 11.01.2006 13:49 Titel: DLink 707p zeigt bei SMNP-Abfrage doppeltes Download an
Betreffende D-Link Geräte: DI 707p C1 FW 3.13b07
Betreffender WLAN-Client Adapter: kein
Welche WLAN-Verschlüsselung ist aktiviert?: Keine
--------------------------------------------------------------------------------------------------------------------
Betriebssystem & ServicePack: Win XP home SP2
I-Net Browser: MS IE 6.0.29, Firefox 1.5
--------------------------------------------------------------------------------------------------------------------
Provider & Zugangsart: Strato DSL
MTU-Wert im Router: 1454
MRU-Wert im Modem/Modem-Router: ?
VPI-Wert im Modem/Modem-Router: ?
VCI-Wert im Modem/Modem-Router: ?
--------------------------------------------------------------------------------------------------------------------
Ist eine Software-Firewall vorhanden (auch wenn deaktiviert)?: Ja, wie unterstehend angegeben:
Software-Firewall: ZoneAlarm 4.5 aktiv, XP SP2 deaktiv
--------------------------------------------------------------------------------------------------------------------
Ist Filesharing im Einsatz?: Nein
Filesharing-Programm u. Vers.:
--------------------------------------------------------------------------------------------------------------------
Wie bezeichnest Du Deinen LAN/WLAN Wissensstand?: Grundwissen (= ich habe schon mal ein Netzwerk < 5 PCs konfiguriert, das hinterher auch lief)
--------------------------------------------------------------------------------------------------------------------
Was hast Du gemacht und/oder installiert, bevor das Problem aufgetreten ist?:
s.u.
Was hast Du bereits versucht, um das Problem zu lösen?:
s.u.
--------------------------------------------------------------------------------------------------------------------
Und hier nun meine detailierte Fehlerbeschreibung und Nachricht:
Hallo zusammen,
erstmal wünsche ich allen für das Jahr 2006 alles Gute, viel Erfolg und vor allem Gesundheit.
Nun zur Sache:
Ich betreibe zur Steuerung des Routers das Programm "RouterControl V.1.60" und zur Erfassung des Datentransfers "TrafficMonitor V.4.50".
TrafficMonitor hat die Möglichkeit, den Datenverkehr mittel SNMP aus dem Router zu lesen. Leider kommt es dabei trotz neuester Versionen von Soft- und Firmware zu falschen Anzeigen.
Bei der Abfrage über SMNP wird vom TrafficMonitor die doppelter Downloadmenge angezeigt. Der Programmentwickler Mirco ist der Meinung, dass das am Router bzw. dessen FW liegen müsste.
Bei meinen Tests bin ich folgendermaßen vorgegangen:
Rechner neu gestartet, RouterControl, TraficMonitor als Dienst und als Programm gestartet, im Router alle Zähler auf Null gesetzt, Verbindung über RouterControl zum Internet hergestellt, FireFox gestartet, Seite des E-Mail-Providers aufgerufen, eingeloggt, ausgeloggt, FireFox beendet, Verbindung zum Inernet über RouterControl beendet.
Das hat zu folgenden Ergebnissen geführt:
1. TrafficMonitor fragt über Packettreiber ab, folgende Werte ergaben sich:
was mich an der Sache wundert, dass die Anzahl der In/Out-Pakete richtig angezeigt wird. Normalerweise wird die übertragene Datenmenge daraus berechnet - der Router macht diese Berechnung nicht! Nachprüfen kannst Du das mit einem 'MIB Browser' (google mal wieder :sunglass: ) beispielsweise von 'iReasoning' (Vorsicht: nur was für Leute, die schon ein wenig über SNMP wissen, ansonsten sieht man da nur Kauderwelsch 8-{ )...
Deswegen denke ich, dass der Fehler doch im Programm und nicht im Router steckt...
ich habe den MIB Browser von 'iReasoning' als SNMP-Client benutzt. Die gleichen Ergebnisse habe ich aber auch mit Smilie, SmnpMgmt sowie SNMP_Manager erhalten.
Mirco sagt, dass die InOktets zu hoch (also verdoppelt) angezeigt würden. Die OutOktets seien OK.
Ich werde Mirco nochmal fragen, welche Werte er genau über SNMP abfragt und wie er die Datenmenge berechnet.
Mirco schreibt, dass er bei SNMP-Abfrage die Oktets ausliest, da die Pakete immer unterschiedlich groß seinen.
Man sieht ja auch an den Werten des Providers, dass an den InOktets etwas nicht stimmen kann (die OutOktests passen zu den Daten des Providers), oder liege ich da falsch?
die Sache mit der variablen Paketgröße mag ja richtig sein, und dass deswegen das Auslesen der Oktetts zuverlässiger ist auch. Doch es heisst nicht umsonst 'Oktett' - und warum ergibt sich dadurch doch ein unterschiedlicher Transferwert?? Ich habe gerade mal überschlagen: Einfach per Dreisatz :doof: die Zahl der eingegangenen Bytes aus den ausgegangenen bestimmt - und was kommt dabei heraus? TrafficMonitor zeigt einen falschen Wert an - nämlich nur die Hälfte. Damit scheint der Fehler dort zu liegen... Jedenfalls nicht am Router, denn laut RFC kann/soll der nur die Oktetts liefern - und das funktioniert ja mit beiden Programmen korrekt!
A) Mir ist kein Traffic-Mess-Programm bekannt, welches abslolut korrekt den in- und ausgehenden WAN-Traffic in z.b. KB/MB misst und protokolliert.
B) Kenne ich pers. div. Fälle, wo sich Personen auf solche Tools verlassen haben und dann die böse Überaschung kam, wenn sie ISP-Volumen-Tarife hatten.
C) Wer unbedingt Wert auf genauen WAN In- und Outgoing Traffic haben will, der sollte/müsste zwischen Router-LAN Port und einem Switch für die Clients einen PC mit zwei NIC´s einbauen, auf welchem ein entsprechendes Netzwerktool läuft.
:oo: da hab ich wohl was überlesen :deal: ... sorry!
Da ich mal davon ausgehe, dass der ISP die Datenmenge korrekt wiedergibt, scheint da wirklich ein Problem vorzuliegen.
BTW: Was sagt eigentlich der MIB Browser über die Zahl der übertragenen Pakete (es gibt ja unterschiedliche Schnittstellen)? Gibt es da Inkonsistenzen?
Wenn ich im MIB Browser den Router mittels "Walk" auslese, bekomme ich nur Werte aus den Bereichen "system" und "interface" angezeigt (30 Zeilen).
Wenn ich explizid andere Bereiche anwähle, bekomme ich die Meldung, dass keine Daten vorhanden seien. Liegt das evtl. an der FreeWare des Browsers, dass nicht mehr angezeigt wird? Kann eigentlich auch nicht sein, da ich auch mit den anderen SNMP-Client nicht mehr Daten auslesen kann, oder?
Die In- und OutOktets erscheinen nur im Bereich "interface" wie beschrieben.