Ok, I think i finally found smthing to work with:

First of all a msg from dave i found here

"
Msg from Dave
http://www.mail-archive.com/[email protected]/msg16507.html

Bottom line:
    The username and engineID specified (either
implicitly or explicitly) by the sending application
must match the username and engineID specified
(implicitly or explicitly) by the receiving application.

For most requests (GET, GETNEXT, SET, and INFORM),
the receiving application will use a default engineID,
and the sending application will first probe to discover
the engine ID to use.   The effect that everything just
works, and you don't have to worry about engineID.

That's not the case with TRAP requests.   Such requests
are "non-acknowledged", so this engine probe mechanism
isn't used.

In this situation, the safest approach is to *explicitly* specify
the same engineID on both the sending side ("trapsess" in
snmpd.conf) and the receiving side ("createUser" in snmptrapd.conf)


Dave"

now to my statement:

> After a loot of testing ;) I understood that the agent, sending traps
> always takes the engineID of itself(so everytime you restart it a new one),
> never the engineID specified in the trapsess line...

Well, not totally correct: After monitoring the traffic with wireshark from the 
windows host(here net-snmp 5.5 is runnung), i noticed some differences between 
traps generated by restarting the snmpd and traps generated by snmptrap

1.) restarting the agent on the windows host generates traps.
If specified trapsess like
trapsess -v 3 -e 0x8000000001020304 -u snmpv3_SHA_authNoPriv_trap_dst6 -l 
authNoPriv -a SHA -A helloworld 10.16.10.193:162

then the specified engineID is taken for the contextEngineID. For the 
msgAuthorativeEngineID some different value is taken, so I think the engineID 
of the process itself I guess?
I think/tested the trapdeamon will listen to the msgAuthorativeEngineID to 
specifiy if the user has the correct ID or not.Correct?

After setting up the corresponding msgAuthorativeEngineID in the trapdeamon 
monitoring the traps of the agent worked fine, so i think thats correct.

So for the Trap generated by restarting the agent:

msgAuthoritativeEngineID: 80001F88801A5300006A516A4C00000000
contextEngineID:          8000000001020304

2.) sending traps with snmptrad

Interestingly enought if i tried to send snmptraps from the windows host the 
situation changes
If I use the command

snmptrap -v 3 -u snmpv3_SHA_authNoPriv_trap_dst6 -l authNoPriv -e 
0x8000000001020304 -a SHA -A helloworld 10.16.10.11 42 coldStart.0

Then the engineID specified in trapsess is used for msgAuthorativeEngineID and 
for the contextEngineID smth different is used

msgAuthoritativeEngineID: 8000000001020304
contextEngineID:          80001F8880CC2E00001BC1734C00000000


So to sum up from my point of view:

The engineID specified in trapsess command is used for the contextEngineID not 
for the msgAuthoritativeEngineID. Therefore one has to specify the 
msgAuthoritativeEngineID in the createUser command in snmptrapd.conf to monitor 
traps when restarted the agent. I did't montire how authentication failures 
behave, i hope i get to it in the evening.
If sending traps by the snmptrap command, the engineID specified by the command 
with option -e is used as msgAuthoritativeEngineID. In this case monitoring the 
traps works without any problem.

Has somebody made maybe the same experience? I hope that helps if a similar 
problem occurs to someone.
Can anybody tell if I am correct?

Markus
-------- Original-Nachricht --------
> Datum: Thu, 26 Aug 2010 09:53:34 +0200
> Von: "Markus Hofer" <[email protected]>
> An: "Markus Hofer" <[email protected]>, [email protected]
> Betreff: Re: trapsess problems

> Hi again
> 
> After a loot of testing ;) I understood that the agent, sending traps
> always takes the engineID of itself(so everytime you restart it a new one),
> never the engineID specified in the trapsess line...
> 
> To monitor the traps by the trapagent on a remote host, i have to create
> the user in the snmptrapd.conf file with a specific engineID.
> 
> But when the engineID is always different after restarting, how can I
> monitor traps then? Then I have to reconfigure every time i restart the
> agnent?? Or do I understand smthng wrong there? I really would appreciate some
> help!!
> 
> Regards
> Markus
> 
> BTW:A manual for trapsess would be really fine!
> 
> 
> 
> > Now I got the following question
> > 
> > When defining 
> > trapsess like this
> > 
> > createUser -e 0x8000000001020304 snmpv3_SHA_authNoPriv_trap_dst1 SHA
> > helloworld
> > 
> > and
> > 
> > trapsess -v 3 -u snmpv3_SHA_authNoPriv_trap_dst2 -l authNoPriv -a SHA -A
> > helloworld 10.16.10.11:162 
> > 
> > Again I used some dummy engineID
> > Does the generated trap by restarting the agent take the engineID I have
> > specified?
> > 
> > The trap agent running on the target host says
> > 
> > 
> > usm: usm: USM processing begun...
> > USM processing begun...
> > usm: usm: match on user snmpv3_SHA_authNoPriv_trap_dst2
> > match on user snmpv3_SHA_authNoPriv_trap_dst2
> > usm: usm: no match on engineID (no match on engineID (80 00 1F 88 80 6C
> 97
> > 72 D6 00 15 37 CB 80 00 1F 88 80 6C 97 72 D6 00 15 37 CB )
> > )
> > usm: usm: Unknown User(snmpv3_SHA_authNoPriv_trap_dst2)
> > Unknown User(snmpv3_SHA_authNoPriv_trap_dst2)
> > 
> > so i don't think so? How can I configure trapsess in such a way that the
> > traps would be recognized by the trap agent correctly?
> > 
> > On the agent side I have configured snmptrad.conf like:
> > 
> > createUser -e 0x8000000001020304 snmpv3_SHA_authNoPriv_trap_dst2 SHA
> > "helloworld"
> > authUser log snmpv3_SHA_authNoPriv_trap_dst2 authNoPriv
> > 
> > and started the agent by
> > 
> >  snmptrapd -Dusm -f -C -c /etc/snmp/snmptrapd.conf -Le
> > 
> > 
> > so snmptraps generated by 
> > 
> > snmptrap -v 3 -u snmpv3_SHA_authNoPriv_trap_dst2 -l authNoPriv -e
> > 0x8000000001020304 -a SHA -A helloworld 10.16.10.11 42 coldStart.0
> > 
> > are recoginzed without any problems.
> > 
> > Would appreciate some help
> > 
> > Regards
> > 
> > Markus
> > 
> > -------- Original-Nachricht --------
> > > Datum: Tue, 24 Aug 2010 14:39:13 +0200
> > > Von: "Markus Hofer" <[email protected]>
> > > An: "Markus Hofer" <[email protected]>,
> > [email protected]
> > > Betreff: Re: trapsess problems
> > 
> > > 
> > > > I thought about if creating a user in the same config file would
> help,
> > > but
> > > > cleary that does not make sense since the other trapsess definition
> > > works
> > > > fine without any problems.
> > > 
> > > Ok. Here I am totally wrong. I need to create a user in snmpd.conf
> like
> > > 
> > > createUser snmpv3_SHA_authNoPriv_trap_dst2 SHA helloworld
> > >  
> > > in order to make things work. Now i get traps without any problem
> > > 
> > > But still the question: Why does sending traps work without engineID
> if
> > i
> > > don't create a user like above?
> > > 
> > > Regards
> > > -- 
> > > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
> > > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
> > 
> > -- 
> > Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
> > jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
> 
> -- 
> Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
> jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
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

Reply via email to