[AGENT++] Traps
MFehde at t-online.de
MFehde at t-online.de
Sun Dec 4 14:36:39 CET 2005
This is not that big, even though genrally sufficient. But considering
the message size and amount of message it can explain the issue.
Did you saw in the analyzer the size of a single message?
Did you have any success with disabling the logging?
Is it possible that you slow down the trap generation, just for testing?
Do you know whether random message got lost, both one of the first
message sent and also one that was sent later in the sequence, or only
those which were sent later? This would be also an indicator for an
overrun, even though you must also consider your event processing.
-Marcus
-----Original Message-----
> Date: Sun, 4 Dec 2005 14:19:24 +0100
> Subject: RE: [AGENT++] Traps
> From: "Chaim Turkel - Israel"
> To: ,
> The buffer size is 8192.
>
> Chaim
>
>
> -----Original Message-----
> From: MFehde at t-online.de [mailto:MFehde at t-online.de]
> Sent: Sunday, December 04, 2005 2:34 PM
> To: Chaim Turkel - Israel; agentpp at agentpp.org
> Subject: Re: [AGENT++] Traps
>
> There's a define in config_snmp_pp.h the disables logging.
> Did you already determine your socket buffer size?
>
> -Marcus
>
> -----Original Message-----
> > Date: Sun, 4 Dec 2005 13:21:15 +0100
> > Subject: RE: [AGENT++] Traps
> > From: "Chaim Turkel - Israel"
> > To: ,
>
> > 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