Ein Kunde fragt nach SNMP v3 (leider keine Chance ihm das auszureden), ich frage mich, ob man das auf unserem STM32F429 zum fliegen kriegen. - Hat das schon jemand versucht bzw hingekriegt? (auf STM32F4xx) - Geht das mit vernünftiger Performance? - Gibt es Beispielcode und/oder Libs dazu? Freeware? OpenSource? Komerziell? Ich bin dankbar für jegliche Feedbacks und Infos
:
Bearbeitet durch User
Peter S. schrieb: > Ein Kunde fragt nach SNMP v3 (leider keine Chance ihm das auszureden), was spricht denn gegen SNMPv3? Ich kenne keine herstellerübergreifend funktionierende Alternative für die Überwachung von Betriebsparametern und -zuständen. Und SNMPv1 und v2 gehen natürlich nicht, da keinerlei Authentifizierung und Verschlüsselung.
:
Bearbeitet durch User
>was spricht denn gegen SNMPv3? UDP statt TCP. Es gibt keine Sicherheit, dass ein Client einen TRAP empfängt. Ein Get,Set oder Respose kann irgendwo verloren gehen, Mann muss ein Tiemout abwarten und hoffen das eine Response ankommt, sonst nochmals versuchen. Das heist man muss rgend was dazu basteln, wenn man eine Übertragundsicherheit will, das macht es schlussendlich langsam (wegen den timeouts), statt dass man gleich TCP verwendet hätte. Und das mit den OBD ist auch eine Krux! >Ich kenne keine herstellerübergreifend funktionierende Alternative.. Leider! >lwIP scheint das zu können: >https://www.nongnu.org/lwip/2_1_x/group__snmp.html Naja, der folgende Satz relativiert das erheblich: When SNMPv3 is used, several functions from snmpv3.h must be implemented by the user. This is mainly user management and persistence handling. The sample provided in lwip-contrib is insecure, don't use it in production systems, especially the missing persistence for engine boots variable simplifies replay attacks."
> Ein Get,Set oder Respose kann irgendwo verloren gehen
Das war bei einem 10 Mbit-Ethernet noch so. Aber mittlerweile
wird nur noch Punkt-zu-Punkt geswitcht.
Da kommt nichts mehr weg...
Aber mit der Kryptografie von SNMP v3 wird der TO sich schwertun.
Und die Persistenz der Daten ist in gemanageden Umgebungen
auch ein Muss. Sieht man schoen wenn die Daten(-bank) eines
solchen LAN-Managementsystems mal ein wenig korrupt werden
und im Netzwerk dann das Hara Kiri losgeht.
Trotzdem viel Erfolg!
... schrieb: > Aber mittlerweile > wird nur noch Punkt-zu-Punkt geswitcht. > Da kommt nichts mehr weg... Dann switch mal von gbit auf 100mbit und staune! Und ja solche Übergangsstellen gibts noch.
https://www.oryx-embedded.com/doc/dir_8f19424e7d8e0e5853bc4f1d9cf5b8f9.html zum abgucken vlt funktioniert da was
>https://www.oryx-embedded.com/doc/dir_8f19424e7d8e0e5853bc4f1d9cf5b8f9.html >zum abgucken >vlt funktioniert da was Cool, das sieht vielversprechend aus. GPLv2 oder Eval-Version zum testen, wenn es was taugt, kann man eine komerzielle Lizens kaufen! => Passt
> Dann switch mal von gbit auf 100mbit und staune! > Und ja solche Übergangsstellen gibts noch. Im Backbone sind immer mindestens (2x) 10 Gbit und das ganze mit VSS gesichert. 100 Mbit hat hier nichts mehr was relevant waere. Unter anderem wird im LAN mit Cisco Netflow (UDP Unicast) gemonitort. Dabei liessen sich Paketverluste sehr schnell diagnostizieren, aber bislang sind immer alle Paeckchen sequentiell und monoton. Es kommt nichts weg.
Ja bei dir vllt ;) In meinem Heimnetzwerk bin ich schonmal in die Falle getappt. Also gibts einen Gegenbeweis und "es kommt nichts weg" stimmt einfach nicht. Was dem TO sein Kunde hat weis er sicherlich nicht. Ob die auch so vorbildlich den Netzwerkverkehr überwachen und ordentliche Switche haben?
:
Bearbeitet durch User
Die Verbindung geht über lange Richtfunkstrecken, da kommt hin und wieder ein Bit falsch an, d.h.Pakete mt CRC-Fehler die verworfen werden. Selbst wenn die Leitung gut ist kann die Gegenstelle vorübergehend weg sein, garade am booten oder ausgeschalten? Und dafür ist SNMP (bzw. UDP) quatsch! Für jedes 'Get' muss man mit Timeout (2..3s) auf eine 'Response' hoffen, ggf. nochmals probieren bzw. irgend wann annehmen, dass die Verbindung oder Gegenstelle weg ist. Das macht es langsam. Und man muss sich ein Daten-Sicherungs-Protokoll darüber basteln, was mit TCP schon inklusive hätte.
Kein Entwickler von Embedded Systemen benutzt TCP wirklich gern. Der Resourcenverbrauch ist deutlich hoeher und das System muss sich auch noch um Aufraeumarbeiten kuemmern wenn eine Verbindung abbricht. Ich durfte mal bewundern wie Admins Netzwerkgeraete zu Tode gemonitort haben. Nach einem Tag Monitoring waren die Geraete per SSH oder Telnet nicht mehr erreichbar. > Für jedes 'Get' muss man mit Timeout (2..3s) auf eine > 'Response' hoffen, ggf. nochmals probieren bzw. irgend wann annehmen, > dass die Verbindung oder Gegenstelle weg ist. Das was du beschreibst sind grenzwertige Bedingungen. Wie man um die herumarbeiten muss, hast du ja schon erkannt. Ein TCP Connect waere da aber auch nicht besser.
>Ein TCP Connect waere da aber auch nicht besser.
Doch, da weiss man in der Regel nach <100ms was Sache ist, wenn keine
Conection zu stande kamm, kann man abbrechen, falls die Connection steht
flutschen die Daten hin und her, und die Apllikation muss sich nicht
drum kümmern, dass alles richtig und vollständig ist.
> da weiss man in der Regel nach <100ms was Sache ist
Ob du es nun glaubst oder nicht, in der Zeit hat ein Geraet
auch auf einen UDP-Request geantwortet.
Wer sein Timeout da auf 2-3 Sekunden dreht, ist vielleicht
etwas uebervorsichtig.
Und das der Netzwerkstack auf den TCP-Syn reagiert, heisst
ja noch lange nicht, das auch die dahinterliegende Applikation
willens und in der Lage ist Daten zu liefern.
Naja, willens vielleicht schon :-).
Peter S. schrieb: > Ein Kunde fragt nach SNMP v3 (leider keine Chance ihm das auszureden), Dann lass ihn finanziell bluten. SNMP ist richtig für den Popo. Was anfänglich immer wieder übersehen wird ist, dass das SNMP-Protokoll alleine gar nichts nützt. Obendrauf kommen die MIBs. Dabei gibt es einen Haufen Standard-MIBs, aus denen man sich die heraus suchen muss, die auf dem Gerät sinnvoll sind. Für weitere zum managende Daten, die nicht durch eine Standard-MIB abgedeckt werden, darf man sich selber eine oder mehrere eigene schreiben. Eine wirklich gute MIB selber zu schreiben ist aber nicht einfach. Also, quetsche schon mal deinen Kunden aus, welche MIBs er haben will, und leg dir schon mal das leider etwas ältere Understanding SNMP MIBs von Perkins unters Kopfkissen. > ich frage mich, ob man das auf unserem STM32F429 zum fliegen kriegen. > > - Hat das schon jemand versucht bzw hingekriegt? (auf STM32F4xx) SNMP ja, aber nie auf STM32F4xx. > - Geht das mit vernünftiger Performance? Richtig gut ist die Performance von SNMP nicht. Was MIB-Compiler erzeugen ist nicht besonders gut, das elende ASN.1 BER Encoding bremst. Dazu kommt wie gut oder schlecht es einem gelingt die Datenquellen und -senken für die MIBs anzubinden. > - Gibt es Beispielcode und/oder Libs dazu? > Freeware? OpenSource? Komerziell? Die einzige Open-Source Bibliothek und Werkzeugsammlung für SNMP, die ich kenne, die etwas taugt ist Net-SNMP http://www.net-snmp.org/ Die ist für Linux und Windows gedacht. Den Agent aus Net-SNMP für einen nackten STM32F429 anpassen? Ufff... Kommerziell (mit etwas Open-Source) gibt es in Deutschland Frank Focks Agentpp Firma https://agentpp.com/ mit diversen Produkten, Compilern usw. > Ich bin dankbar für jegliche Feedbacks und Infos Besonders wenn man selber neun in dem Bereich ist und es eine nicht-triviale SNMP-Anwendung werden soll, solle man am besten schon mal den Berater im Budget einplanen. Dann nimmt man was der Berater vorschlägt. Billig wird das nicht.
@Hannes J. >Dann lass ihn finanziell bluten. SNMP ist richtig für den Popo. Wenn wir teurer sind als die Mitbewerber, wirds nix mit dem Auftrag >Also, quetsche schon mal deinen Kunden aus, welche MIBs er haben will... Nicht viel, eine handvoll Parameter bzw. Zustände die er abfragen will. >SNMP ja, aber nie auf STM32F4xx. Wieso nicht? Der hat ganz ordentlich viel Dampf under der Haube: 32 Bit, FPU; 180 MHz, reichlich FLASH und SRAM, stellt meinen esrten 100 MHz 486er locker in den Schatten. Sollte für einige UDP-Pakete pro Sekunde reichen. >Die einzige Open-Source Bibliothek und Werkzeugsammlung für SNMP, die ich kenne... Der bereits erwähnte Cyclone.TCP (https://www.oryx-embedded.com/#&panel1-2) sieht recht vielversprechend aus, aber keine Ahnung was er kostet. Jedenfalls habe ich kurzerhand ein beileigendes Bespiel für das Nucleo-F429ZI mit dem ARM-GCC bauen können, jetzt muss ich bloss noch das passende Board ordern um es auszuprobieren. Fragt sich ober der TCP-Stack der mit dem Keil MDK dabei ist auch was taugt, insbesondere für SNMP.v3 und ev IP.V6? LwIP habe ich geprüft, der scheidet aus. Scheint mir ein eher ein Flickwerk mit vielen Hacks und nicht nur SNMP.v3 ist unvollständig implementiert.
:
Bearbeitet durch User
gdgddfgdfd schrieb: > https://www.oryx-embedded.com/doc/dir_8f19424e7d8e0e5853bc4f1d9cf5b8f9.html > zum abgucken > vlt funktioniert da was Muss gerade auch was machen mit SNMPv3. Also selber machen kann man als mittlere oder kleine Industriefirma gleich vergessen, viel zu viel Aufwand sich die ganzen Module zu programmieren die dafür benötigt werden. Insbesondere die ganzen Hash- und Cryptogeschichten sind alles andere als trivial. Hab mir von Oryx Embedded den CycloneTCP Stack mit SNMPv3 angeschaut. Was ich schon mal sagen kann ist, dass das ganze sehr schön strukturiert ist. Ein mitgelieferte Beispiel (für sw4stm32) konnte ich in STM32CubeIDE importieren, builden und läuft problemlos auf dem NUCLEO-H743ZI auf dem ich das getestet habe.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.