2009/8/21 Wes Hardaker
>
> [CCing the -coders list again; please keep conversations on the list]
>
> > On Fri, 21 Aug 2009 11:45:38 -0400, Daniel Savard <
> [email protected]> said:
>
> DS> I did preliminary work and found that the old SMIv1 traps definitions
> are
> DS> ignored by the
2009/9/4 Scott Grumm :
> I need to support a SNMP client that does not understand the SMIv2
> NOTIFICATION-TYPE.
> Should I create a separate MIB for that client that
> uses TRAP-TYPE
If this client cannot handle current standards, then yes.
that's probably what you'll have to do. SMIv2 h
I
need to support a SNMP client that does not understand the SMIv2
NOTIFICATION-TYPE. I've loaded the MIB in and it does not recognize it
as an event it can register but it does handle TRAP-TYPE. I assumed
that I was doing something wrong and needed to have MIBS with both the
NOTIFICATION-TYP
Hi All,
I have a doubt about the below function
1. Does [ user nanoName[] = "" ] is valid user
name ?
2. If not why does it is assigned it to "name" ?
3. I think if "char *name" received as NULL, Then instead of
assigning to null character and looping ,
It will bette
2009/9/4 Scott Grumm :
> I am trying to send both v1 and v2c traps and am having problems figuring
> out the right way to do it.
>
> Originally I thought that I should have two MIBs, one with a TRAP-TYPE
> definition and one with a NOTIFICATION-TYPE definition.
No.
The version of SMI used to defin
I am trying to send both v1 and v2c traps and am having problems
figuring out the right way to do it.
Originally
I thought that I should have two MIBs, one with a TRAP-TYPE definition
and one with a NOTIFICATION-TYPE definition. I then made calls to
send_trap_vars() and send_v2trap() figurin
