2012-05-25 10 views
5

Piszę agenta SNMP, a definicja MIB zawiera OID typu Unsigned32.Jakie jest prawidłowe kodowanie dla typu SNMP Unsigned32?

Implementacja Unix agenta używa Net-SNMP i ustawia OID jako typ ASN_UNSIGNED, ponieważ nie ma on ASN_UNSIGNED32. Kiedy patrzę na odpowiedź GET z Wireshark, dekoduje ją jako wartość "Gauge32". To ma sens na pierwszy rzut oka, ponieważ zgodnie z RFC 1902 Unsigned32 i Gauge32 są takie same.

Implementacja Windows opiera się na SnmpAPI.lib Windows i ustawia OID jako ASN_UNSIGNED32, a gdy patrzę na odpowiedź GET z Wireshark, dekoduje ją jako "Unsigned32". Wydaje mi się to jeszcze lepsze.

W jaki sposób 2 wdrożenia dają różne wyniki na drucie?

Jaka jest poprawna wersja i jak mogę ją uzyskać z obu implementacji?

Odpowiedz

5

Okazuje się, że Net-SNMP używa aktualnego kodowania RFC 1902, w którym Unsigned32 i Gauge32 są identyczne, podczas gdy Windows używa przestarzałego kodowania RFC 1442, gdzie Unsigned32 i Gauge32 mają różne kodowania.

+1

Dobry połów. Brzmi jak błąd systemu Windows. –

+0

Wygląda na to, że Microsoft nie zaktualizował usługi SNMP od 1996 roku, kiedy pojawił się RFC 1902. Dlatego po prostu trzymają się starej wersji i wydaje się, że większość narzędzi SNMOP jest nadal zgodna z RFC 1442. –

1

Zapisanie przechwytywania Wireshark w systemie Windows, a następnie otwarcie go w programie Wireshark na systemie Unix. Wtedy możesz zobaczyć, jaki jest typ, który pokazuje. Unsigned32 i Gauge32 są wymienne określone przez standard, więc nie powinno być żadnych różnic we wszystkich implementacjach SNMP. Na drucie powinien przesłać te same bajty.

+0

To, co myślałem, ale oba ślady Wireshark zostały wykonane na Linuksie, a OID od agenta Linuksa są wyświetlane jako Gauge32, a te z agenta Windows są wyświetlane jako Unsigned32. Ten sam plik wykonywalny Wireshark na tym samym komputerze. –

+0

Nie miał czasu, aby zanurkować w parserze Wiresharka. Ale tak jak powiedziałem, powinieneś przeczytać surowe bajty. Zrobiłeś to? –

Powiązane problemy