[AGENT++] Traps

Chaim Turkel - Israel ChaimT at gilat.com
Sun Dec 4 13:21:15 CET 2005 

Yes I used a sniffer and saw the messages go out, but not come in.
How do I turn off the logging?

Chaim Turkel

-----Original Message-----
From: MFehde at t-online.de [mailto:MFehde at t-online.de] 
Sent: Sunday, December 04, 2005 2:18 PM
To: Chaim Turkel - Israel; agentpp at agentpp.org
Subject: Re: [AGENT++] Traps

If I get you right then your trap messages are sent, but they got lost
at the receiver side. Did you verify this with a network analyzer (e.g.
Packetyzer)?
I assume that you used different SNMP implementations for .NET and
Delphi, didn't you?
Did you try to switch of (on-screen) logging of SNMP/Agent++. This takes
a lot of time and slows down message processing significantly.
This would be a hint for loosing message due to an overrun in the socket
queue. Your UDP socket has a limited queue size and if it is exceeded
further incoming messages are discarded.
You should have a look at the getsockopt system call of the Win32 API.
This may enable you to retrieve the size of your in-buffer.
If you send ~50 messages per second with a size ~100 bytes (depending on
the included variable bindings) you may exceed the buffer size fast.

-Marcus


-----Original Message-----
> Date: Sun,  4 Dec 2005 12:17:41 +0100
> Subject: RE: [AGENT++] Traps
> From: "Chaim Turkel - Israel" 
> To: , 

> I am currently working on a way to pass the information via ftp, and
> only notifications via snmp to let me know that it is updated.
> The issue that I am writing here, is that I checked this issue (of
> receiving traps) with three different code engines (one in c++
> (snmp++), dotnet and Delphi). In all of them I found the same problem,
> but was able to overcome it by moving all information to a different
> thread. For example if I did nothing but count the traps all was ok
> (the problem was in the processing on the same thread of the socket).
> In the c++ version, even if I did nothing I count not keep up with the
> traps. So I wanted to know why is there so much processing in the
> snmp++ engine for the trap on the same thread as the socket.
> 
> Thank for all your help.
> 
> Chaim Turkel
> 
> 
> -----Original Message-----
> From: MFehde at t-online.de [mailto:MFehde at t-online.de]
> Sent: Sunday, December 04, 2005 11:46 AM
> To: Chaim Turkel - Israel; agentpp at agentpp.org
> Subject: Re: [AGENT++] Traps
> 
> Hi Chaim,
> 
> could this be a multithreading issue or a socket overrun, because of
> too slow message processing? Since SNMP bases on UDP you wouldn't get
> notice of this.
> Anyway, I don't know neither whether the problem occurs at the manager
> or agent side nor do I know your application at all.
> This is always my problem, too, when I'm trying to get adequate
> answers to my questions. We're using the SNMP protocol only for
> company specific application  s without involving 3rd parties. So we
> use the protocol sometimes a little bit different as, for instance,
> network
> administrators are used to. Even though we do not harm the standard,
> but it leads sometimes to misunderstandings. This was also the reason
> why I suggested that you should not trying to make a denial of service
> attack by emitting a high volumn of traps:)
> We developed a remote service system for medical applications using
> the SNMP.
> 
> Even though I don't know your application I suggest to think about
> having a table listing all your events and sending only one trap for
> notifying your manager (trap directed pollig). The manager reads out
> the table and gets informed about all events. Additionally you could
> have a column in your table that is used by the manager to confirm
> each processed event. This enables you to detect whether the manager
> received your traps or if the message got lost.
> 
> Regards,
> Marcus
> 
> 
> -----Original Message-----
> 
> > Date: Sun,  4 Dec 2005 08:07:46 +0100
> > Subject: RE: [AGENT++] Traps
> > From: "Chaim Turkel - Israel"
> > To:
> 
> > 
> > My current system uses the traps to notify my application on
> > internal component changes. The majority of the times there is no
> > problem. When the whole system reboots, that is when I get massive
> > notifications of internal objects (50 a sec).
> > I have tested traps in c++ (snmp++) dotNet and Delphi. All of them
> > drop, but once I moved all messages to a different thread then it
> > works fine. Though in the c++ it does not work. All my code does is
> > to count the traps and I still loose packets. This means that snmp++
> > is doing to much processing on the dequeue. Is there a way to move
> > all traffic on the dequeue to a different thread?
> > Chaim Turkel
> > 
> > 
> > -----Original Message-----
> > From: agentpp-bounces at agentpp.org
> > [mailto:agentpp-bounces at agentpp.org] On Behalf Of
> > agentpp-request at agentpp.org Sent: Saturday, December 03, 2005 1:58
> > PM
> > To: agentpp at agentpp.org
> > Subject: AGENTPP Digest, Vol 23, Issue 3
> > 
> > Send AGENTPP mailing list submissions to
> > agentpp at agentpp.org
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.agentpp.org/mailman/listinfo/agentpp
> > or, via email, send a message with subject or body 'help' to
> > agentpp-request at agentpp.org
> > 
> > You can reach the person managing the list at
> > agentpp-owner at agentpp.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of AGENTPP digest..."
> > 
> > 
> > Today's Topics:
> > 
> > 1. RE: Traps (James McDonnell)
> > 2. RE: Traps (Fehde, Marcus)
> > 3. Re: Response to wrong snmpEngineId (Jochen Katz)
> > 4. Re: Response to wrong snmpEngineId (MFehde at t-online.de)
> > 
> > 
> >
----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Fri, 2 Dec 2005 09:34:40 -0500
> > From: "James McDonnell"
> > Subject: RE: [AGENT++] Traps
> > To:
> > Message-ID: <008401c5f74d$88375fc0$262810ac at office.slipstream.net>
> > Content-Type: text/plain;	charset="us-ascii"
> > 
> > 
> > Have you tried using informs instead of notifies?  Informs require
> > acknowledgement.  If acknowledgement isn't received, the trap
> > generator is suppose to re-send the inform.
> > 
> > -----Original Message-----
> > From: agentpp-bounces at agentpp.org
> > [mailto:agentpp-bounces at agentpp.org] On Behalf Of Chaim Turkel -
> > Israel
> > Sent: December 2, 2005 4:15 AM
> > To: agentpp at agentpp.org
> > Subject: [AGENT++] Traps
> > 
> > I have found that when sending a very high volume of traps, if the
> > processing of the trap is to high then traps are dropped (I assume
> > on the socket level). I have seen this on multiple trap applications
> > (code). The solution to this is to dequeue all traps to another
> > thread so that all processing does not occure on the thread of the
> > socket.
> > Is there a way to solve this in snmp++ since the internal processing
> > is to high and even if I do nothing but count the traps, some get
> > dropped?
> > Chaim Turkel
> > _______________________________________________
> > AGENTPP mailing list
> > AGENTPP at agentpp.org
> > http://lists.agentpp.org/mailman/listinfo/agentpp
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 2
> > Date: Fri, 2 Dec 2005 15:43:57 +0100
> > From: "Fehde, Marcus"
> > Subject: RE: [AGENT++] Traps
> > To: "James McDonnell" ,
> > 
> > Message-ID:
> > 
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > Are you planning to implement a denial of service attack? What is
> > you definition of a "very high volume"?
> > 
> > You should use traps only for rising alarms and for getting the
> > attention of a management station (called trap directed polling).
> > Furthermore Inform-message are critical and can flood a network,
> > particularly because they have to be acknowledged by the server and
> > they're re-send if either the request or the response got lost. Even
> > though Inform-messages can be sent by agents they should be only
> > sent between management stations.
> > 
> > Regards,
> > Marcus
> > 
> > -----Original Message-----
> > From: agentpp-bounces at agentpp.org
> > [mailto:agentpp-bounces at agentpp.org] On Behalf Of James McDonnell
> > Sent: Freitag, 2. Dezember 2005 15:35
> > To: agentpp at agentpp.org
> > Subject: RE: [AGENT++] Traps
> > 
> > 
> > 
> > Have you tried using informs instead of notifies?  Informs require
> > acknowledgement.  If acknowledgement isn't received, the trap
> > generator is suppose to re-send the inform.
> > 
> > -----Original Message-----
> > From: agentpp-bounces at agentpp.org
> > [mailto:agentpp-bounces at agentpp.org] On Behalf Of Chaim Turkel -
> > Israel
> > Sent: December 2, 2005 4:15 AM
> > To: agentpp at agentpp.org
> > Subject: [AGENT++] Traps
> > 
> > I have found that when sending a very high volume of traps, if the
> > processing of the trap is to high then traps are dropped (I assume
> > on the socket level). I have seen this on multiple trap applications
> > (code). The solution to this is to dequeue all traps to another
> > thread so that all processing does not occure on the thread of the
> > socket. Is there a way to solve this in snmp++ since the internal
> > processing is to high and even if I do nothing but count the traps,
> > some get dropped?
> > Chaim Turkel
> > _______________________________________________
> > AGENTPP mailing list
> > AGENTPP at agentpp.org
> > http://lists.agentpp.org/mailman/listinfo/agentpp
> > _______________________________________________
> > AGENTPP mailing list
> > AGENTPP at agentpp.org
> > http://lists.agentpp.org/mailman/listinfo/agentpp --------------
> > next part --------------
> > Important Note
> > This e-mail message may contain confidential and/or privileged
> > information. If you are not an addressee or otherwise authorized to
> > receive this message, you should not use, copy, disclose or take any
> > action based on this e-mail or any information contained in the
> > message. If you have received this material in error, please advise
> > the sender immediately by reply e-mail and delete this message.
> > Thank you.
> > 
> > Wichtiger Hinweis
> > Diese E-Mail und etwaige Anlagen koennen Betriebs- oder
> > Geschaeftsgeheimnisse oder sonstige vertrauliche Informationen
> > enthalten. Sollten Sie diese E-Mail irrtuemlich erhalten haben, ist
> > Ihnen dieser Umstand hiermit bekannt. Bitte benachrichtigen Sie uns
> > in diesem Fall umgehend durch Ruecksendung der E-Mail und loeschen
> > Sie diese E-Mail einschließlich etwaiger Anlagen von Ihrem System.
> > Diese E-Mail und ihre Anlagen duerfen weiterhin nicht kopiert oder
> > an Dritte weitergegeben werden. Vielen Dank.
> > 
> > ------------------------------
> > 
> > Message: 3
> > Date: Sat, 03 Dec 2005 01:33:22 +0100
> > From: Jochen Katz
> > Subject: Re: [AGENT++] Response to wrong snmpEngineId
> > To: Agent++ Mailing List
> > Message-ID: <4390E7D2.2050300 at 2004.joka.homelinux.org>
> > Content-Type: text/plain; charset=us-ascii
> > 
> > Hi,
> > 
> > 
> > 
> > > Accordingly to RFC3414, ch. 3.2, 3) the agent should return a
> > > REPORT-PDU containing the varbind usmUnknownEngineId.
> > > As far as I've analyzed the code this does not happen. There are
> > > (at least) two places where the engineId is checked.
> > > One is in USM::process_msg where usm_time_table->check_time() is
> > > called. Surprisingly for me, this method succeeds.
> > > 
> > > 
> > 
> > possibly the USM is in discovery mode, so it accepts all engine ids.
> > But what I really want to know: Why does the manager send a message
> > with a wrong engine id?
> > 
> > 
> > 
> > > The second check of the engineId is done in v3MP::snmp_parse
> > 
> > > ...
> > > if (!(unsignedCharCompare(securityEngineID.data(),
> > securityEngineID.len(),
> > > own_engine_id, own_engine_id_len))) {
> > > debugprintf(0, "snmp_parse: securityEngineID doesn't match
> > own_engine_id.");
> > > usm->delete_sec_state_reference(securityStateReference);
> > > return SNMPv3_MP_MATCH_ERROR;
> > > ...
> > 
> > > But this check seems only to force the PDU to be discarded, but
> > > without sending a REPORT.
> > > 
> > 
> > This is because of rfc 3412 page 36/37:
> > 13) If the pduType is from the Confirmed Class, then:
> > 
> > a) If the value of securityEngineID is not equal to the value of
> > snmpEngineID, then the security state information is
> > discarded, any cached information about this message is
> > discarded, the incoming message is discarded without further
> > processing, and a FAILURE result is returned.  SNMPv3 Message
> > Processing is complete.
> > 
> > Looking at the USM rfc 3414 pages 27:
> > 3)  If the value of the msgAuthoritativeEngineID field in the
> > securityParameters is unknown then:
> > 
> > a) a non-authoritative SNMP engine that performs discovery may
> > optionally create a new entry in its Local Configuration
> > Datastore (LCD) and continue processing;
> > 
> > or
> > 
> > b) the usmStatsUnknownEngineIDs counter is incremented, and an error
> > indication (unknownEngineID) together with the OID and
> > value of the incremented counter is returned to the calling
> > module.
> > 
> > Note in the event that a zero-length, or other illegally sized
> > msgAuthoritativeEngineID is received, b) should be chosen to
> > facilitate engineID discovery.  Otherwise the choice between a) and
> > b) is an implementation issue.
> > 
> > The decission between a) and b) is impossible at this time because
> > the entity does not know the pdu type and so cannot decide if the
> > entity is authoritative or not. snmp++ currently uses only the flag
> > discovery-mode to decide.
> > 
> > Regards,
> > Jochen
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 4
> > Date: Sat,  3 Dec 2005 10:04:11 +0100
> > From: "MFehde at t-online.de"
> > Subject: Re: [AGENT++] Response to wrong snmpEngineId
> > To: "Jochen Katz" ,	"Agent++ Mailing List"
> > 
> > Message-ID: <1EiTJT-1eXJgm0 at fwd32.aul.t-online.de>
> > Content-Type: text/plain; charset="ISO-8859-1"
> > 
> > Hi Jochen,
> > 
> > our SNMP agent changes its engineId on each startup to an arbitrary
> > one.
> > 
> > This enables us to detect the exchange of an entity without further
> > communication which is important for our application.
> > The SNMP manager is communicating with the agent and is not aware of
> > the
> > exchange. This leads to the situation.
> > This would explain why the agent could be in discovery mode. On the
> > other hand I steped through the code and did not see any hint for
> > being in discovery mode.
> > 
> > Can you tell me whether we should get a timeout or a
> > "unknownEngineId" report?
> > 
> > Thanks for your help,
> > Marcus
> > -----Original Message-----
> > 
> > 
> > > Date: Sat,  3 Dec 2005 01:33:22 +0100
> > > Subject: Re: [AGENT++] Response to wrong snmpEngineId
> > > From: Jochen Katz
> > > To: Agent++ Mailing List
> > 
> > > Hi,
> > > 
> > > > Accordingly to RFC3414, ch. 3.2, 3) the agent should return a
> > > > REPORT-PDU containing the varbind usmUnknownEngineId.
> > > > As far as I've analyzed the code this does not happen. There are
> > > > (at least) two places where the engineId is checked.
> > > > One is in USM::process_msg where usm_time_table->check_time() is
> > > > called. Surprisingly for me, this method succeeds.
> > > > 
> > > > 
> > > > 
> > > 
> > > possibly the USM is in discovery mode, so it accepts all engine
> > > ids.
> > > But what I really want to know: Why does the manager send a
> > > message with a wrong engine id?
> > > 
> > > 
> > > 
> > > 
> > > > The second check of the engineId is done in v3MP::snmp_parse 
> > > 
> > > > ...
> > > > if (!(unsignedCharCompare(securityEngineID.data(),
> > > securityEngineID.len(),
> > > > own_engine_id, own_engine_id_len))) {
> > > > debugprintf(0, "snmp_parse: securityEngineID doesn't match
> > > own_engine_id.");
> > > > usm->delete_sec_state_reference(securityStateReference);
> > > > return SNMPv3_MP_MATCH_ERROR;
> > > > ...
> > > 
> > > > But this check seems only to force the PDU to be discarded, but
> > > > without sending a REPORT.
> > > > 
> > > > 
> > > 
> > > This is because of rfc 3412 page 36/37:
> > > 13) If the pduType is from the Confirmed Class, then:
> > > 
> > > a) If the value of securityEngineID is not equal to the value of
> > > snmpEngineID, then the security state information is
> > > discarded, any cached information about this message is
> > > discarded, the incoming message is discarded without further
> > > processing, and a FAILURE result is returned.  SNMPv3 Message
> > > Processing is complete.
> > > 
> > > Looking at the USM rfc 3414 pages 27:
> > > 3)  If the value of the msgAuthoritativeEngineID field in the
> > > securityParameters is unknown then:
> > > 
> > > a) a non-authoritative SNMP engine that performs discovery may
> > > optionally create a new entry in its Local Configuration
> > > Datastore (LCD) and continue processing;
> > > 
> > > or
> > > 
> > > b) the usmStatsUnknownEngineIDs counter is incremented, and an
> > > error indication (unknownEngineID) together with the OID and
> > > value of the incremented counter is returned to the calling
> > > module.
> > > 
> > > Note in the event that a zero-length, or other illegally sized
> > > msgAuthoritativeEngineID is received, b) should be chosen to
> > > facilitate engineID discovery.  Otherwise the choice between a)
> > > and b) is an implementation issue.
> > > 
> > > The decission between a) and b) is impossible at this time because
> > > the entity does not know the pdu type and so cannot decide if the
> > > entity is authoritative or not. snmp++ currently uses only the
> > > flag discovery-mode to decide.
> > > 
> > > Regards,
> > > Jochen
> > > 
> > > _______________________________________________
> > > AGENTPP mailing list
> > > AGENTPP at agentpp.org
> > > http://lists.agentpp.org/mailman/listinfo/agentpp
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > ------------------------------
> > 
> > _______________________________________________
> > AGENTPP mailing list
> > AGENTPP at agentpp.org
> > http://lists.agentpp.org/mailman/listinfo/agentpp
> > 
> > 
> > End of AGENTPP Digest, Vol 23, Issue 3
> > **************************************
> > 
> > 
> > _______________________________________________
> > AGENTPP mailing list
> > AGENTPP at agentpp.org
> > http://lists.agentpp.org/mailman/listinfo/agentpp
> 
> 
> 
> 
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/agentpp

More information about the AGENTPP mailing list