Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm doing an "snmpwalk" to a remote device. In response I get something like this:

. -> Hex-STRING: 24 37 4C 0C 65 0E 
. -> Hex-STRING: 24 37 4C 0B A2 DA 
. -> STRING: "$7L
. -> STRING: "$7L

As you can see some variables are of a STRING type, others are Hex-STRING. The correct output would only have Hex-STRING types.

So, I'm wondering whos fault is this? Does the remote device send the variable's type in responce? Or snmpwalk has to guess the type?

share|improve this question
up vote 1 down vote accepted

All object types and names are defined in the MIB(s).

Without MIBs for the OIDs returned, snmpwalk can only show dot-names and raw data values.

Since you only get dot-names (and not MIB-defined object names) in the response, snmpwalk probably guesstimates what the object type is.

You can simply include the relevant (missing) MIB definition somewhere so snmpwalk can load it.

share|improve this answer

This mailing list post explains things; per RFC 2579, MIBs can contain a DISPLAY-HINT in their definition of variables. This defines how the data might be displayed; e.g. as a number to 2 decimal places, an ASCII string, etc.

You can pass snmpcmd options to snmpwalk such as -Oa or -Ox to force variables not having a display hint to be interpreted as ASCII or hex respectively; or you can use -d to dump the raw packets. The explanatory text for -Ih is quite informative, too:

disables the use of DISPLAY-HINT information when assigning values. This would then require providing the raw value:

snmpset ... HOST-RESOURCES-MIB::hrSystemDate.0

               x "07 D2 0C 0A 02 04 06 08"

instead of a formatted version:

snmpset ... HOST-RESOURCES-MIB::hrSystemDate.0

               = 2002-12-10,2:4:6.8 

The best place to find fine detail on the SNMP standard is of course the relevant RFCs; the O'Reilly book Essential SNMP is probably worth a read, too.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.