[2014/02/17 00:47:27] #net-snmp <cousin_luigi> fenestro: I added a "pass 2.25.UUID.1 myscript" line, but snmpwalk doesn't appear to be seeing it: is it normal?
[2014/02/17 03:49:02] #net-snmp <fenestro> cousin_luigi: if you run snmpwalk with no arguments, it just walks mib-2; try "snmpwalk <argumetns> .2"
[2014/02/17 03:52:15] #net-snmp <cousin_luigi> fenestro: snmp_build: unknown failuresnmpwalk: Error building ASN.1 representation (Can't build OID for variable)
[2014/02/17 03:52:20] #net-snmp <cousin_luigi> (with .17)
[2014/02/17 03:53:34] #net-snmp <fenestro> yeah, that is the kind of failure that I would expect to see when using the UUID in this way
[2014/02/17 03:54:12] #net-snmp <fenestro> while it's technically valid, I don't think anyone actually tests using OID segments larger than 2^32
[2014/02/17 03:56:30] #net-snmp <cousin_luigi> What could be a relatively safe hack?
<-- JeffJohnson has left #net-snmp
[2014/02/17 05:09:44] #net-snmp <DanielJanzon> /names
[2014/02/17 05:11:43] #net-snmp <DanielJanzon> rstory-work: Thanks for your response the other day (15 Feb 16.33), I was distracted and didn't see your response until now
[2014/02/17 05:13:17] #net-snmp <DanielJanzon> I was asking about the error status flag in trap messages since I was under the false impression it could be used to reset a previous trap
[2014/02/17 05:13:39] #net-snmp <DanielJanzon> It's really hard to find best practices for clearing traps :)
[2014/02/17 05:14:03] #net-snmp <DanielJanzon> Anyone knows the best practice for SNMPv2?
[2014/02/17 05:15:20] #net-snmp <DanielJanzon> I can't find anything in the netsnmp plugin API, so I guess there is no one way of doing it?
[2014/02/17 06:56:12] #net-snmp <rstory-work> DanielJanzon: there is no standard for clearing traps..
[2014/02/17 06:56:52] #net-snmp <rstory-work> when you say clearing, are you talking about the device indicating the error condition is resolved, or the manager acknowledging it received the trap?
[2014/02/17 06:57:54] #net-snmp <rstory-work> cousin_luigi: re a walk triggering your script, the script should only perform it's action when it receives a set request. a get request should just return 0 and do nothing..
[2014/02/17 07:03:54] #net-snmp <DanielJanzon> I'm talking about indicating that the error condition is resolved
[2014/02/17 07:05:07] #net-snmp <rstory-work> ok.. then the error/status object in the trap could have a special value defined to indicate 'normal', and you just send that trap again.
[2014/02/17 07:05:50] #net-snmp <rstory-work> but since there is no standard, the manager might see that as another error condition.
[2014/02/17 07:05:55] #net-snmp <DanielJanzon> And the error/status object is vendor-specific? Or is it covered by any rfc?
[2014/02/17 07:06:42] #net-snmp <rstory-work> no standard, highly specific... like I said, usually the same oid as the error condition..
[2014/02/17 07:06:46] #net-snmp <DanielJanzon> OK, so a manual association of the traps is needed in the manager?
[2014/02/17 07:06:52] #net-snmp <rstory-work> yes
[2014/02/17 07:06:52] #net-snmp <DanielJanzon> Thx
[2014/02/17 07:08:19] #net-snmp <rstory-work> so say you have and oid x.voltage. when voltage exceeds a threshold, you can send a trap with x.voltage and it's value, and when the voltage drops to normal, resend the trap with the current (haha) value...
[2014/02/17 07:09:39] #net-snmp <rstory-work> or, you can have 'voltageHigh' trap, which has as it's value the OID of the dohickey with the high value, and another voltageNormal trap, again with the OID of the normal device..
[2014/02/17 07:14:23] #net-snmp <DanielJanzon> And the association is just available in the manual? There is no way to define it in the MIB?
[2014/02/17 07:16:03] #net-snmp <rstory-work> It can be defined and explained in the text of the MIB, but people read MIBs even less often than they read manuals. And no, there is no easy machine-readable way of making the association. It's in the text of the MIB descriptions...
[2014/02/17 07:16:47] #net-snmp <DanielJanzon> Ok too bad for the operation people but no prob for me as a dev :)
[2014/02/17 07:17:31] #net-snmp <DanielJanzon> In any case its outside the netsnmp scope, which is what I wanted to verify
[2014/02/17 07:18:56] #net-snmp <DanielJanzon> It kind of surprises me though that there are no standard OIDs to encode trap reset and alarm description etc
[2014/02/17 07:19:46] #net-snmp <DanielJanzon> Or rather variable bindings, but I guess they all uses OIDs
[2014/02/17 07:23:17] #net-snmp <DanielJanzon> Wow just found ITU X.733 that seems to try to standardize these things
[2014/02/17 07:30:41] #net-snmp <rstory-work> i think that turned into the disman mib, which we do support..
[2014/02/17 07:33:18] #net-snmp <DanielJanzon> "we" as in netsnmp?
[2014/02/17 07:33:48] #net-snmp <rstory-work> they have the concept of a generic 'trigger'.. and define a 'rising' and 'falling' trap (which would work for the voltage example above)..
[2014/02/17 07:34:05] #net-snmp <rstory-work> yes, we = net-snmp..
[2014/02/17 07:35:08] #net-snmp <cousin_luigi> rstory-work: but what parameter would be sent via set?
[2014/02/17 07:35:23] #net-snmp <cousin_luigi> rstory-work: the script already works like that
[2014/02/17 07:37:10] #net-snmp <rstory-work> it's all defined in http://tools.ietf.org/html/rfc2981 ... it's a little different that the standard concept of devices sending traps, because the device doesn't send a trap - the agent is monitoring the device (via snmp), and the disman tables are configured to define triggers.
[2014/02/17 07:37:43] #net-snmp <rstory-work> so traps happen a little slower, since the agent is polling, instead of firing immediately..
[2014/02/17 07:38:38] #net-snmp <rstory-work> disman can be used to monitor other devices, or the agent can self-monitor..
[2014/02/17 07:39:42] #net-snmp <rstory-work> there's a very simple example here http://www.net-snmp.org/wiki/index.php/TUT:DisMan_Monitoring
[2014/02/17 07:40:15] #net-snmp <rstory-work> it shows monitoring cpu load.. but it only polls every 10 minutes...
[2014/02/17 07:40:36] #net-snmp <rstory-work> so a spike would only trigger an event if it happened at the right time...
[2014/02/17 07:40:53] #net-snmp <rstory-work> as always, there are tradeoffs..
[2014/02/17 07:45:01] #net-snmp <DanielJanzon> true, but I guess polling within the same machine can be performed quite often
[2014/02/17 08:02:24] #net-snmp <DanielJanzon> So if you'd like to monitor something that there is no standard mib for, you'd make your own plug-in callback for snmp querying, and then add monitor config in snmpd.conf?
[2014/02/17 08:03:36] #net-snmp <DanielJanzon> Is netsnmp_register_handler(netsnmp_handler_registration *reginfo); the right entry point for a plugin?
[2014/02/17 08:03:49] #net-snmp <rstory-work> that should work... monitor config is a net-snmp-ism..
[2014/02/17 08:05:07] #net-snmp <rstory-work> if what you are calling a plugin is a regular MIB module, yes.. our mib2c tool can help with generating skeleton code for a proprietary mib..
[2014/02/17 08:29:06] #net-snmp <DanielJanzon> In netsnmp_register_handler() you specify the root-OID so I assume the netsnmp core understands it should delgate queries to the plug-in
[2014/02/17 08:29:40] #net-snmp <rstory-work> yes, that's what register does..
[2014/02/17 08:30:28] #net-snmp <DanielJanzon> thx a lot for all you wisdoms rstory! it has been very helpful
[2014/02/17 08:30:49] #net-snmp <rstory-work> you're welcome