Frame snmp
Az UDP-datagrammába ágyazott SNMP üzenetek formátuma.
Ábra. az SNMP Management Protocol Semenov Yu.A. (SSC ITEP)
Nem szabad elfelejtenünk, hogy az ASN.1 és a BER-t használják.
A továbbított adatok egy csoportja:
Az eszközre küldött első bájt 30H. Ez egy Univerzális Sequence adattípus-attribútum, és általában BER / DER-kompatibilis protokollok első bájtja.
A 30H bináris ábrázolásában:
Az első két bit a bal oldalon van. Ha nulla, akkor egy univerzális lekérdezést jelez, azaz. minden mezőre érvényes. A bal oldali következő bit egy, ami összetett lekérdezést jelent. A többi bit 10000B = 10H, ez SEQUENCE. Tehát ez az univerzális szekvencia
A tömb következő bájtja tartalmazza a teljes csomag méretét, kivéve az első két bájtot.
A következő bájt 0x02. ez azt jelenti, hogy az ezt követő információ egy egész szám, vagyis egy szám. A kk [3] bájt az adathossz, és kk [4] a tényleges érték. A 0x00 itt jelzi, hogy a protokoll verziója 1 (egy kisebb, mint az SNMP v.1 tényleges értéke).
Következő a 0x04 bájt. amely azt jelzi, hogy a következő adatok oktett (8 bites) karakterlánc. Ezután van egy hosszú bájt és 6 byte karakterkód. A "public" karakterlánc a közösségre mutat. ez a változó jelszóként használható.
A kk [13] bájtja 0xa1. A bináris ábrázolás
Ha a bal oldali három bit = 101, akkor ez azt jelenti, hogy a következő adatok Kontextus-specifikusak. azaz egy adott protokoll dokumentációját kell látnia. Az utolsó négy bit jelzi a számot, amely ebben az esetben 1. Tehát ez a Kontextus-specifikus 1. Az SNMP - Get Next Request dokumentációjában.
A következő bájt a hossza (= 24, a csomag végéig)
A következő három bájt tartalmaz egy kérésazonosítót. amit egyenlővé tettünk. Kk [15] = 0x02, ami az Integer típusát jelzi. A következő bájt a hossza (= 1), majd maga az adat (= 1).
A következő három bájt tartalmazza az aktuális kapcsolat hibaállapotát. Mivel csak elkezdtük a beszélgetést, nullára van állítva.
Természetesen ezután három bájt van a hibaindexet jelezve. Ugyancsak nullára van állítva.
Most, kk [26] = 30H. van egy másik struktúra kezdete (vagy sorrend, ha úgy tetszik).
Közvetlenül az első struktúra után van egy másik. Ez a formátum lehetővé teszi, hogy egyszerre két kérelmet készítsen. Csak add hozzá a következő 0x30-at a struktúra vége és a megfelelő adatok után.
Hosszú bájt után 0x06 bájt van. amely az Objektumadat-típusra (Object Identifier) utal. A következő bájt a hossza.
A következő hét bájt nagyon fontos.
Az ISO korlátlan bölcsességében az internetet fa-szerű hierarchiába fújtatta.
Természetesen a tetején a gyökér (root), akkor megy ISO (1), majd a org ISO (1.3), majd a Védelmi Minisztérium alá dod vagy org (1.3.6). Közvetlenül ezután van Internet (1.3.6.1), az Internetes mi MGMT (1.3.6.1.2) és az alatt MGMT mi MIB vagy a Management Information Database (1.3.6.1.2.1). Mivel SNMP-t használunk, melyet a hálózati rendszerek kezelésére használunk, rendelkezünk rendszerrel (1.3.6.1.2.1.1). Tehát az 1.3.6.1.2.1.1 hierarchiában vagyunk. Az utolsó 3. a kk-ben [36], - A rendszernek a rendszerműködése.
Tehát a kk [30] - kk [36] bájtjai tartalmazzák lekérdezésünk hierarchiáját. Lehet, hogy kicsit zavaros, hogy az első bájt, kk [30], ahelyett, hogy 1.3-as lenne, 0x2b helyett. Valójában ez az ISO egy kicsit bölcsebb (egyszer!). A továbbított bájtok mentésére úgy döntöttek, hogy az első 1.3.6.1.2.1.1.3-ban 40-tel szorozzák, és az eredményt hozzáadják a második számhoz, azaz 3. Szóval, kaptunk 1 * 40 + 3 = 43 vagy 0x2b. Zavaros, de bölcs.
Érdekes pillanat, ha egy objektum értékét lekérdezni szeretné az 1.3.6.1.4.1.9585.1.0 űrlap azonosítójával. Az egyik alkidifier értékének értéke nyilvánvalóan nagyobb, mint 255 (azaz a byte nem illeszkedik). Olvassuk a GOST-ot.
GOST R ISO / IEC 8825-93.
Informatika. Nyitott rendszerek összekapcsolása.
Az első változat (ASN.1) absztrakt szintaktikai jelölésének alapvető kódolási szabályai.
22. Az "objektum azonosító" értékének kódképzése.
22.1 Az "objektumazonosító" értékének kódjának az egyszerű kódképzésnek kell lennie.
22.2. A tartalmi oktettek az alkódjelölők egymás után kódolt (sorrendben) sorrendje (lásd 22.3 és 22.4).
Minden egyes alkódazonosítót egy vagy több oktett szekvenciája képvisel. Az egyes oktettek 8-as bitje jelzi, hogy ez az oktet az utolsó a sorozatban: az utolsó oktett 8. bitjének "nulla" értékűnek kell lennie, és minden előző oktettnek a 8. bitje "egy" értékű. Bitek 1-7 oktettje ebből a szekvenciából kódolt egy alkódazonosítót. Ezeket a bitcsoportokat, egymás után egymáshoz kapcsolódóan, nem aláírt bináris számnak kell tekinteni, amelynek legmagasabb bitje az első oktett 7. bitje, és a legkevésbé szignifikáns bit az utolsó oktett 1. bitje. Az alkódjelzőt a lehető legkevesebb oktettszámmal kell kódolni; ez azt jelenti, hogy a szubdidifikátor fej octete nem lehet hexadecimális értéke 80H.
22.3 Az al-azonosítószám (N) számának kisebbnek kell lennie, mint az objektum-azonosító összetevőinek száma az "objektum-azonosító" kódolt értékben.
22.4 Az első alkidifikátor számértékét az "objektum azonosító" kódolt értékének az első két értékéből kell kiszámítani az alábbi képlet segítségével
(X * 40) + Y,
ahol X az objektum azonosító első összetevőjének értéke,
és Y az objektum azonosító második összetevőjének értéke.
Megjegyzés - Ez a „csomagolt” ábrázolása az első két komponens az objektum azonosító miatt lehetséges, hogy az a tény, hogy a kiosztott értékeket csak három élek a gyökér-csomópontból, és nem több, mint 39 egymást követő értékeinek - a csúcsok megfelelő X = 0 és X = 1.
22.5 Az i. Alpont azonosítójának számjegye (2 <= i <= N) совпадает счисловым значением (i+1)-го компонента идентификатора объекта.
A csomag utolsó két bájtja 0x05 és 0x00. amelyek együtt jelzik a NULL értékét. Ennek az az oka, hogy nem tudjuk válaszolni a kérésben!
44 bájtos válaszcsomag