[AGENT++] Traps
Chaim Turkel - Israel
ChaimT at gilat.com
Sun Dec 4 14:19:24 CET 2005
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