[AGENT++] Traps
Chaim Turkel - Israel
ChaimT at gilat.com
Sun Dec 4 08:07:46 CET 2005
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" <jmcdonnell at slipstream.com>
Subject: RE: [AGENT++] Traps
To: <agentpp at agentpp.org>
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" <Marcus.Fehde at draeger.com>
Subject: RE: [AGENT++] Traps
To: "James McDonnell" <jmcdonnell at slipstream.com>,
<agentpp at agentpp.org>
Message-ID:
<A8E0CBAC9F9AFD4D94DE492866A1855C01679130 at mdemxs02.de.draeger.com>
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 <katz at agentpp.com>
Subject: Re: [AGENT++] Response to wrong snmpEngineId
To: Agent++ Mailing List <agentpp at agentpp.org>
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" <MFehde at t-online.de>
Subject: Re: [AGENT++] Response to wrong snmpEngineId
To: "Jochen Katz" <katz at agentpp.com>, "Agent++ Mailing List"
<agentpp at agentpp.org>
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
**************************************
More information about the AGENTPP
mailing list