I'm using Net-SNMP 5.5.0-2.x64 on Windows 10 1803. I'm trying to get SNMP values from a Ricoh printer. I've downloaded Printer-MIB and placed it in my C:\usr\share\snmp\mibs folder. I also downloaded and placed IANA-CHARSET-MIB and IANA-PRINTER-MIB. I also double checked snmp.conf to make sure they're in the right mibdirs folder.
I'm trying to access the value for black toner. I found some OIDs here, which I was trying to use for my example.
When I try to access the value for black toner:
snmpwalk -v 1 -c public -m Printer-MIB x.x.x.x 1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1
I get
SNMPv2-SMI::enterprises.367.3.2.1.2.24.1.1.5.1 = INTEGER: 80
I get the same result when I try -m ALL as well. Also if I try added Printer-MIB::printmib at the end, I get the same exact message.
When I try the command:
snmptranslate -IR -Td Printer-MIB::prtMarkerSuppliesLevel.1.1
I get
Printer-MIB::prtMarkerSuppliesLevel.1.1
prtMarkerSuppliesLevel OBJECT-TYPE
-- FROM Printer-MIB
SYNTAX Integer32 (-3..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION "The current level if this supply is a container; the remaining
space if this supply is a receptacle. If this supply
container/receptacle can reliably sense this value, the value
is reported by the printer and is read-only; otherwise, the
value may be written (by a Remote Control Panel or a Management
Application). The value (-1) means other and specifically
indicates that the sub-unit places no restrictions on this
parameter. The value (-2) means unknown. A value of (-3) means
that the printer knows that there is some supply/remaining
space, respectively."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) printmib(43) prtMarkerSupplies(11) prtMarkerSuppliesTable(1) prtMarkerSuppliesEntry(1) prtMarkerSuppliesLevel(9) 1 1 }
So doesn't that mean SNMP sees the file and can parse it?
Edit:
I was able to get the MIB file to work, but the OID values are confusing me. I ran snmpwalk -v 1 -c public x.x.x.x Printer-MIB::printmib and now the values with their MIB tags print. However, when I come across the value for black ink, the OID doesn't match the one I had found online, but they return the same value.
C:\usr\bin>snmpwalk -v 1 -c public x.x.x.x Printer-MIB::prtMarkerSuppliesLevel.1.1
Printer-MIB::prtMarkerSuppliesLevel.1.1 = INTEGER: 80
and
C:\usr\bin>snmpwalk -v 1 -c public x.x.x.x 1.3.6.1.4.1.367.3.2.1.2.24.1.1.5.1 Printer-MIB::printmib
SNMPv2-SMI::enterprises.367.3.2.1.2.24.1.1.5.1 = INTEGER: 80
If I run snmptranslate, I get a completely different OID than the one I had been using before:
C:\usr\bin>snmptranslate -On Printer-MIB::prtMarkerSuppliesLevel.1.1
.1.3.6.1.2.1.43.11.1.1.9.1.1
Not sure why the OID I found online works to retrieve the value, but not to work with the MIB file. Some sort of mix between proprietary and public MIB data?
Try the right OID
snmpwalk ... 1.3.6.1.2.1.43.5.1.1.16
Related
I'm trying to add a custom mib file that contains few nodes.
For an example I tried loading SNMP-COMMUNITY-MIB as it's a standard mib and thus shouldn't throw errors.
I copied the mib into the path
~/.snmp/mibs
and also updated snmpd.conf as:
mibdirs +$HOME/.snmp/mibs
mibs +SNMP-COMMUNITY-MIB
I tried to print the oid of one of the nodes "snmpCommunityName" using:
snmptranslate -m +SNMP-COMMUNITY-MIB -IR -On snmpCommunityName
it worked fine and the oid was printed.
I then tried to list all using snmpwalk:
snmpwalk -v2c -c public localhost
But the nodes from my mib and its oid's were not printed.
How can I have my oids listed on snmpwalk?
I accidentally noticed that when I run snmpwalk without an OID, I get only 593 variables from my device, and the device-specific variables are missing. But if I add 1 as the OID, I get 2527 variables, including the ones which are the most useful. So in your case try adding 1 at the end of the snmpwalk command:
snmpwalk -v2c -c public localhost 1
Edit: The above method worked on an APC PDU, and on a Supermicro BMC. The BMC was a bit confusing because it did not use the OID names from the MIB file, but all the information I need is there.
i try to monitor values with nagios over snmp from my two audiocodes SBCs (M500L).
For these i download two MIBs "AC-ALARM-MIB" + "IP-MIB_rfc4293" from https://github.com/librenms/librenms/tree/master/mibs/audiocodes rename it to .txt at the end and upload it to my ubuntu server in path /usr/share/snmp/mibs/.
Then i try to use the following command in command line.
snmpget -v3 -l authPriv -u xxxxxx -a SHA -A xxxxx -x AES -X xxxxx 123.456.789.100 AcAlarm:acActiveAlarmName
and i get the following output
AcAlarm::acActiveAlarmName = No Such Instance currently exists at this OID
I try to find out the OID from these in MIB Browser - seems like it is " .1.3.6.1.4.1.5003.11.1.1.1.1.5". When i use these OID i get same output.
Anyone has an idea?
SNMP treats all values as being entries in some database. OIDs are used to identify entries in this conceptual database. MIB files allow an SNMP manager to translate OIDs into a human-readable string, with an accompanying textual description.
The issue here is not that the MIB files are bad, or the OIDs are wrong, the problem is that, either the devices that hold this (imaginary) database do not support the entries you are trying to access, or that your user is not authorized to access those entries. A simple way to find out what OIDs are supported would be to do a full walk of the database, using something like snmpwalk <hostname> 1.3.6.1
Currently, my OIDs branch from Net-SNMP using extend, which results in an OID like this:
SNMPv2-SMI::enterprises.8072.1.3.2.4.1.2.1.49.1258
or without the MIB:
.1.3.6.1.4.1.8072.1.3.2.4.1.2.1.49.1258
8072 is Net-SNMP,
49 is the decimal value of an ASCII "1" (an arbitrary name I gave my extension), and
1258 is a 'leaf' on my root OID (49).
Now that I have a PEN, how do I go about making my OID tree under my PEN so that I can execute an snmpwalk that displays:
.1.3.6.1.4.1.<MyPEN>.<MyOIDTree>
OS: Linux (Raspbian)
Partial Solutions:
-Good-
Specify an OID in the extend command (in snmpd.conf) like so:
extend [OID] <extName> </dir/binary> </dir/script>
The OID is optional, however, omitting it will cause the Net-SNMP PEN to be used by default.
In my case, my extend looks like this:
extend .1.3.6.1.4.1.<myPEN> SQL /bin/sh /usr/sbin/MyScript.sh
This produces the following output:
.1.3.6.1.4.1.[PEN redacted].4.1.2.3.83.81.76.1258 = STRING: "My Data"
This is much closer to the desired structure since it is now extending from a custom PEN, though one is now faced with trimming off the .4.1.2.3 and the .83.81.76 (resulting from the extension name 'SQL').
If anyone knows how to remove those, post it as a new answer!
-Better-
Use the pass command:
pass .1.3.6.1.4.1.PEN /bin/sh /home/pi/net-snmp/local/shellCode
Shell code example: passtest
Output:
.1.3.6.1.4.1.PEN.1.0 = STRING: "Hello World!"
.1.3.6.1.4.1.PEN.2.1.2.1 = INTEGER: 9
.1.3.6.1.4.1.PEN.2.1.3.1 = OID: .1.3.6.1.4.1.PEN.99
.1.3.6.1.4.1.PEN.3.0 = Timeticks: (363136200) 42 days, 0:42:42.00
.1.3.6.1.4.1.PEN.4.0 = IpAddress: 127.0.0.1
.1.3.6.1.4.1.PEN.5.0 = Counter32: 9
.1.3.6.1.4.1.PEN.6.0 = Gauge32: 9
This appears to solve both issues, however I am unsure of the extent of its capabilities in comparison to a 'proper' OID tree installation.
-Best- (Complete Solution)
Register OIDs using a MIB...
I am extending my snmp agent with a self developed MIB file.
What I've noticed is that when I do a walk it prints my variables as
MY-MIB::myvariable.0
But I've specifically placed the variable at at an OID which is does not end at 0.
I am using the net-snmp library functions:
netsnmp_create_handler_registration
and also
netsnmp_register_read_only_ulong_instance
to register my instances.
It only seems to happen with netsnmp_create_handler_registration. But when I specify reg_oid_len one shorter, it double registers some of the variables.
I am going in to this assuming that your question is 'Why is a 0 appended to my OID?'
In order to access any scalar value you have to append a .0 to the leaf node of the tree. If you were attempting to address a table entry you would need to append the index of the entry into the table. Not using the .0 on a scalar will typically cause problems if you're not using the OID as the argument to something like a bulkget or a walk, i.e.
$ snmpget -v2c -c public 192.168.1.120 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0 = STRING: things, stuff
$ snmpget -v2c -c public 192.168.1.120 1.3.6.1.2.1.1.1
SNMPv2-MIB::sysDescr = No Such Instance currently exists at this OID
$ snmpwalk -v2c -c public 192.168.1.120 1.3.6.1.2.1.1.1
SNMPv2-MIB::sysDescr.0 = STRING: things, stuff
see this net-snmp mailing list entry for more explicit detail on why scalars end in 0.
I am trying to send an snmp message with snmptrap from the commandline, and the manual isn't super clear.
I have managed to send the example message successfully (10.0.0.1 == where I'm sending the messages to)
snmptrap -v 1 -c private 10.0.0.1 NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification "" 6 17 "" netSnmpExampleHeartbeatRate i 13546
But when I want to send a resynchronisation message such as:
snmptrap -v 1 -c private 10.0.0.1 HW-IMAPV1NORTHBOUND-TRAP-MIB::hwNmNorthboundEventSynchronizationCommandStart
I need to add a few more arguements. I've tried adding myip:myport:date:date or just myip:myport, but no success. I'm not too clear on what should be the following arguements. The man page:
snmptrap -v 1 [COMMON OPTIONS] [-Ci] enterprise-oid agent generic-trap specific-trap uptime [OID TYPE VALUE]
What should be the generic-trap, specific-trap etc?
From the MIB files:
: 1.3.6.1.4.1.2011.2.15.1.7.7.4
hwNmNorthboundEventSynchronizationCommandStart OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
Format to omit dst flag:- IP:port:start time:end time:timezone, will consider the dstflag to be 0
Does someone have a bit more experience than me with SNMP to understand what I need to put in the command line arguements?
thanks!
I don't know if I should delete this question, or leave it, but my problem was partly because somehow the mib file was no read, and I had to use the OID directly. Otherwise the "arguments" depends on the mib file, the 6 is always 6, the 17 on the otherhand should correspond to the last number in the oid of the mib..