On systems with 32 bit time_t the engineID produced in setup_engineID
(snmpv3.c) with ENGINEID_TYPE_NETSNMP_RND is 13 bytes long.
Systems with a time_t, that is 64 bits wide, will produce an engineID with a
length of 17 bytes. The additional 4 bytes are all 0 and will be for approx.
the next 90
> On Fri, 25 Feb 2011 19:46:37 +0530, Manjit
> said:
M> What is the purpose for a permanent row, is it to have a just backup or
M> the snmp application should
M> start using these backup data ??
Net-SNMP only has rows that are created via incoming SETs marked as
"non-volatile". Any ot
also changing the
> M> SnmpEngineID.
>
> Means you're going to completely lose the point of having the row
> persistent in the first place. If the EngineID is always changing then
> the old users will not be useful so there is really no point in keeping
> them arou
hanging the
M> SnmpEngineID.
Means you're going to completely lose the point of having the row
persistent in the first place. If the EngineID is always changing then
the old users will not be useful so there is really no point in keeping
them around in the first place!
Why are you genera
EngineProperty will be new.( A new EngineID and a EngineBoot = 0 )
My question : Is the Permanent value of usmUserTable row have any
dependency on EngineID.
Or is it like the backup of usmUserTable row should be taken only in the
case when the engine will have the same engineID and EngineBoot will
On 10 December 2010 05:24, Wes Hardaker wrote:
> This is cleaner and clearer so I'm fine with
> applying it for 5.6.1.
+1
Dave
--
___
Net-snmp-coders mailing list
Net-snmp-cod
On Thu, Dec 09, 2010 at 09:24:36PM -0800, Wes Hardaker wrote:
> This is cleaner and clearer so I'm fine with
> applying it for 5.6.1.
+1
/Niels
--
Niels Baggesen - @home - Århus - Denmark - [email protected]
The purpose of computing is insight, not numbers --- R W Hamming
usm.c
+++ b/net-snmp/snmplib/snmpusm.c
@@ -3127,7 +3127,11 @@ usm_get_user_from_list(u_char * engineID, size_t
engineIDLen,
memcmp(ptr->engineID, engineID, engineIDLen) == 0)))
return ptr;
DEBUGMSGTL(("usm", "no match on engineID ("))
>>>>> On Thu, 27 May 2010 10:54:25 +0530, Tony Thomas
>>>>> said:
TT> [Tony] Did you mean use a known engineID for subagent? The system
TT> has many elements, each containing a subagent. As a solution to this
TT> problem, I tried to use a known common eng
ement to use an explicitly specified engineID
<< when sending traps, and configure snmptrapd with users that
<< also specify the same engineID.
[Tony] Did you mean use a known engineID for subagent? The system has many
elements, each containing a subagent. As a solution to
>>>>> On Wed, 26 May 2010 16:14:19 +0530, Tony Thomas
>>>>> said:
TT> As per system requirements, the new element must be added to system
TT> without user intervention (not possible to manually configure the
TT> engineID in master element).
Dave's
On 26 May 2010 11:44, Tony Thomas wrote:
> In my system, when a new element is added to the network, the subagent in it
> sends a notification (V3 trap) to the master agent in the network using its
> unique engineID. As per the tutorial, I understand that the snmptrapd.conf
> sho
- user details with engineID details should be configured in snmptrapd.conf
to receive SNMP v3 trap.
In my system, when a new element is added to the network, the subagent in it
sends a notification (V3 trap) to the master agent in the network using its
unique engineID. As per the tutorial, I
>>>>> On Wed, 15 Apr 2009 13:32:37 +0800, Kang Chen
>>>>> said:
KC> When I want to receive a v3 trap using snmptrapd, I must assign the same
KC> engineid both in snmpd.conf and snmptrapd.conf.
KC> But, if I use MG-SOFT mibbrowser to receive the v3 trap, I
Hi, Dave
I find a difference between the snmptrapd and the third party tools like
MG-SOFT mibbrowser.
When I want to receive a v3 trap using snmptrapd, I must assign the same
engineid both in snmpd.conf and snmptrapd.conf.
But, if I use MG-SOFT mibbrowser to receive the v3 trap, I need not
On Jan 20, 2008 12:42 PM, Thomas Anders <[EMAIL PROTECTED]> wrote:
> My gut feeling would be to extend the existing engineIDType/engineID
> functionality to cover that, i.e. to introduce a new engine ID type 4
> (raw).
>
> Whatever way you prefer, please submit your
-SNMP release?
My gut feeling would be to extend the existing engineIDType/engineID
functionality to cover that, i.e. to introduce a new engine ID type 4 (raw).
Whatever way you prefer, please submit your final patch to
http://www.net-snmp.org/patches so it won
On Jan 18, 2008 3:45 PM, Dave Shield <[EMAIL PROTECTED]> wrote:
> On 18/01/2008, Nathan Schrenk <[EMAIL PROTECTED]> wrote:
> >there is no way to
> > specify the engineID exactly. I'd like to be able to configure the
> engineID
On 18/01/2008, Nathan Schrenk <[EMAIL PROTECTED]> wrote:
>there is no way to
> specify the engineID exactly. I'd like to be able to configure the engineID
> using a command that just takes the hex-encoded raw engineID, similar to the
> oldE
Hi,
I'm working on a project to include an SNMP agent based on NET-SNMP's snmpd
in an ethernet switch. The switch's command-line interface provides the
ability to specify the SNMP agent's engineID. This is somewhat problematic
with NET-SNMP (at least as of version 5.4.1) bec
with each potential
notification generator.
Actually, when the agent reads the trapsess token in the config file it
creates a session for that specific manager. If the trapsess token is
indicating that the manager will receive informs, the agent discovers
the manager's engineID. It does that synchron
wrote:
>> There are two scenarios, that I am thinking, when the agent can trigger
>> a discovery.
>>
>> 1) When the session is opened.
>> 2) When an inform is about to be sent and the session engineID is NULL.
>>
>> For the first option, to make the discover
On 09/05/07, Passera Pablo-APP015 <[EMAIL PROTECTED]> wrote:
> There are two scenarios, that I am thinking, when the agent can trigger
> a discovery.
>
> 1) When the session is opened.
> 2) When an inform is about to be sent and the session engineID is NULL.
>
> For th
On Wed, 9 May 2007 11:33:04 -0400 Passera wrote:
PPA> There are two scenarios, that I am thinking, when the agent can trigger
PPA> a discovery.
PPA>
PPA> 1) When the session is opened.
PPA> 2) When an inform is about to be sent and the session engineID is NULL.
PPA>
PPA> For
Dave, thanks for your answer.
There are two scenarios, that I am thinking, when the agent can trigger
a discovery.
1) When the session is opened.
2) When an inform is about to be sent and the session engineID is NULL.
For the first option, to make the discovery asynchronously does not
seems to
On 08/05/07, Passera Pablo-APP015 <[EMAIL PROTECTED]> wrote:
> Did someone try to modify the code to do engineID discovery
> asynchronously?
Not so far. Be our guest
> Is there a some reason why the discovery is being done synchronously?
a) It's a lot eas
receive requests from any other sessions (like port 161).
Did someone try to modify the code to do engineID discovery
asynchronously? Is there a some reason why the discovery is being done
synchronously?
Thanks in advance,
Pablo
TECTED] On
Behalf Of Dave Shield
Sent: Tuesday, February 27, 2007 1:28 AM
To: Makavy, Erez (Erez)
Cc: Wes Hardaker; [email protected]
Subject: Re: Disabling engineID Probe for Informs
On 26/02/07, Makavy, Erez (Erez) <[EMAIL PROTECTED]> wrote:
> It then seems that th
On 26/02/07, Makavy, Erez (Erez) <[EMAIL PROTECTED]> wrote:
> It then seems that the only solution for supporting informs in a
> "firewalled" system, is to use a fixed port (or range of ports) as
> the source port for the sent informs,
For a TCP-based transport, this sort of response to an outgoin
Makavy, Erez (Erez) wrote:
> Hi,
>
> It then seems that the only solution for supporting informs in a
> "firewalled" system,
> is to use a fixed port (or range of ports) as the source port for the
> sent informs,
> so that the returned acknowledgements can be accepted (by adding rule to
> the fire
---Original Message-
From: Makavy, Erez (Erez)
Sent: Monday, February 26, 2007 6:55 PM
To: 'Wes Hardaker'
Cc: [email protected]
Subject: RE: Disabling engineID Probe for Informs
Hi,
It then seems that the only solution for supporting informs in a
"firewalled"
es the SNMP message ID to correlate the ACK to the
inform.
thanks,
Erez.
-Original Message-
From: Wes Hardaker [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 12:37 AM
To: Makavy, Erez (Erez)
Cc: [email protected]
Subject: Re: Disabling engineID Probe for In
>>>>> "EM" == Erez Makavy writes:
EM> Before an inform is sent, an automatic engineID probe is sent to the
EM> manager-station,
EM> because of the firewall blocking unknown incoming UDP port,
EM> the probe response is not received, and the inform is not sent
Dave Shield wrote:
> Update of /cvsroot/net-snmp/net-snmp/snmplib
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv28753
>
> Modified Files:
> snmp_parse_args.c tools.c
> Log Message:
> CHANGES: library: BUG: 1660061: Validate engineIDs more strictly.
In the light of this, why do we
Hi,
Problem:
-
Sending Informs (using the snmpNotificationMIB, and snmpTargetMIB) does
not work when firewall is active.
[Version: Net-Snmp-5.3.1, Linux , PPC]
Analysis:
-
Before an inform is sent, an automatic engineID probe is sent to the
manager-station,
because of
e
JS> SNMP implementation does to produce a value.
FYI Juergen,
The Net-SNMP package has a 3rd-party mechanism for generating
engineIDs specifically to avoid the above problems (and in fact, we
did get reports of real-world collisions when we were using the IPv4
engineID derivation; we haven&
>>>>> "DS" == Dave Shield <[EMAIL PROTECTED]> writes:
>> When do we need to set engineID?
DS> I've no idea. Wes is the security expert, not me :-)
DS> In general, unless you *know* that you need to set the engineID
DS> explicitly, then you
On Thu, Feb 01, 2007 at 09:17:55AM +, Dave Shield wrote:
> > When do we need to set engineID?
>
> I've no idea. Wes is the security expert, not me :-)
RFC 3411 contains the definition of the SnmpEngineID textual
convention which explains the various formats. In a nutshell
On 31/01/07, redhouse101 <[EMAIL PROTECTED]> wrote:
> When do we need to set engineID?
I've no idea. Wes is the security expert, not me :-)
In general, unless you *know* that you need to set the engineID
explicitly, then you probably don't (a
Thank you very much, Dave!
When do we need to set engineID? In man page, it states that we can set
"engineID STRING" in snmpd.conf. Which snmpd.conf, persistent one or regular
one?
RH
On 1/31/07, Dave Shield <[EMAIL PROTECTED]> wrote:
DS> The engine ID is normally set aut
On 31/01/07, redhouse101 <[EMAIL PROTECTED]> wrote:
> In using SNMPv3, where should engineID set?
The engine ID is normally set automatically when the agent first
starts up. This is then saved (again automatically) in the persistent
snmpd.conf file.
> In my testing, I have not
Hi, experts,
In using SNMPv3, where should engineID set? in persistent snmpd.conf or
regular snmpd.conf?
In my testing, I have not set any, it still works. Does this an optional
configuration?
Thank you very much,
RH
On Thu, 15 Sep 2005 21:56:43 -0700 Wes wrote:
WH> The new delayed engineID probing scheme actually enforces a USM probe
WH> before anything else takes place. EG, if you run snmpget with a
WH> different security model (eg, ksm) it forces a USM-based-packet
WH> engineID probe to happen
in spite of this error.
> Does this mean that this is an expected result and I shouldn't
> worry about it?
Yes - that's fine.
It's probably related to the automatic engineID discovery,
which is (sometimes) done when the session is first opened.
Don't you worry your p
Hello there,
I am
developing a snmp client using snmp version 3. After the snmp_open, the
session variable that is returned has its s_snmp_errno element set to
SNMPERR_UNKNOWN_ENG_ID. I took a look at the snmpv3_engine_ID_probe
function, which is the one that throws this error a
The new delayed engineID probing scheme actually enforces a USM probe
before anything else takes place. EG, if you run snmpget with a
different security model (eg, ksm) it forces a USM-based-packet
engineID probe to happen first which I'm sure it didn't use to do (nor
should it)
On Wed, 20 Apr 2005 09:20:55 +0100 Dave wrote:
DS> On Tue, 2005-04-19 at 18:18, Wes Hardaker wrote:
DS> > 5) thus, I would choose one of:
DS> >a) have the new behaviour to probe later with a new flag to probe
DS> >immed.
DS>
DS> Well, we've already got a flag to do this (sort of).
DS> It's
On Tue, 2005-04-19 at 19:27, mark kaplun wrote:
> What is the point of sending an snmpv3 GET to an agent which does
> not support snmpv3?
There isn't any point in doing that, no.
But we're not really talking about sending a request. At least,
not from the point of view of the application develope
On Tue, 2005-04-19 at 18:18, Wes Hardaker wrote:
> 5) thus, I would choose one of:
>a) have the new behaviour to probe later with a new flag to probe immed.
Well, we've already got a flag to do this (sort of).
It's called "DONT_PROBE".
Or rather, it's the *absence* of the "DONT_PROBE" flag.
I
HI,
It would be really cool if there was a file that had translations
between transport addresses and engineIDs (and contain engineBoots,
and a timestamp that could be used to compute engineTime).
Instead of probing, the values from this file would be used.
If a failure occured, due to engineID
5) thus, I would choose one of:
a) have the new behaviour to probe later with a new flag to probe immed.
b) have the new behaviour to have a new flag to probe later
c) leave as existing
Obviously c is what we're trying to avoid, b is probably safer but I
think we should do a because I doubt
> On Thu, 14 Apr 2005 17:01:27 +0100, Dave Shield <[EMAIL PROTECTED]> said:
>> The question is, what should the default behaviour be?
>> Always delay the probe ... [or] allow a failed probe to
>> successfully return, and set up to retry the probe when needed.
Dave> Either of those two would b
he semantics of the return code
DS> > from snmp_open so you could tell if the probe failed.
DS>
DS> So you can tell whether the probe failed by looking at the engineID
DS> field.
That's true. The original patch, however, also define several other return
codes for other failu
later (when the request was ready to be sent)
rather than earlier (possibly before the session credentials
had been properly established).
IIUC, setting DONT_PROBE would mean that the initial snmp_open()
would succeed, returning a session data structure (though without
the remote engineID and rela
On Mon, 18 Apr 2005 13:43:37 +0100 Dave wrote:
DS> Let's take a step back - what's the purpose behind sending the
DS> probe at this point (opening the session) rather than later on
DS> (when it's actually used) ?
You'll have to argue with Wes on that one.
DS> What would be the implications of d
On Mon, 18 Apr 2005 14:08:18 +0100 Patrick wrote:
PW> but there doesn't seem to be anywhere which says something
PW> like "Unless you are really writing a multithreaded application,
PW> steer clear of snmp_sess_open and stick to snmp_open" i.e., style
PW> recommendations / what is the actual API as
On Mon, 2005-04-18 at 14:08, Patrick Welche wrote:
> On Mon, Apr 18, 2005 at 01:43:37PM +0100, Dave Shield wrote:
> > With the old v4 distributions (and even with v5, given a configure
> > choice of SNMPv1 or SNMPv2c as the default version), then
> >
> > snmp_sess_init( &sess );
> > ss1 =
On Mon, Apr 18, 2005 at 01:43:37PM +0100, Dave Shield wrote:
> On Thu, 2005-04-14 at 22:25, Robert Story wrote:
> > Doesn't setting SNMP_FLAGS_DONT_PROBE in the session flags work? That should
> > prevent the probe and allow a valid session struct to be returned.
>
> Possibly, but it still feels l
On Thu, 2005-04-14 at 22:25, Robert Story wrote:
> Doesn't setting SNMP_FLAGS_DONT_PROBE in the session flags work? That should
> prevent the probe and allow a valid session struct to be returned.
Possibly, but it still feels like an unnecessary step.
With the old v4 distributions (and even with
On Thu, 14 Apr 2005 17:01:27 +0100 Dave wrote:
DS> On Thu, 2005-04-14 at 16:11, Robert Story wrote:
DS> > The question is, what should the default behaviour be?
DS> > Always delay the probe ... [or] allow a failed probe to
DS> > successfully return, and set up to retry the probe when needed.
DS>
D
On Thu, 14 Apr 2005 09:53:37 -0700 (PDT) David wrote:
DTP> I hope you allow the engineID to be specified in the API.
Yes, you can set a flag to not probe, and set the engineID directly in the
session structure.
--
NOTE: messages sent directly to me, instead of the lists, will be dele
HI,
I hope you allow the engineID to be specified in the API.
Regards,
/david t. perkins
On Thu, 14 Apr 2005, Robert Story wrote:
> In order to fix the problem where an inform session fails to open at startup,
> I'm integrating a patch (submitted a few years ago) to delay the engine
On Thu, 2005-04-14 at 16:11, Robert Story wrote:
> The question is, what should the default behaviour be?
> Always delay the probe ... [or] allow a failed probe to
> successfully return, and set up to retry the probe when needed.
Either of those two would be acceptable.
At the moment, the library
In order to fix the problem where an inform session fails to open at startup,
I'm integrating a patch (submitted a few years ago) to delay the engineID probe
until it is needed.
The question is, what should the default behaviour be? Always delay the probe
(any time snmp_open is called for
Wes Hardaker wrote:
On Thu, 24 Jun 2004 17:44:13 +0200, Thomas Anders <[EMAIL PROTECTED]> said:
Thomas> At least the following comment in snmplib/snmpv3.c seems to
Thomas> disagree slightly:
Thomas> if (localEngineIDType == ENGINEID_TYPE_UCD_RND)
Thomas> /*
Thomas> * we must use the net-snmp enterp
>>>>> On Thu, 24 Jun 2004 17:44:13 +0200, Thomas Anders <[EMAIL PROTECTED]> said:
Thomas> -Coders,
Thomas> AFAICS the engineIDType still defaults to the custom (aka
Thomas> proprietary) ENGINEID_TYPE_UCD_RND (128) and the enterprise ID
Thomas> in the engineID i
-Coders,
AFAICS the engineIDType still defaults to the custom (aka proprietary)
ENGINEID_TYPE_UCD_RND (128) and the enterprise ID in the engineID is still
UCD (2021=0x07e5) instead of Net-SNMP (8072=0x1f88). Is there a good reason
for still doing so, even in CVS MAIN?
At least the following
67 matches
Mail list logo
