SNMP snmpwalk lefert Ergebniss, snmpget nicht

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo,


    wir haben uns eine check gebastelt, welche über perl NET-SNMP die Anzahl gedruckter Seiten vom Drcuker abfragt.
    Funktioniert soweit auch ganz gut. Jetzt steht ein HP OfficeJet 8600 an.


    Wenn über snmpwalk abgefragt wird sieht alles gut aus:
    #> snmpwalk -v1 -c public -On [IP-Adresse des Druckers]
    ...
    .1.3.6.1.2.1.43.10.2.1.4.0.1 = Counter32: 1410
    ...


    das ganze abgefragt über snmpget sieht aber nicht so gut aus:
    #> snmpget -v1 -c public [IP-Adresse des Druckers] .1.3.6.1.2.1.43.10.2.1.4.0.1
    Error in packet
    Reason: (noSuchName) There is no such variable name in this MIB.
    Failed object: SNMPv2-SMI::mib-2.43.10.2.1.4.0.1


    Entsprechende Meldung liefert auch NET-SNMP im check. So richtig auskennen mit SNMP/MIB/OID tun wir uns ehrlsich gesagt nicht.
    Muss noch was installiert werden damit snmpget funktioniert. Eine MIB haben wir bei HP leider nicht gefunden.
    Ich dachte immer wenn die OID komplett numerisch angegeben wird, sei die MIB nicht notwendig. Wahrscheinlich sehe den Wald vor lauter Bäumen nicht


    Bin um jeden Tip dankbar
    LargeAssy

  • #> snmpget -v1 -c public [IP-Adresse des Druckers] .1.3.6.1.2.1.43.10.2.1.4.0.1


    1: Kann SNMPGET den Communitystring mit dem kleinen "c" überhaupt auswerten? Ich meine, dass muss ein großes "C" sein.... Das kleine steht für critical, meine ich....

    2. Ich meine der abzufragenden OID muss ein -o oder --oid vorangestellt werden....

    3. INFO: Im Gegensatz zu snmpwalk muss man bei snmpget stets den Endknoten angeben, der die Informationen enthält. (Buch "Nagios System- und Netzwerk- Monitoring" von Wolfgang Barth...)

    Hoffe das hilft vielleicht weiter....

    Die Leute sagen immer, die Zeiten werden schlimmer!
    Die Zeiten bleiben immer, die Menschen werden schlimmer....

  • Hallo,


    danke für den Hinweis.
    Hmm, ich habe das ganz mal mit einer anderen OID durchprobiert:
    #>snmpwalk -v1 -c public -On [IP-Adresse des Druckers]
    ...
    SNMPv2-SMI::mib-2.43.11.1.1.6.0.1 = STRING: "black ink"
    ...


    und auch bei snmpget:
    #>snmpget -c public -v1 [IP-Adresse des Drcukers] .1.3.6.1.2.1.43.11.1.1.6.0.1
    SNMPv2-SMI::mib-2.43.11.1.1.6.0.1 = STRING: "black ink"


    Daher denke ich mal das die Formulierung des Befehls richtig sein sollte. Es scheint irgendwie an der OID zu liegen.
    ich habe das ganz auch mal so (ohne Punkt vor der eins) probiert:
    #>snmpget -c public -v1 [IP-Adresse des Drcukers] 1.3.6.1.2.1.43.11.1.1.6.0.1
    Macht in beiden Fällen keinen Unterschied.


    LargeAssy

  • 1: Kann SNMPGET den Communitystring mit dem kleinen "c" überhaupt auswerten? Ich meine, dass muss ein großes "C" sein.... Das kleine steht für critical, meine ich....

    snmpget ist ein Kommandozeilentool und kein Nagios-Plugin, das weiß nix von "CRITICAL" und Konsorten. (Von "-o" auch nicht.)


    Wäre nicht der erste schlecht programmierte SNMP-Support in irgendeiner Firmware, der komplette snmpwalks absolviert, aber eine gezielt abgefragte OID nicht liefern kann. Teste 'mal mit snmpwalk durch, wie weit Du ab (einschließlich!) der kompletten numerischen OID im OID Tree nach oben gehen mußt, bis die gewünschte OID wieder auftaucht. Und probier' auch 'mal -v 2c.

  • Hallo bern,


    debian lenny mit snmpget:
    Version: 5.4.1
    Web: http://www.net-snmp.org/
    Email: net-snmp-coders@lists.sourceforge.net
    Ist da was bekannt, das dieses snmpget zickt, oder kann es an der Drucker-Firmware von HP liegen?


    bei -v2c:
    #> snmpget -v2c -c public [IP-Adresse des Druckers] .1.3.6.1.2.1.43.10.2.1.4.0.1
    Timeout: No Response from [IP-Adresse des Drcukers]
    Denke das der HP OfficeJet 8600 eben nur -v 1 kann.


    Deinen Hinweis mit "gehe nach oben bis die OID wieder auftaucht" verstehe ich nicht ganz.
    snmpwalk -On liefert alle OID nur komplet numerisch.
    bei
    #> snmpwalk -c public -v1 [IP-Adresse des Druckers]
    ...
    SNMPv2-SMI::mib-2.43.10.2.1.4.0.1 = Counter32: 1418
    ...
    aber die OID taucht nur einmal auf.
    Ich habe noch ein bischen rumprobiert. Kein Ahnung warum aber es scheint an der OID 1.3.6.1.2.1.43.10.* zu liegen.
    Eine OID mit 1.3.6.1.2.1.43.11.* lässt sich mit snmpget abfragen, ebenso ein OID mit 1.3.6.1.2.1.43.9.*


    LargeAssy

  • Deinen Hinweis mit "gehe nach oben bis die OID wieder auftaucht" verstehe ich nicht ganz.

    Soll sowas heißen wie:



    und in die Ausgaben gucken, bei welchen davon Fehler, Subtree ohne die gewünschte OID oder Subtree mit herausgefallen kommen.

    Kein Ahnung warum aber es scheint an der OID 1.3.6.1.2.1.43.10.* zu liegen.
    Eine OID mit 1.3.6.1.2.1.43.11.* lässt sich mit snmpget abfragen, ebenso ein OID mit 1.3.6.1.2.1.43.9.*

    Dann würde ich 'mal vermuten, daß spätestens bei einem snmpwalk über .1.3.6.1.2.1.43 die gewünschte OID mit herausgefallen kommt.


    Prinzipiell würde SNMP IIUC erlauben, daß eine OID X erst dann "existiert", wenn man vorher eine OID Y angefaßt und dadurch eine Datenerfassung ausgelöst hat - dann gibt man check_snmp halt zwei OIDs und nur für die zweite Limits. Ohne eine passende MIB mit den ganzen Erklärungen an der Hand zu haben, dürfte es schwierig sein, das auszuschließen. Aber bei einem Druckseitenzähler glaube ich nicht so recht daran ...

  • Hallo bern,


    ich habe das mit snmpwalk mal durch gespielt. Die betreffende OID taucht immer auf.
    Durch diesen Hinweis bin ich dann auch auf den Trichter gekommen, unsere check_paper nochmals anzuschauen.
    Bisher wurde der Wert einer OID über SNMP-NET get_request abgefragt, analog zu snmpget.
    Weil aber snmpwalk funktioniert und snmpget nicht, habe ich die check_paper probeweise umgebaut auf SNMP-NET get_next_request.
    Damit lässt sich jetzt auch die omnöse OID auslesen.


    Ist zwar nicht schön, weil ich das unterschiedliche Verhalten von snmpwalk und snmpget nicht verstehe, aber zumindest funktioniert
    der check_paper


    Nochmals vielen Dank für die Hilfe.


    LargeAssy

  • Ist zwar nicht schön, weil ich das unterschiedliche Verhalten von snmpwalk und snmpget nicht verstehe

    Da gibt's nix dran zu verstehen, außer daß offenbar viele Leute, die den SNMP-Teil in irgendwelche Firmware bauen, a) die Verarbeitung von GET und GETNEXT Requests weitgehend trennen und b) beim GET-Teil dann alle möglichen OIDs schlicht vergessen. :thumbdown: Taucht zu häufig und über zu viele verschiedene Hersteller und Gerätetypen auf, als daß es eine andere Erklärung geben könnte.