Adapter SNMP V2.x.x Support Thread
-
Ich eröffnen hier mal einen Support Thread für den SNMP Adapter.
Aktuelle Test Version 2.1.10 (Stable) 2.1.10 (Latest) / 2.1.10 (Github) Veröffentlichungsdatum 7.10.2022 13.9.2022 Github Link https://github.com/iobroker-community-adapters/ioBroker.snmp README.md https://github.com/iobroker-community-adapters/ioBroker.snmp#readme Hier die Links zu versionsspezifischen Supportbeiträgen:
Der SNMP Adapter ermöglicht das Auslesen von Daten via SNMP Protokoll.
Die aktuelleste Dokumentation findet sich im Github README.md (https://github.com/iobroker-community-adapters/ioBroker.snmp#readme).
Falls Fragen auftauchen, bitte einfach hier mals stellen. Für Fehler bitte ein Issue in Github (https://github.com/iobroker-community-adapters/ioBroker.snmp/issues) anlegen. Dort finden sich auch die noch offenen Feature Requests (Upvoten von Request bzw. Kommentare dazu sind erlaubt dmit ich weiß was mehr od. weniger wichtig ist).
-
SNMP V2.1.7 im stable
snmp V2.1.7 wurde released.
Wichtiger Hinweis!
Die Konfigurationsdaten wurden für Version 2.0.0 (und neuer) geändert. Die Installation wird versuchen, die Daten zu migrieren, aber es gibt eine Chance, dass dies versagt. Bitte stellen Sie sicher, dass Sie ein Backup und eine externe Dokumentation Ihrer Konfiguration vor dem Upgrade auf Version 2.0.0 oder neuer haben.
Was wurde geändert / gefixed:
2.1.8
Der Parameter Community wurde im Zuge der Migration nicht migriert.2.1.7
Die Dokumentation in README.md wurde aktualisiert. (KEINE Codeänderungen enthalten.)2.1.6
Einige Probleme, die von Sentry gemeldet wurden, wurden behoben (#151, #152)2.1.5
Die Funktionalität der Option optional wurde wiederhergestellt. (#147)2.1.4
Crash bei SNMP v1 und anderen Fehlern als Timeout behoben2.1.3
Um TOOBIG Fehler zu vermeiden, wurde eine neue Option zur Steuerung der Anzahl der OIDs innerhalb einer einzigen Anfrage hinzugefügt (#72)2.1.2
Die Umwandlung von floatingpoint-werten wurde korrigiert (#16)2.2.1
update externer Pakete (dependa-bot PRs)2.1.0
• net-snmp wurde auf version 3.8.2 aktualisiert
• Unterstützung für SNMP v2c wurde hinzugefügt (#116)
• Der Qualitätsmarker von Stateobjects wird bei Fehler oder Timeout verwendet
• Der OID-Marker Optional wurde implementiert. Dieser Marker unterdrückt Fehler für OIDs, die nicht immer verfügbar sind. (#116)
• Unterstützung für Counter64 OIDs wurde hinzugefügt. (#57)
• Die von der SNMP-Kommunikation zurückgegebenen Daten werden jetzt mit weiteren Details protokolliert.
• Der kompakte Modus wurde aktiviert. (#20)
• Bekannte Einschränkung: Derzeit werden nur SNMP V1 und SNMP V2c unterstützt.
• Bekannte Einschränkung: OID-Attribut Schreibbar ist noch nicht implementiert.2.0.1 (2022-07-22)
• Fehlerhafte Behandlung des Kompatibilitätsmodus-Flags wurde korrigiert (#135)
• Protokollierung von Fehlern bei ungültigen OIDs korrigiert (#134)2.0.0 (2022-07-21)
• Viele Teile des Codes wurden neu geschrieben
• Der Adapter verwendet jetzt die admin5-Schnittstelle
• Timerwerte können jetzt pro Gerät unterschiedlich eingestellt werden (#105)
• Das Ändern der Reihenfolge der Konfigurationseinträge zerstört keine Daten mehr (#15)
• Zustandsobjekte für Geräte können jetzt benannt werden. Das alte Verhalten ist optional verfügbar.
• Bekannte Einschränkung: derzeit wird nur SNMP V1 unterstützt.
• Bekannte Einschränkung: OID-Attribute optional und beschreibbar sind noch nicht implementiert. -
SNMP V2.x.x FAQ
Hier werde ich öfter auftretende Fragen / Unklarheiten zusammenfassen bzw. verlinken.
- Adapter beendet sich kurz nach dem Start selbst
Im Log steht folgende Fehlermeldung:
error: snmp.0 (1798235) device 127_0_0_1 (127.0.0.1) references unknown or completly inactive oid group set-1. Please correct configuration.Hintergrund:
Das (wahrscheinlich) migrierte Device 127.0.0.1 referenziert eine OID Gruppe (set-1) in der keine aktive OID existiert.Abhilfe:
Device 127.0.0.1 disablen oder löschenSiehe auch https://forum.iobroker.net/topic/57579/adapter-snmp-v2-x-x-support-thread/4
- Adapter unterstützt DNS Abfragen nicht mehr
In Version V2.x.x. verlangt der Adapter die Eingab einer IP (IPv4) Adresse. Die Eingabe eines Hostnamens ist nicht mehr möglich. Diese Feature ist im Zuge der Vorarbeiten für IPv6 Support verloren gegangen. Eine Korrektur ist für die nächste Version geplant.
https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/165
- Die Verbindung zum Zielgerät kann nicht aufgebaut werden - es wird ein TIMEOUT Fehler gelogged
Bei der Migration von auf v2.x.x wird bis incl. V2.1.7 der Parameter "community" nicht migriert. Dies führt zu einem Fehler falls bisher der Wert vom Defaultwert "public" abweichend gesetzt wurde. Bitte in diesem Fall den richtigen Wert am Tab "Devices" eintragen
https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/163
-
@mcm57 Habe heute den SNMP Adapter upgedatet und jetzt habe ich gesehen das er nicht mehr startet. Auch bei manuellem Start stoppt er gerade wieder.
Im Log:
2022-08-30 21:05:38.903 - info: host.Iobroker "system.adapter.snmp.0" enabled 2022-08-30 21:05:39.020 - info: host.Iobroker instance system.adapter.snmp.0 started with pid 1798235 2022-08-30 21:05:39.756 - info: snmp.0 (1798235) starting. Version 2.1.7 in /opt/iobroker/node_modules/iobroker.snmp, node: v16.17.0, js-controller: 4.0.23 2022-08-30 21:05:39.825 - error: snmp.0 (1798235) device 127_0_0_1 (127.0.0.1) references unknown or completly inactive oid group set-1. Please correct configuration. 2022-08-30 21:05:39.826 - error: snmp.0 (1798235) invalid config, cannot continue 2022-08-30 21:05:39.837 - info: host.Iobroker "system.adapter.snmp.0" disabled 2022-08-30 21:05:39.837 - info: host.Iobroker stopInstance system.adapter.snmp.0 (force=false, process=true) 2022-08-30 21:05:39.839 - info: host.Iobroker stopInstance system.adapter.snmp.0 send kill signal 2022-08-30 21:05:39.840 - info: snmp.0 (1798235) Got terminate signal TERMINATE_YOURSELF 2022-08-30 21:05:39.841 - info: snmp.0 (1798235) terminating 2022-08-30 21:05:39.841 - info: snmp.0 (1798235) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2022-08-30 21:05:40.382 - info: host.Iobroker instance system.adapter.snmp.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) -
@stefu87_ch said in Adapter SNMP V2.x.x Support Thread:
error: snmp.0 (1798235) device 127_0_0_1 (127.0.0.1) references unknown or completly inactive oid group set-1. Please correct configuration.
Obige Zeile ist die relevante Fehlermeldung.
Du hast in deiner Konfiguration ein Device (Tab Devices) mit der IP 127.0.0.1. Dieses referenziert eine OID Gruppe (set-1). Am Tab OIDs existiert entweder keine OID mit dieser Gruppe (set-1) oder alle OIDs die dieser Gruppe zugeordnet sind sind disabled.
Abhilfe:
Entferne den Enabled Marker (erste Spalte) am Tab Devices bei diesem Gerät, d.h. disable das Gerät 127.0.0.1.McM
P.S. Ich glaub mich zu erinnern, dass 127.0.0.1 ein disabled Defaulteintrag der v1.0.0 war. Solltest du also nichts via IP 127.0.0.1 (d.h. am ioBroker Host) überwachen wollen, dann kannst du das Device auch löschen.
-
gelöscht
-
@mcm57 sagte in Adapter SNMP V2.x.x Support Thread:
Abhilfe:
Entferne den Enabled Marker (erste Spalte) am Tab Devices bei diesem Gerät, d.h. disable das Gerät 127.0.0.1.Das war die Lösung. Jetzt startet der Adapter wieder von alleine.
-
@stefu87_ch
Ich hab einen Issue erstellt, dass der Adapter das in einer neueren Version ev. selbst erledigt.
(https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/155).Sorry für die Unannehmlichkeiten beim Umstieg
-
Thema Subtree:
Ist es denn schon möglich eine OID eines Subtrees hinzuzufügen oder müssen alle OIDs innerhalb dieses Subtrees manuell hinzugefügt werden ?
Grüße -
@djmarc75
Derzeit muss jede abzufragende OID einzeln eingetragen werden. Allerdings kann mit V2.x.x eine OID Gruppe für mehrere Geräte verwendet werden (z.B. wenn z.B. mehr als ein nahezu identes NAS, Switch, ...) abgefragt werden soll.Falls hier eine Erweiterung gewunschen ist, bitte einen Issue auf github erstellen.
Je nach Bedarf (Feedback in Github bzw. hier) und notwendigem Aufwand werde ich die Umsetzung einplanen. Ich möchte bzw. kann aber nichts zusagen. Prinzipiell würde ich diesen Wunsch als berechtigt sehen - aber ich kann derzeit den Aufwand nicht abschätzen.Schöne Grüße
Martin -
@mcm57 Vielen Dank für die schnelle Antwort. Ich werde die Tage ein Issue auf Git anlegen.
Im Moment habe ich natürlich jede OID des jeweiligen Subtrees eingetragen.
Adapter läuft erstaunlich gut
-
@djmarc75
Danke für das positive Feedback.Der Dank gebührt aber auch den über 100 Testern die bereit waren den Adapter vom Lastest-Repo zu installieren und bei denen einige Fehler der 2.x.x noch aufgetreten sind die hoffentlich nun behoben sind.
Martin
-
Zwei Rundfragen:
Benutzt jemand von euch den snmp Adapter in folgender Konstellation - insbesondere unter DOCKER: ?Adapter version: V2.7.1
JS-Controller version: 4.0.23
Node version: V16.17.0
Operating system: docker, QNAPEs gibt ein Issue (noch mit sehr wenig Daten) dazu und ich würde gerne wissen, ob der Adapter unter Docker prinzipiell funktioniert - ich habe dazu keine Testöglichkeit).
https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/163
Hat jemand von euch direkt von 0.5.0 auf 2.1.7 aktualisiert?
Da die Config sich zwischen 0.5.0 und 1.x.x nicht unterschieden hat sollte der Upgrade da kein Problem habe. Aber ... wer weiß das schon sicher
DANKE für Feedback
-
Da @Pandia22 (- leider keine Ahnung o b bzw. unter welchem Namen er / sie hier im Forum aktiv ist -) ein Problem mit dem SNMP Adapter in V2.1.7 hat, möchte ich dieses hier nochmals breittreten:
Basis: https://github.com/iobroker-community-adapters/ioBroker.snmp/issues/163
Umgebung / Versionen:
Adapter version: V2.7.1
JS-Controller version: 4.0.23
Node version: V16.17.0
Operating system: docker, QNAPDas IOB-Master-System läuft als Docker auf dem QNAP NAS mit dem SNMP-Adapter der Version 2.1.7. Ein identisches IOB-Slave-System auf einem Raspberry Pi4. Der SNMP-Adapter auf dem Slave in der Version 0.5.0 läuft weiterhin ohne Probleme.
Der Adapter läuft dort in Version 2.1.7 nicht. Es kommt immer zu einem Timeout.
Wenn ich den Issue richtig lese / interpretiere dann ist der Adapter vor dem Upgrade in Version 0.5.0 einwandfrei gelaufen.
Mir fehlen im Moment Ideen. Falls wer eine hat - insbesondere in Bezug auf Docker / QNAP / Loopback auf das eigen QNAP) bitte melden. Detto falls eine ähnliche uMgebung bei jemand funktioniert / oder auch nicht funktioniert.
Ich Hoffe Pandia22 meldet sich hier damit er/sie ggF weitere Infos bereitstellen kann.
McM
-
@mcm57 Hi mcm57, vielen Dank für die Weiterleitung des Tickets. Ich habe heute alle mir bekannten Logs auf dem NAS und der Docker-Umgebung geprüft, ob es Unregelmäßigkeiten im SNMP-Umfeld oder des Adapters gibt. Leider ohne Erfolg.
Jetzt stehe ich auch auf dem Schlauch. Hat noch jemand eine Idee, was ich in der Umgebung noch testen kann?
Kann ich temporär ein Downgrade des Adapter auf die Version V0.5.0 durchführen. Wo stehen die Vorgängerversionen? (Pandia22 - Github)
-
@pandia
Das geht leider nur auf der Commandlinecd /opt/iobroker
npm i iobroker.snmp@0.5.0
iob upload snmpSollte dies erledigen
ACHTUNG:
-) Backup vorher nicht vergessen
-) Config wird NICHT hinuntermigriert - muss daher neu eingetippt werdenBitte - wenn es nicht zuviel Aufwand ist - teste noch vor dem Downgrade ob die 2.1.7 ein anderes Gerät erreichen kann.
Und noch eine Sicherheitsfrage:
Dein Master ioB im Docker hat VOR dem Upgrade (also mit 0.5.0) das QNAP abfragen können? Oder hat sich noch irgendwas geändert? Mein Netgear Switch prüft z.B. von welcher IP der SNMP Request kommt und antwortet einfach nicht, wenn die IP nicht passt. Detto wenn die communitiy nicht passt. -
@Pandia
Ich fasse hier mal weiter Infos aus dem Issue zusammen. Da hier ein größerer Kreis erreicht wird, erscheint es mir sinnvoll hier zu diskutueren:Zitate von Pandia:
Vor dem Upgrade lief der SNMP Adapter auf dem Master in der Version 0.5.0 stabil. Alle Daten wurde korrekt ausgelesen. Es wurden keine sonstigen Veränderungen, außer das Upgrade auf V2.1.7, am System vorgenommen. Die Netzwerkverbindung vom Docker zum QNAP kann ausgeschlossen werden, da diverse andere Adapter die gleiche Netzwerkverbindung benutzen. Der Fehler jedoch nur beim SNMP-Adapter auftritt.
Testbericht: Downgrade des Adapters auf dem Master (QNAP/Docker)
o SNMP-Adapter V2.1.7 gelöscht
o SNMP-Adapter V0.5.0 installiert
o neue SNMP-Instanz hinzugefügt
o qnap_systemCPUUsage OID .1.3.6.1.4.1.24681.1.2.1.0 community = private hinzugefügt und aktiviertErgebnis: Der Adapter (V.0.5.0) baut die Verbindung korrekt auf und liefert kontinuierlich Daten.
Testbericht: Upgrade des Adapters auf dem Slave (Pi4)
o Upgrade SNMP-Adapter von V0.5.0 auf V2.1.7
o qnap_systemCPUUsage OID .1.3.6.1.4.1.24681.1.2.1.0 community = private hinzugefügt und aktiviertErgebnis: Nach dem Upgrade auf die Version V2.1.7 kann die Verbindung auch auf diesem Geräte nicht aufgebaut werden. Das Verhalten ist identisch zum Master unter QNAP/Docker.
Fazit:
o QNAP/Docker kann als Fehlerquelle ausgeschlossen werden
o Fehler ist auf unterschiedlichen Systemen reproduzierbar
o Downgrade auf die Version V0.5.0 beseitigt den FehlerIdee:
o Vielleicht gibt es eine Abhängigkeit zur Note JS Version? Auf beiden Systemen ist Note JS V16.17.0 installiert.
Zitat von @micklafisch
Hallo,
ich reihe mich hier mal ein. Update einer funktionierenden V1.0.0 auf 2.1.7 gemacht und es funktioniert nicht mehr. Downgrade durchgeführt, geht wieder.Das System läuft bei mir auf einer Synology Docker Installation, Node.js: 16.15.1, NPM 8.11.0
ERGO
Ich würde es im MOment auch so sehen, dass das Problem mit dem Adapter zusammenhängt und nicht mit Docker & Co.@micklafisch :
Du schreibts nur "funktioniert nicht". Heißt das identes Fehlerbilde? Timeout im Debug Log oder gibts irgendwelche anderen Logeinträge? -
Habe nun einen Test mit node 16 gemacht - allerdings auf einem Windows 10 System.
node -v
v16.15.1Ergebnis: Alles läuft normal
Habe am Win10 System ( Spielwiesensystem) nun mal schnell node auf 16.17.0 gebracht.
node -v
v16.17.0Ergebnis: Alles läuft noch immer normal
-
Fragst du mit deiner SNMP Installation zufällig auch ein QNAP NAS ab?
Da dein Docker auf einer Synology läuft eher unwahrscheinlich - aber ich suche ein Muster warum 2 User auf 3 System mit unterschiedlicher Hardware ein Problem haben. Ich gehe davon aus, dass die ca 700 anderen User (lt. ioBroker Statistik) nicht stillschweigen würden wenn es dort auch auftritt.Das soll NICHT bedeuten dass ein Fehler bei euch existiert. Ich versuche nur zumindest eine Hypothese zu schaffen was da schief läuft ...
-
@mcm57
Hallo, unter Windows kein Problem:
Plattform: Windows
RAM: 16 GB
NODE.JS: V16.17.0
NPM: 8.11.0
JS Controller: 4.0.23
Admin: 6.2.21
SNMP: 2.1.7
