On Thu, 2005-01-20 at 23:35, Carlos Cantu wrote:
> > Because the hrDeviceTable contains entries for a wide variety
> > of different types of device, the code for reporting the status
> > and error count is very device-specific.
> > So the code will look for a device-specific hook routine,
> > and if that's not provided for a particular type of device, it
> > will skip the instance altogether.
>
> Reading the MIB, and maybe I'm missing something here, it doesn't
> seem like this OID is optional. In my interpretation, if the hook
> is missing, the value returned should be 'unknown(1)'.
Strictly speaking, you're probably correct.
And in the case of hrDeviceStatus, there is indeed a suitable
value to return, so it would be possible to return unknown(1)
in the absence of a proper status hook routine for that type
of device.
Unfortunately, things aren't so simple for hrDeviceErrors.
If the agent doesn't have a suitable device-specific error hook
routine, there isn't a similar dummy value that can be used.
Returning 0 would give the impression that the device was
working flawlessly, which might not be correct.
In general we've felt that it's better to admit to a lack
of information (even if this is technically not allowed),
rather than to lie! :-)
> > Checking the code, it's only the network interface and printer
> > devices that support both of these, and the processor device
> > only supports hrDeviceStatus.
>
> What I am seeing is that on my SuSE Intel box:
> * Rows with hrDeviceTypes of hrDevicePrinter & hrDeviceNetwork
> show valid hrDeviceStatus & hrDeviceErrors
> On my SuSE RISC box:
> * Row with hrDeviceType of hrDevicePrinter has row for
> hrDeviceStatus & hrDeviceErrors
> * Rows with hrDeviceType of hrDeviceNetwork do not show any
> rows for hrDeviceStatus & hrDeviceErrors (possibly no hooks,
> but seems like a bug)
> * Row with hrDeviceType of hrDeviceProcessor does not have
> a corresponding row for hrDeviceStatus (seems like bug as per
> your comments above)
Hmmmm.... that sounds strange.
All I can suggest is that you try running the agent under a
debugger, set a breakpoint in the routine var_hrdevice() -
say in the HRDEV_STATUS block, and then issue the single request
snmpgetnext .... hrDeviceStatus.1024
(probably with '-r 0 -t 6000' to avoid repeating the request)
That _ought_ to return the status of the first network card.
Check whether device_status[4] is set, and then single step
through this call, which should take you into the routine
hr_network.c:network_status()
[ from RISC output ]
> hrDeviceDescr.1 = My Printer
> hrDeviceDescr.768 = An electronic chip
> that makes the computer work. <--- INTERESTING
Sorry - that's my slightly off-beat humour at work again.
> hrDeviceDescr.1025 = network interface lo
> hrDeviceDescr.1026 = network interface tunl0
> hrDeviceDescr.1027 = network interface eth0
> hrDeviceDescr.1028 = network interface eth1
> hrDeviceDescr.1029 = network interface sit0
Those entries do show that the 'device_descr[]'
(and 'next_device[]') hooks are working properly,
at least. That makes it look as if it's probably
just the 'device_status[]' (and 'device_errors[]')
hooks that are affected - my guess is that they're
not actually being set. But you can check that by
running things under the debugger.
I'm afraid I can't be of much more help with this problem.
I've currently stepped down from active support of the
Net-SNMP project. But I'm sure the rest of the people on
the -users list will be able to guide you appropriately.
Good Luck.
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
