Wie W-LAN-Signalstärke in PRTG darstellen?

[pank]

@vebis
aah, besten dank.

[stefanbunzel]

... schließe mich dieser Diskussion noch mal mit einer ergänzenden Frage an:
Weiß jemand, wo man die Sende- bzw. Empfangsrate von P2P-Strecken für die Darstellung in PRTG auslesen kann? Ich hatte den Pfad eigentlich mal gefunden, aber das waren keine zur Datenrate proportionalen Werte. Ich vermute, dass der Lancom bzw. LANmonitor diese Zahlenwerte in die entsprechende Datenrate erst umrechnet.
Hat das mal jemand für PRTG auch hinbekommen?

Stefan

[Raudi]

Wenn ich mit dem MIB Browser von iReasoning schaue dann habe ich da zwei einträge:

1.3.6.1.4.1.2356.600.3.254.1.3.36.1.1.5.1
1.3.6.1.4.1.2356.600.3.254.1.3.36.1.1.16.1

Beide haben bei mir den Wert "e48m" was mit meiner Verbindungsgeschwindigkeit von 48MBit übereinstimmen würde.

Im PRTG sieht man aber nur eine 14, bei einem Blick in die MIB wird klar, das die 14 e48m bedeutet.

Code: Alles auswählen

staWlanInterpAccTxrate OBJECT-TYPE
                       SYNTAX INTEGER{
                         unknown(0),
                         e1m(1),
                         e2m(2),
                         e5m(3),
                         e5-5m(4),
                         e8m(5),
                         e11m(6),
                         e6m(8),
                         e9m(9),
                         e12m(10),
                         e18m(11),
                         e24m(12),
                         e36m(13),
                         e48m(14),
                         e54m(15),
                         t-12m(20),
                         t-18m(21),
                         t-24m(22),
                         t-36m(23),
                         t-48m(24),
                         t-72m(25),
                         t-96m(26),
                         t-108m(27)
                       }

So ein MIB Browser ist praktisch um sich einen Überblick über die MIB und die Werte zu verschaffen.

Gruß
Stefan

[Raudi]

Ich habe auch noch einen, den Signalpegel in dB, den man im WLAN-Link-Test sieht habe ich noch nicht gefunden, oder muss der auch errechnet werden?

Gruß
Stefan

[stefanbunzel]

Hallo Raudi,

super - vielen Dank für die Datenraten-Tabelle. Genau soetwas hatte ich gesucht.
Weiß jetzt noch jemand, ob ich im PRTG so eine Tabelle einbauen kann, dass er selbst "14" in "48" umbenennt bzw. umrechnet?

Stefan

[vebis]

Ich habe auch noch einen, den Signalpegel in dB, den man im WLAN-Link-Test sieht habe ich noch nicht gefunden, oder muss der auch errechnet werden?

Gruß
Stefan

Meinst du den Signalpegel von Wlan-Clients oder von P2P-Strecken, die stehen an unterschiedlichen Stellen?

[Raudi]

Den von P2P strecken.

Gruß
Stefan

[Jirka]

Hallo,

ich möchte hier noch mal auf PRTG eingehen, obwohl das schon ganz schön off-topic ist und daher hier im LANCOM-Forum eigentlich nichts mehr zu suchen hat.

Installiert wurde PRTG Traffic Grapher V6.1.1.855 (ohne Key, d. h. es läuft als Freeware-Variante mit max. 3 Sensoren) in deutsch. Die deutsche Version gibt es noch nicht lange, dementsprechend finden sich hier und da immer wieder Stellen, wo Wörter abgeschnitten sind, weil sie von der Länge her dort so nicht hinpassen. Aus diesem Grund eignet sich von den drei zur Auswahl stehenden Webinterface-Designs auch nur eins.

Das eigentliche Problem trat bei mir bei Firmwareupdates an den LANCOMs auf, dann nämlich führte das in PRTG mitunter zu einer Anzeige von 800.000 kbit/Sekunde (in der Folge ist dann der bisherige Verlauf der Zeitreihe "gestaucht" und selbst Peaks sind nicht mehr auszumachen). Leider gibt es scheinbar keine Möglichkeit, die von PRTG ausgelesenen Werte einzusehen oder gar noch zu editieren. Um zu untersuchen, ob das ganze am LANCOM oder dem PRTG liegt, habe ich mit Wireshark/Ethereal mal mitgeschnitten und gestern passierte auch genau das beim Firmwareupdate. Da nach einem Firmware-Update der LANCOM neu bootet liefern die in meinem letzten Posting oben angegebenen Variablen sehr kleine Werte, da seit dem Bootvorgang ja bisher kaum Traffic angefallen ist. Damit PRTG jetzt nicht denkt, dass der 32-Bit-Zähler übergelaufen ist, d. h. der Wert von 4294967295 Bytes überschritten wurde und dann wieder von vorne angefangen wird zu zählen erfolgt noch eine Abfrage der Betriebszeit, in dem die Variable sysUpTime abgefragt wird. Aus der Betriebszeit lässt sich dann schließen, ob es einen Zählerüberlauf oder ein Nullsetzen der Variablen gegeben hat. Diese Abfrage der sysUpTime erfolgt vor jedem Abfragen eines Wertes, also sowohl bei ifInOctets als auch bei ifOutOctets. Nur leider scheint PRTG diese Werte nicht so auszuwerten wie es angebracht wäre ... Es war zu erkennen, dass die Abfrage nach der sysUpTime erfolgte, zu der Zeit bootete der LANCOM jedoch gerade. Von daher blieb die Antwort aus. Danach (5 Sek. später, Betriebszeit LANCOM 3,8 Sekunden) erfolgte die Abfrage nach ifInOctets, die mit dem Wert 40 beantwortet wurde. Da dem PRTG nun die Antwort auf sysUpTime fehlte geht er fälschlicherweise davon aus, dass kein Bootvorgang stattfand und folglich ein Zählerüberlauf angenommen wird, so dass sich der verbrauchte Traffic zu 4294967295 - letzte Abfrage + aktuelle Abfrage ergibt. Das kann natürlich utopische Werte ergeben. Meiner Ansicht nach liegt hier ein klarer Fehler in PRTG vor. Nun gibt es die Möglichkeit bei den Eigenschaften des Sensors übergroße Werte von der Auswertung auszuschließen. Aber erstens beseitigt man dadurch nicht die Ursache sondern die Symtome und zweitens weiß man so recht gar nicht, in welcher Einheit man das in dem Feld eingeben soll. Dann habe ich durch ausprobieren einen Wert rausgefunden, bei dem im Normalfall nichts mehr abgeschnitten wird, aber dieser Wert hatte nicht viel mit dem theoretischen Maximalwert der Übertragungsrate der Leitung zu tun - eigenartig.

Ein paar andere Fehler sind mir auch noch aufgefallen, also so recht begeistert bin ich nicht ...

Viele Grüße,
Jirka

EDIT: Also bzgl. der Möglichkeit bei den Eigenschaften des Sensors übergroße Werte von der Auswertung auszuschließen noch mal ein paar Anmerkungen. Das funktioniert nicht wirklich. Bearbeitet man einen Sensor findet sich unter Sensoreinstellungen -> Erweitert -> Werte das Feld "Höchstwerte filtern". Problem Nummer 1, man müßte hier für eingehend und ausgehend unterschiedliche Werte angeben können. Problem Nummer 2, gebe ich hier bei einem DSL-3000-Anschluss mit einer Downloadrate von max. 3072 kbit/s den Wert 3100 ein, so werden Werte um die 60 kbit/s im Live-Graph bereits beschnitten, aber im Diagramm der Stundenmittelwerte bleibt nach wie vor ein Peak von 7500 kbit/s stehen, den es da so nie gegeben hat (da war Bootvorgang aufgrund von Firmwareupdate). Das haut also alles nicht so hin.

[stefanbunzel]

Hallo Jirka,

ich habe deine beschriebenen Probleme beim PRTG auch schon beobachtet - aber natürlich bin ich da nicht so ins Detail vorgedrungen.

Meine persönliche Meinung: Haben wir Alternativen? Ist es ein Lancom-Problem? (So viel zu der Frage, ob deine Beobachtung nicht lieber gleich an Paessler mitgeteilt werden sollte.)

Ich kann mit den "Ausreißern" leben, da sie zum Glück selten auftreten und ich sie als "Macke" von PRTG einstufen kann. Ansonsten dient mir PRTG zur allgemeinen Überwachung des Netzes - und das geht auch mit diesen Problemchen.

Ach ja: Ich habe regelmäßig "Fehlzeiten" in der PRTG-Dokumentation, da mein Windows 2000 sich mal wieder aufgehangen hat...

Empfehlung an Lancom: Liefert ihr uns ein solches schönes Tool zur graphischen Analyse der Geräte - bis dahin werden wir uns wohl mit den Macken anderer Programme rumschlagen müssen.

Stefan

[alf29]

Moin,

Empfehlung an Lancom: Liefert ihr uns ein solches schönes Tool zur graphischen Analyse der Geräte Wink - bis dahin werden wir uns wohl mit den Macken anderer Programme rumschlagen müssen.

Dazu fühle ich mich als Firmware-Entwickler nicht direkt berufen, und die
Truppe, die die LANtools macht, ist auch schon ziemlich 'dicht' - damit würde
ich nicht in absehbarer Zeit rechnen.

Außerdem, mal so herum gefragt: Was soll denn alles angezeigt/geloggt
werden?

Gruß Alfred

[Raudi]

Hallo Alfred,

die Qualitätswerte einer Verbindung sind eigentlich immer recht interessant. Also Signalstärke, Rauschpegel und evtl. die Datenrten.

Z.B. habe ich mal die 100 Euro die T-Com für einen Vor-Ort Einsatz verlangt hat wieder gutgeschrieben bekommen, da ich zufällig noch alte Werte meiner DSL Leitung hatte und damit zeigen konnte, das die Werte sich derart verschlechtert hatten, das zwar das Teledat des T-Com Technikers auf anhieb funktionierte aber das interne Modem des LANCOM's keinen Link bekommen hat.

Gruß
Stefan

[vebis]

Was mir aufgefallen ist und ich als störend empfinde im großen Mischbetrieb verschiedener Lancoms mit unterschiedlichen Firmware-Version von 5.x bis 7.x ist, dass ab Version 7.x die Interfaces aus irgendeinem Grund durchgewürfelt wurden und somit die oids, die bei 5.x und 6.x noch auf das 2. Wlan Interface gezeigt haben nun nicht mehr Ziel führen. Diese Inkonsistenz find ich persönlich mist, und bereitet einen nur ein haufen Arbeit, da wieder Firmwareabfragen in die Scripte reinmüssen, damit dieses Verhalten ausgeglichen wird. Das Lancom sich sowas leistet ist komisch, aber scheinbar gibt es kaum Leute die ihre Lancom richtig monitoren oder es wie bei cacti für jeden einzelnen selber zusammenklicken.

[Jirka]

Hallo vebis,

Was ... ich als störend empfinde ... ist, dass ab Version 7.x die Interfaces aus irgendeinem Grund durchgewürfelt wurden und somit die oids, die bei 5.x und 6.x noch auf das 2. Wlan Interface gezeigt haben nun nicht mehr Ziel führen

Das ist halt die Folge der Implementation von ARF und den dafür erforderlichen Änderungen. Das muss man wohl in dem Zusammenhang in Kauf nehmen.

aber scheinbar gibt es kaum Leute die ihre Lancom richtig monitoren

Glaub mal nicht, dass Du der Einzige bist, dem das aufgefallen ist, andere haben das auch schon bemerkt gehabt.


Hallo an alle,

Also bzgl. der Möglichkeit bei den Eigenschaften des Sensors übergroße Werte von der Auswertung auszuschließen noch mal ein paar Anmerkungen. Das funktioniert nicht wirklich. Bearbeitet man einen Sensor findet sich unter Sensoreinstellungen -> Erweitert -> Werte das Feld "Höchstwerte filtern". Problem Nummer 1, man müßte hier für eingehend und ausgehend unterschiedliche Werte angeben können. Problem Nummer 2, gebe ich hier bei einem DSL-3000-Anschluss mit einer Downloadrate von max. 3072 kbit/s den Wert 3100 ein, so werden Werte um die 60 kbit/s im Live-Graph bereits beschnitten, aber im Diagramm der Stundenmittelwerte bleibt nach wie vor ein Peak von 7500 kbit/s stehen, den es da so nie gegeben hat (da war Bootvorgang aufgrund von Firmwareupdate). Das haut also alles nicht so hin.

Ich habe inzwischen rausgefunden, dass man in diesem Feld bei Traffic-Sensoren den Wert in Bytes (je Sekunde) angeben soll. Weiterhin habe ich rausgefunden, dass die Implementation dieser Funktion fehlerhaft ist, sie funktioniert immer nur für die letzten 24 bis 48 Stunden (weiß nicht genau). Beispiel: Ich hatte einen herausragenden Peak in meiner Monatskurve. Dann klickte ich die Wertefilterung ab, dann waren drei (unnormale) Peaks zu sehen. Daraufhin Wertefilterung wieder angehakt und von den drei Peaks verschwand leider keiner mehr ... sieht echt beknackt aus jetzt! Ich werde versuchen, den obigen Fehler bei Paessler zu melden, soweit dies als noch nicht zahlender Kunde möglich ist (wenn man denn zahlt, bekommt man leider standardmäßig nur für 12 Monate Updates, das hält mich persönlich eher vom Kauf ab).

Viele Grüße,
Jirka

[alf29]

Moin,

nd somit die oids, die bei 5.x und 6.x noch auf das 2. Wlan Interface gezeigt haben nun nicht mehr Ziel führen.

ARF hat eigentlich bei den WLANs nichts geändert - könntest Du bitte mal
genauer sagen, welche OIDs bei der 7.x nicht mehr funktionieren?

Gruß Alfred

[vebis]

Hallo Alf,

ich hab dir per PN ausführlicher geantwortet.

Hier nochmal in Kürze...

Zum einem geht es um die Indizes in der ifTable, dort war es bisher üblich zuerst die Ethernetinterfaces aufzuführen gefolgt von den Wlaninterfaces, dass hat sich in FW 7.x geändert. Da werden zuerst die Wlaninterfaces aufgeführt und danach die Ethernetinterfaces und die ganzen logischen Schnittstellen.

Zum anderem geht es um die Anordnung der Wlan-Netze, in der FW 7.x ist das WLAN-2 hinter WLAN-1 gerückt, das wird auch sicher jeder in der Webconfig gemerkt haben. Die Oids sind die selben geblieben, nur hat sich da beim Walken etwas geändert. "Früher" wurde zuerst die SSID von WLAN-1 ausgegeben und danach alle logischen SSIDs von WLAN-1 gefolgt von der SSID WLAN-2 und derer logischen Schnittstellen, also die Zweige hierarchisch abgeklappert. Mit der 7.x hat sich das auch geändert, da wird erst SSID von WLAN-1 und WLAN-2 ausgeben und danach die SSIDs der logischen Schnittstellen. (in staWlanNetworkNet findet das statt)