[AGENT++] Traps
Chaim Turkel - Israel
ChaimT at gilat.com
Sun Dec 4 12:17:41 CET 2005
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
More information about the AGENTPP
mailing list