API für Netgear Switches (JGS524E)?

[Mickey Mouse]

konkreter Fall:
ich habe drei Netgear Switches, zwei JGS524E, einmal V1 (ohne Web/HTML Console, nur propietäres Windows Tool) und den "neueren" V2 mit Web-Interface (das Tool funktioniert da aber auch), dazu noch einen kleinen GS108E-V3 (ebenfalls mit Web-Interface & Tool).

jetzt würde ich gerne automatisch einige Werte (genauer die CRC Errors aber auch gerne die traffic counter) auslesen.
naiv wie ich bin, dachte ich zumindest bei den V2/3 ist das ja ganz einfach, cURL, Perl HTMLarse oder mit großem Besteck und Python mit beautifulsoup sollte das ja kein Problem sein. So mache ich das z.B. um meine Yamaha AVR zu bedienen.
Nur basieren die Seiten auf JavaScript und dafür bin ich zu alt und blöd...
beim V1 würde das ja aber eh nicht gehen.

daher lange Rede kurzer Sinn: kennt jemand eine Doku oder sogar eine Library (Perl, Python, C...) zur API um Netgear Switches "zu bedienen"?

und NEIN, snmp können die Teile nicht, genauso wenig wie telnet/ssh, das wäre ja viel zu einfach. Auf der anderen Seite werde ich aber auch nicht alle Switches ersetzen, nur um in der Übersicht von der Hausautomatisierung die Zählerstände der Switches zu haben.
oder ich muss das doch noch mit Java-Script lernen und durch eine lokale Browser Engine jagen, mal sehen...

und wenn ich schon dabei bin: die MACs der angeschlossenen Geräte bekomme ich nichtmal über das Web-Interface raus, das wäre natürlich auch noch eine interessante Information

 

[Raijin]

Hm.. Ich meine, dass Netgear hier ein proprietäres Protokoll einsetzt : NSDP

Auf github gibt's dazu auch ein Projekt: Klick!

 

[Mickey Mouse]

sauber Danke, das muss ich mir heute Abend in Ruhe ansehen.
im Wiki sind ja noch mehrere Projekte verlinkt.
das von Github lässt sich zwar ohne Probleme auf Anhieb kompilieren, findet aber keinen meiner Switches und liest sie auch mit angegebener MAC nicht aus. Da muss ich mal forschen was da schief läuft.

 

[Raijin]

Ich bin mir aber nicht sicher ob du damit überhaupt die gewünschten Daten abrufen kannst. Die L2-Smart-Switches haben nur rudimentäre Management-Funktionen und ich gehe stark davon aus, dass auch die API entsprechend kastriert ist. So smart solche Switches heutzutage auch sind, sie haben keine vollwertige CLI wie ein L3-Switch.

 

[Mickey Mouse]

Doch, das (bisschen) was ich möchte (in erster Linie die Statistiken) liefern die ja auch über das mitgelieferte Tool. Und in dem Source-code kann man das auch erkennen.
Im Moment bekomme ich allerdings nur Timeouts, das muss ich mir wie gesagt in Ruhe ansehen. Ich bin mir gar nicht sicher, ob auf dem Testrechner die Firewall komplett aus war...

 

[Raijin]

Ok, bin gespannt was draus wird, hab ja auch einen JGS524E im Einsatz. Halt mich also auf dem Laufenden

 

[Mickey Mouse]

es ist mir etwas peinlich, das hat mir über Mittag keine Ruhe gelassen, die Firewall war tatsächlich aktiv (auf meinem Spielzeug NUC mit SuSE Tumbleweed).
kaum macht man es richtig, funktioniert es auch
das Tool vom verlinkten Git Projekt liest die Daten schonmal problemlos aus, allerdings nicht die CRC counter, das ist in dem Tool gar nicht vorgesehen/eingebaut. Da werde ich mir mal die anderen Quellen ansehen, ob es da Hinweise dazu gibt. Das Web-Interface spuckt die zusammen mit den Rx/Tx Countern aus, vielleicht werden da nur die Rückgabewerte nicht ausgewertet, sind ja i.d.R. eh Null.

aber so habe ich auf jeden Fall schonmal was zum Spielen und kann z.B. die Rx/Tx Counter protokollieren und so Anomalien sichtbar machen.

 

[Mickey Mouse]

fertig!

nuc2:~/libnsdp-master> diff nsdp_property_types.c.orig nsdp_property_types.c
328,329c328,329
<   snprintf(txt, txt_size, "%d:rx=%" PRId64 ",tx=%" PRId64,
<            stat[0], nsdp_get_u64be(stat+1), nsdp_get_u64be(stat+1+8));
---
>   snprintf(txt, txt_size, "%d:rx=%" PRId64 ",tx=%" PRId64 ",er=%" PRId64,
>            stat[0], nsdp_get_u64be(stat+1), nsdp_get_u64be(stat+1+8), nsdp_get_u64be(stat+1+40));

jetzt druckt er mir auch die CRC Error Counter bei der Port Statistik aus. Zumindest habe ich durch mehrfaches Stecker ziehen/stöpseln ein paar Fehler provoziert und die werden vom Tool für diesen Port jetzt auch angezeigt.
also Offset 1: RX, O 9: TX, O 17/25: keine Ahnung (scheint irgendwie mit der Zahl der Rx/Tx Pakete zu korrelieren nur ca. Faktor 200 kleiner), O 33: hier immer Null, O 41: CRC-Errors

jetzt kann es mit dem regelmäßigen Auslesen und Auswerten der Daten weiter gehen. Wahrscheinlich baue ich mir eine Version, die die Werte etwas "geordneter" ausgibt. Das ging jetzt wesentlich flotter als ich gedacht hatte und ich muss erstmal in mich gehen, ob ich das als simples CSV oder JSON ausgebe oder gleich in eine InfluxDB schiebe, das weiß ich noch nicht...