Re: Alarms oddity ...

[Robin Iddon <[e-mail]>]

   This isn't a problem.  The threshold description in the MIB says:
   >>	When the
   >>	current sampled value is greater than or equal to
   >>	this threshold, and the value at the last sampling
   >>	interval was less than this threshold, a single
   >>	event will be generated.

   Let me emphasize "...and the value at the last sampling interval was
   less than this threshold, ..."
   If the value arrived at the common threshold value from "above"
   ("below"), the probe will generate a single falling (rising) alarm. 
   Nothing more will be generated while in that state.
   End of controversy?  (or else I missed something).

Oh yeah :-) - This is of course the nicest behaviour (and is what I fixed our
box to do).

   The packet match trap could easily have been generated using an alarm
   with risingThreshold == 1 and fallingThreshold == 0 (as I described
   earlier).  This alarm could sample channelMatches or
   bufferControlCapturedPackets.  When the MS gets the rising event, it can
   begin polling for the captured packets (or other information) and stop
   when it receives the falling event.  When RFC1271 comes around for
   elevation to draft standard in roughly six months, I am going to lobby
   for us to deprecate the unstable packetMatch trap and it's associated
   logic and replace it with this mechanism.

I assume that you're talking about removing only the alwaysReady state - the
other two are required for synchronised packet trigger/capture.

   Steve

Thanks,
Robin

Robin Iddon ([e-mail])
Spider Systems Ltd
Edinburgh
Scotland