net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Re: 4.2.pre2 available - Win32 Build Log

[John C. W. <joh...@c-...>]

Net-SNMP Coders,

I've attached a Win-32 build log for 4.2 pre2.

Regards,
John
********************************************
John C. Westmoreland
Broadband Network Division
C-Cube Microsystems, Inc.
1778 McCarthy Boulevard
Milpitas, California 95035
Phone:  408-490-5111
Fax:    408-490-5508
E-Mail:  joh...@c-...
Pager: (800) 562-0687
Text Page: 800...@mo...
********************************************

"Most of the important things in the world have been
accomplished by people who have kept on trying
when there seemed to be no hope at all."
--Dale Carnegie



----- Original Message -----
From: "Wes Hardaker" <wjh...@uc...>
To: <net...@li...>
Sent: Saturday, November 18, 2000 7:45 AM
Subject: 4.2.pre2 available


>
> ucd-snmp-4.2.pre2 is now available at
> http://download.sourceforge.net/net-snmp/ucd-snmp-4.2.pre2.tar.gz.
>
> We'd greatly appreciate people testing it and letting us know of any
> problem that still exist.
>
> Misc recent changes:
>
> - It's support for AgentX should be greatly improved
> - "make test" suite now has 31 tests (some require specific mib
>   modules to be compiled in or else they may be skipped).
>
> --
> Wes Hardaker
> Please mail all replies to net...@li...
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
>

Re: read_objid() capability to interpret strings

[<ni...@ba...>]

On 21 Nov 2000 06:44:28 -0800 Wes Hardaker <wjh...@uc...> wrote:
>That wasn't a good example.  A better example would be a table that I
>don't have a mib for (possibly because it hasn't been written to match
>the code for yet).  I'd certainly want to be able to easily index oids
>based on values even though the first half of them were entirely
>numeric.

Like this?

$ apps/snmptranslate 99.13.14.\"guf\".8
.1.3.6.1.2.1.99.13.14.3.103.117.102.8
$

/Niels

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Re: read_objid() capability to interpret strings

[<ni...@ba...>]

On 21 Nov 2000 06:44:28 -0800 Wes Hardaker <wjh...@uc...> wrote:
>>>>>> On 21 Nov 2000 22:29:34 -0000, ni...@ba... (Niels Baggesen) said:
>
>Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\"
>Wes> Unknown object identifier: system."blue"
>
>Niels> That was not intended, I will fix it (although I have
>Niels> difficulty seing the use for it)
>
>That wasn't a good example.  A better example would be a table that I
>don't have a mib for (possibly because it hasn't been written to match
>the code for yet).  I'd certainly want to be able to easily index oids
>based on values even though the first half of them were entirely
>numeric.

Now youre talking buziness. Yes, it should of course not require you to have the
mib file. I will investigate that.

/Niels

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

re: openssl-0.9.6

[<ni...@ba...>]

Please keep responding to the list, not to me personally. Others on the list are
more fluent in the security aspects of v3!

On Tue, 21 Nov 2000 17:13:52 +0100 Khalif Aden Hassan
<kha...@er...> wrote:
>
>hi Niels!
>I did rerun configure and re-install ucd-snmp after installing OpenSSL
>as you said.

I forgot to ask: did you remove config.cache before rerunning configure?

>I use the ucd-snmp as a manager , to send the request to another
>Target-agent (proxy agent), the question is : do I need to configure usm
>access in snmpd.conf in UCD packet??

No, you only use snmpd.conf if you run out snmpd. It was not clear from your
first post what agent you were talking to.

>as an example or calling snmpwalk:
>
>"snmpwalk -v3 -Os -p 4700 -l authNoPriv -u SHA -a SHA -A
>SHAUSerAuthPassword localhost system"
>
>and the result is the same!!
>
>snmpwalk: USM authentication failure

This is probably an error that originates from the agent, but this is where we
reach the limits of my understanding of v3. You might try adding the options

   -d -Dusm,snmpv3,snmp_parse

to snmpwalk to get more details on what is going on.

/Niels

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Re: read_objid() capability to interpret strings

[Wes H. <wjh...@uc...>]

>>>>> On 21 Nov 2000 22:29:34 -0000, ni...@ba... (Niels Baggesen) said:

Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\"
Wes> Unknown object identifier: system."blue"

Niels> That was not intended, I will fix it (although I have
Niels> difficulty seing the use for it)

That wasn't a good example.  A better example would be a table that I
don't have a mib for (possibly because it hasn't been written to match
the code for yet).  I'd certainly want to be able to easily index oids
based on values even though the first half of them were entirely
numeric.

For another example, see the ucd-snmp/proxy module and how its capable
of re-locating remote oids into a different section of the local OID
tree (since we have no context support currently, this is required to
support multiple remote agents serving the same information).

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: read_objid() capability to interpret strings

[<ni...@ba...>]

On 21 Nov 2000 18:19:31 +0100 Frank Strauss <st...@ib...> wrote:
>Wes> However (Niels), it doesn't seem to work genericly, which is a
>Wes> problem (even if its illegal and doesn't make sense...  We shouldn't
>Wes> force the requirement of knowledge about the mib in question):
>
>Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\"
>Wes> Unknown object identifier: system."blue"

That was not intended, I will fix it (although I have difficulty seing the use
for it)

>Yes. This seems to be my problem. In case of VACM configurations we
>would need the generic behavior.

Please explain to me why you would need it

/Niels

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Re: rmon possibilities?

[Wes H. <wjh...@uc...>]

>>>>> On Tue, 21 Nov 2000 10:08:21 -0500 (EST), Jas...@ms... said:

Jason> hey all -- was wondering...the RMON-MIB is in the mibs
Jason> directory...how do you activate it?  do i have to compile it
Jason> first with mib2c, or is there an alternative way of doing this?
Jason> essentially, the goal of all of this is to send out traps based
Jason> on certain values being exceeded/reached elsewhere in the MIBs
Jason> (so if someone knows of another way to do this, please
Jason> advise!)...

no, RMON isn't supported by our agent (and would be a major
under-taking to add support for it).  Just having the MIB file isn't
enough.  Running mib2c on it would help define a structure that could
be used to add the implementation needed, but a lot of work would be
required after mib2c was run on each of the RMON sections.

This kind of question is also discussed in the FAQ, so you might go
glance through that.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: rmon possibilities?

[Bert D. <dri...@pl...>]

Jason Greenberg wrote:

>         hey all -- was wondering...the RMON-MIB is in the mibs
> directory...how do you activate it?  do i have to compile it first
> with mib2c, or is there an alternative way of doing this?  
> essentially, the goal of all of this is to send out traps based on
> certain values being exceeded/reached elsewhere in the MIBs (so if
> someone knows of another way to do this, please advise!)...

This topic comes up every once in a while... Actually, both topics :-)

mib2c will only generate a template for you. What you have to do then is
implement the code that actually does what needs to happen. In the case
of RMON, that is a lot.

There is one public RMON implementation available, which is btng
(Beholder, The Next Generation) from the university of
Delft. Unfortunately, it is as dead as a doornail. Pity, because it's a
very good piece of work.

I'm considering ripping all parts of btng that duplicate UCD-SNMP
functionality out, and using the remainder as a standalone RMON agent to
supplement NET-SNMP (time permitting, loosely integrating the thing as a
sub-agent, but we all know what an elusive entity time is).

I've started to work on this, currently the thing builds under FreeBSD
and BSD/OS. Contact me if you want to try your luck.

Cheers,

				-- Bert


Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!

Re: read_objid() capability to interpret strings

[Frank S. <st...@ib...>]

Frank> Is it intentional that the configuration of views in snmpd.conf
Frank> can no longer include strings in the OID field? I was very
Frank> happy to use something like

Wes> I think this was recently fixed (just after 4.2.pre2).  Can you check
Wes> the absolute latest cvs snapshot?

Wes> % ./snmptranslate -IR snmpTargetAddrTDomain.\"blue\"
Wes> .1.3.6.1.6.3.12.1.2.1.2.98.108.117.101

Right. This works. But...

Wes> However (Niels), it doesn't seem to work genericly, which is a
Wes> problem (even if its illegal and doesn't make sense...  We shouldn't
Wes> force the requirement of knowledge about the mib in question):

Wes> 8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\"
Wes> Unknown object identifier: system."blue"

Yes. This seems to be my problem. In case of VACM configurations we
would need the generic behavior.

Re: Pluggable transport domains via register_readfd-like API?

[John N. <jb...@ca...>]

Wes> Posting to the sourceforge patches page is a fine thing to do...  No
Wes> problems there (I don't consider it an interface to manage *only* the
Wes> next release).

Ah, okay.  I've added it there too.

John.

-- 
// Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd.
// The future of broadband wireless access  // www.cambridgebroadband.com

Re: Last leak news

[Dave S. <D.T...@cs...>]

> The last memory leak is about subagent INIT or EXIT which create memory
> leak at the master agent side (agentx). We can deal with that minor problem,
> even if it should be corrected some days.

Thanks for your reports.  Having finally got my head round what
the format means, I'm finding them invaluable.

  I'm inclined to suggest that we hold off on trying to fix the init/exit
leaks just now.  They're not likely to have as significant an effect as
the request ones, and I'm concerned about breaking a (mostly working)
agent, just as we're on the point of releasing it.


> I cannot resist to send the PURIFY's report about this last memory leak.

Noted.
We'll try and fix these as soon as the chaos of the 4.2 release has
calmed down.  (Not that I'm anticipating any problems, oh nooooo....)


Dave

P.S:  One minor point - could you possibly report these sorts of problems
 to just one of the mailing lists, rather than all four.  The volume is
 pretty high already, and such duplications just make the problem worse.
I'm sure neither you nor Wes would want me to have to withdraw from
 the project due to email overload!

Re: Pluggable transport domains via register_readfd-like API?

[Wes H. <wjh...@uc...>]

>>>>> On Tue, 21 Nov 2000 16:55:25 +0000, Dave Shield <D.T...@cs...> said:

Dave> Oh, I'd agree that mib modules shouldn't *need* to know about it.
Dave> Currently, they can operate quite happily in the the absence of
Dave> this information, and I don't see that changing.

Sorry.  I meant to say that I agree, however.  I was being entirely
theoretical.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Pluggable transport domains via register_readfd-like API?

[Dave S. <D.T...@cs...>]

Dave> -  Currently, the MIB module code does not have access
Dave> to any of the PDU "administrative" information, such as the
Dave> authenticated user, the community string, or the context.

Wes> Theoretically, I've always considered this a bad thing that mib
Wes> modules should need to know about it

Oh, I'd agree that mib modules shouldn't *need* to know about it.
Currently, they can operate quite happily in the the absence of
this information, and I don't see that changing.
  What I'd like is to give mib module implementations the *option* 
of accessing this information.   There may be situations where this
might be useful, and I can't see any reason to forbid it, if we can
do this in a sensible manner.

  I've been particularly thinking of the context string, but I'm also
trying to think ahead, and plan in terms of a flexible mechanism
(e.g. SNMPv9's "gravitational constant" field....)

Dave

Re: Pluggable transport domains via register_readfd-like API?

[Wes H. <wjh...@uc...>]

>>>>> On Tue, 14 Nov 2000 13:42:54 +0000, John Naylon <jb...@ca...> said:

John> If anyone is interested, I can email patches, but for now I
John> won't post anything to the sourceforge page. I expect to clean
John> up the remaining stuff over the next few days.

Posting to the sourceforge patches page is a fine thing to do...  No
problems there (I don't consider it an interface to manage *only* the
next release).

John> What's the current ETA of 4.2?

End of next week, developers permitting.

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Pluggable transport domains via register_readfd-like API?

[Wes H. <wjh...@uc...>]

>>>>> On Tue, 07 Nov 2000 10:17:29 +0000, Dave Shield <D.T...@cs...> said:

Dave> -  Currently, the MIB module code does not have access
Dave> to any of the PDU "administrative" information, such as the
Dave> authenticated user, the community string, or the context.
Dave> This might be useful for particular modules that want to respond
Dave> differently based on this information.

Theoretically, I've always considered this a bad thing that mib
modules should need to know about it (see previous rant on the subject
of the USM ownKeyChange objects).

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: read_objid() capability to interpret strings

[Wes H. <wjh...@uc...>]

>>>>> On 21 Nov 2000 13:33:51 +0100, Frank Strauss <st...@ib...> said:

Frank> Is it intentional that the configuration of views in snmpd.conf
Frank> can no longer include strings in the OID field? I was very
Frank> happy to use something like

I think this was recently fixed (just after 4.2.pre2).  Can you check
the absolute latest cvs snapshot?

% ./snmptranslate -IR snmpTargetAddrTDomain.\"blue\"
.1.3.6.1.6.3.12.1.2.1.2.98.108.117.101

However (Niels), it doesn't seem to work genericly, which is a
problem (even if its illegal and doesn't make sense...  We shouldn't
force the requirement of knowledge about the mib in question):

8:24am wanderer [189]: ./snmptranslate -IR system.\"blue\"
Unknown object identifier: system."blue"

-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Last leak news

[Wes H. <wjh...@uc...>]

Jargot> All the tests have been done again, and everything is just
Jargot> find for SET, GET, and GETNEXT !!

Excellent!

You might also (if you haven't) try doing a few SIGHUPs to the
agent(s) and see if that produces some more (I wouldn't be surprised
if it did).

-- 
Wes Hardaker
Please mail all replies to net...@li...

rmon possibilities?

[<Jas...@ms...>]

	hey all -- was wondering...the RMON-MIB is in the mibs
directory...how do you activate it?  do i have to compile it first with
mib2c, or is there an alternative way of doing this?  essentially, the
goal of all of this is to send out traps based on certain values being
exceeded/reached elsewhere in the MIBs (so if someone knows of another way
to do this, please advise!)...

thanks,

jason

Last leak news

[Jargot J. <Jer...@fe...>]

  Hi,

This is the last memory leak report from my tests with PURIFY.

The fix sent by John Naylon to correct the bug #326 (memory leak of SET) has been applied.

All the tests have been done again, and everything is just find for SET, GET, and GETNEXT !!

The last memory leak is about subagent INIT or EXIT which create memory leak at the master agent side (agentx). We can deal with that minor problem, even if it should be corrected some days.

I cannot resist to send the PURIFY's report about this last memory leak.


Version : UCD-SNMP version 4.2.pre2 + fix_of_bug_#326 (from John Naylon)
System  : SunOS 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-250


A table summarizes all the results of the tests :
    - Values with * are not constant.
    - MLK stands for Memory LeaK
    - PLK stands for Potential memory LeaK


Example from the table:
--------------+----------+--------+--------+----------+
              |          |        |        |          |
GET / GETNEXT | Subagent |      0 |      0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
The previous line means: "Issuing a GET or a GETNEXT to fetch a value in a MIB handled by a subagent does not make any kind of memory leak on the master agent."



-------------------------+----------------------------+
        Operation        |       Memory (bytes)       |
-------------------------+----------------------------+
              |          |        |        |          |
     Type     |  Target  |  MLK   |  PLK   | Location |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
--------------+----------+--------+--------+----------+
              |          |        |        |          |
Init          |   Master |     19 |   2064 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
Init          | Subagent | *  636 | * 3232 | Subagent |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
Init          | Subagent | * 2124 | * 4128 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
GET / GETNEXT |   Master |      0 |      0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
GET / GETNEXT | Subagent |      0 |      0 | Subagent |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
GET / GETNEXT | Subagent |      0 |      0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
SET           | Subagent |      0 |      0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
SET           | Subagent |      0 |      0 | Subagent |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
SET           |   Master |      0 |      0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
Exit          | Subagent | *   57 | *    0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+






Here is the PURIFY's report for:

--------------+----------+--------+--------+----------+
              |          |        |        |          |
Init          | Subagent | * 2124 | * 4128 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+

New memory leaked: 2124 bytes (2.09%); potentially leaked: 4128 bytes (4.06%)
   MLK: 2064 bytes leaked in 3 blocks
   This memory was allocated from:
         malloc         [rtlib.o]
         register_mib_context [agent_registry.c:310]
              int res, i;
              struct register_parameters reg_parms;

         =>   subtree = (struct subtree *) malloc(sizeof(struct subtree));
              if ( subtree == NULL )
                return MIB_REGISTRATION_FAILED;
              memset(subtree, 0, sizeof(struct subtree));
         register_agentx_list [master_admin.c:161]
                                     pdu->variables->name, pdu->variables->name_length,
                                     pdu->priority, pdu->range_subid, ubound, sp,
                                     pdu->community, pdu->time,
         =>                          pdu->flags&AGENTX_MSG_FLAG_INSTANCE_REGISTER)) {

                    case MIB_REGISTERED_OK:
                                            DEBUGMSGTL(("agentx:register",
         handle_master_agentx_packet [master_admin.c:385]
                            break;

                    case AGENTX_MSG_REGISTER:
         =>                 asp->status = register_agentx_list( session, pdu );
                            break;

                    case AGENTX_MSG_UNREGISTER:
         _sess_read     [snmp_api.c:4237]
                    {
                      /* MTR snmp_res_lock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                      sp->callback(RECEIVED_MESSAGE, sp, pdu->reqid, pdu,
         =>                        sp->callback_magic);
                      /* MTR snmp_res_unlock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                    }
                }
         snmp_sess_read [snmp_api.c:4259]
                struct snmp_session *pss;
                int rc;

         =>     rc = _sess_read(sessp, fdset);
                psl = (struct session_list *)sessp;
                pss = psl->session;
                if (rc && pss->s_snmp_errno) {
   Block of 688 bytes (3 times); last block at 0xc0e38
   MLK: 60 bytes leaked in 3 blocks
   This memory was allocated from:
         malloc         [rtlib.o]
         register_mib_context [agent_registry.c:331]
              subtree->end_len = (u_char) mibloclen;
              memcpy(subtree->label, moduleName, strlen(moduleName)+1);
              if ( var ) {
         =>     subtree->variables = (struct variable *) malloc(varsize*numvars);
                memcpy(subtree->variables, var, numvars*varsize);
                subtree->variables_len = numvars;
                subtree->variables_width = varsize;
         register_agentx_list [master_admin.c:161]
                                     pdu->variables->name, pdu->variables->name_length,
                                     pdu->priority, pdu->range_subid, ubound, sp,
                                     pdu->community, pdu->time,
         =>                          pdu->flags&AGENTX_MSG_FLAG_INSTANCE_REGISTER)) {

                    case MIB_REGISTERED_OK:
                                            DEBUGMSGTL(("agentx:register",
         handle_master_agentx_packet [master_admin.c:385]
                            break;

                    case AGENTX_MSG_REGISTER:
         =>                 asp->status = register_agentx_list( session, pdu );
                            break;

                    case AGENTX_MSG_UNREGISTER:
         _sess_read     [snmp_api.c:4237]
                    {
                      /* MTR snmp_res_lock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                      sp->callback(RECEIVED_MESSAGE, sp, pdu->reqid, pdu,
         =>                        sp->callback_magic);
                      /* MTR snmp_res_unlock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                    }
                }
         snmp_sess_read [snmp_api.c:4259]
                struct snmp_session *pss;
                int rc;

         =>     rc = _sess_read(sessp, fdset);
                psl = (struct session_list *)sessp;
                pss = psl->session;
                if (rc && pss->s_snmp_errno) {
   Block of 20 bytes (3 times); last block at 0xbc5a0
   PLK: 4128 bytes potentially leaked in 6 blocks
   This memory was allocated from:
         malloc         [rtlib.o]
         register_mib_context [agent_registry.c:310]
              int res, i;
              struct register_parameters reg_parms;

         =>   subtree = (struct subtree *) malloc(sizeof(struct subtree));
              if ( subtree == NULL )
                return MIB_REGISTRATION_FAILED;
              memset(subtree, 0, sizeof(struct subtree));
         register_agentx_list [master_admin.c:161]
                                     pdu->variables->name, pdu->variables->name_length,
                                     pdu->priority, pdu->range_subid, ubound, sp,
                                     pdu->community, pdu->time,
         =>                          pdu->flags&AGENTX_MSG_FLAG_INSTANCE_REGISTER)) {

                    case MIB_REGISTERED_OK:
                                            DEBUGMSGTL(("agentx:register",
         handle_master_agentx_packet [master_admin.c:385]
                            break;

                    case AGENTX_MSG_REGISTER:
         =>                 asp->status = register_agentx_list( session, pdu );
                            break;

                    case AGENTX_MSG_UNREGISTER:
         _sess_read     [snmp_api.c:4237]
                    {
                      /* MTR snmp_res_lock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                      sp->callback(RECEIVED_MESSAGE, sp, pdu->reqid, pdu,
         =>                        sp->callback_magic);
                      /* MTR snmp_res_unlock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                    }
                }
         snmp_sess_read [snmp_api.c:4259]
                struct snmp_session *pss;
                int rc;
 
         =>     rc = _sess_read(sessp, fdset);
                psl = (struct session_list *)sessp;
                pss = psl->session;
                if (rc && pss->s_snmp_errno) {
   Block of 688 bytes (6 times); last block at 0xc6150
   Purify Heap Analysis (combining suppressed and unsuppressed blocks)
                            Blocks        Bytes
                 Leaked          7         2143
     Potentially Leaked          8         6192
                 In-Use        654        93378
     ----------------------------------------
        Total Allocated        669       101713



Here is the PURIFY's report for:
--------------+----------+--------+--------+----------+
              |          |        |        |          |
Exit          | Subagent | *   57 | *    0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+

New memory leaked: 57 bytes (0.0682%); potentially leaked: 0 bytes (0%)
   MLK: 36 bytes leaked at 0xc53f0
   This memory was allocated from:
         malloc         [rtlib.o]
         snmp_duplicate_objid [snmp_api.c:5268]
            snmp_duplicate_objid(oid *objToCopy, size_t objToCopyLen)
            {
              oid *returnOid;
         =>   returnOid = (oid *) malloc(objToCopyLen*sizeof(oid));
              if (returnOid) {
                memmove(returnOid, objToCopy, objToCopyLen*sizeof(oid));
              }
         open_agentx_session [master_admin.c:90]
                     * But I'm willing to be persuaded otherwise....
                     */
                sp->securityAuthProto =
         =>         snmp_duplicate_objid(pdu->variables->name, pdu->variables->name_length);
                sp->securityAuthProtoLen = pdu->variables->name_length;
                sp->securityName = strdup( pdu->variables->val.string );
                gettimeofday(&now, NULL);
         handle_master_agentx_packet [master_admin.c:375]

                switch (pdu->command) {
                    case AGENTX_MSG_OPEN:
         =>                 asp->pdu->sessid = open_agentx_session( session, pdu );
                            if ( asp->pdu->sessid == -1 )
                                asp->status = session->s_snmp_errno;
                            break;
         _sess_read     [snmp_api.c:4237]
                    {
                      /* MTR snmp_res_lock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                      sp->callback(RECEIVED_MESSAGE, sp, pdu->reqid, pdu,
         =>                        sp->callback_magic);
                      /* MTR snmp_res_unlock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                    }
                }
         snmp_sess_read [snmp_api.c:4259]
                struct snmp_session *pss;
                int rc;

         =>     rc = _sess_read(sessp, fdset);
                psl = (struct session_list *)sessp;
                pss = psl->session;
                if (rc && pss->s_snmp_errno) {
   MLK: 21 bytes leaked at 0xc5468
   This memory was allocated from:
         malloc         [rtlib.o]
         strdup         [libc.so.1]
         open_agentx_session [master_admin.c:92]
                sp->securityAuthProto =
                    snmp_duplicate_objid(pdu->variables->name, pdu->variables->name_length);
                sp->securityAuthProtoLen = pdu->variables->name_length;
         =>     sp->securityName = strdup( pdu->variables->val.string );
                gettimeofday(&now, NULL);
                sp->engineTime = calculate_time_diff( &now, &starttime );

         handle_master_agentx_packet [master_admin.c:375]

                switch (pdu->command) {
                    case AGENTX_MSG_OPEN:
         =>                 asp->pdu->sessid = open_agentx_session( session, pdu );
                            if ( asp->pdu->sessid == -1 )
                                asp->status = session->s_snmp_errno;
                            break;
         _sess_read     [snmp_api.c:4237]
                    {
                      /* MTR snmp_res_lock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                      sp->callback(RECEIVED_MESSAGE, sp, pdu->reqid, pdu,
         =>                        sp->callback_magic);
                      /* MTR snmp_res_unlock(MT_LIBRARY_ID, MT_LIB_SESSION); */
                    }
                }
                           snmp_sess_read [snmp_api.c:4259]
                struct snmp_session *pss;
                int rc;
 
         =>     rc = _sess_read(sessp, fdset);
                psl = (struct session_list *)sessp;
                pss = psl->session;
                if (rc && pss->s_snmp_errno) {
   Purify Heap Analysis (combining suppressed and unsuppressed blocks)
                            Blocks        Bytes
                 Leaked          9         2200
     Potentially Leaked          8         6192
                 In-Use        617        75208
     ----------------------------------------
        Total Allocated        634        83600




Someone may correct these memory leaks...


Thanks for everything



   Jerome

read_objid() capability to interpret strings

[Frank S. <st...@ib...>]

Hi!

Is it intentional that the configuration of views in snmpd.conf
can no longer include strings in the OID field? I was very happy
to use something like

view guestReadView \
     included DISMAN-SCRIPT-MIB::smScriptObjects.0.0.0."guest" ff:8f:c0

in the past. But now (after a CVS update to 4.2pre2) this does not
work any longer:

.../snmpd_jasmin.conf: line 59: Error: bad SUBTREE object id

 Frank

Re: Pluggable transport domains via register_readfd-like API?

[John N. <jb...@ca...>]

Hi,

  here is a preliminary patch which adds pluggable transport domains to the 
net-snmp library.  It applies cleanly to the current CVS source.  I've 
checked the resultant code on Linux and Solaris 2.7 and it builds cleanly 
and passes the test suite on both.  Domains are included or excluded from 
the library via two new configure options, --with-transports and 
--with-out-transports (strongly modeled on the MIB module options); see 
./configure --help for more information.

  Hopefully there aren't any externally visible API changes, but quite a lot 
of internals have been touched, so there may be some tweaks necessary.  I'd 
be really interested in any feedback, especially if anyone felt like having 
a go at adding another transport.  The best way of approaching the latter 
would be to take a look at either snmpUDPDomain.[ch] or snmpTCPDomain.[ch], 
depending on the whether the transport is connectionless or 
connection-oriented, and mimicking what they do.  It should only be a couple 
of hours' work to add a transport.

  The most significant areas of uncertainty are how the new code interacts 
with the AgentX (I am almost certain it will have no effect) and how it 
interacts with the target MIB.  Again, it should just work with the latter, 
but there is lots of scope to do some cool stuff allowing traps to be sent 
over alternative transport domains.

  Apply the patch with:

    % patch -p0 < plug-patch

  from the top-level of the net-snmp hierarchy, and run autoconf before 
configuring for the first time.

  John

-- 
// Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd.
// The future of broadband wireless access  // www.cambridgebroadband.com

Re: Bug or resource limit?

[<ni...@ba...>]

On Mon, 20 Nov 2000 23:17:52 GMT "Daniel L. Needles"<dne...@jp...> wrote:
>Hello,
>  It appears I hit another limit.  If 1020 sessions are specified, everything's
>fine. But if 1021 sessions are speified snmp_select_info() returns OK but the
>select() call complains with errno=22 (#define EINVAL          22      /*
Invalid
>argument */)
>
>At 3000 or so session the &fds count returned from snmp_select_info is over
>several million but the return VALUE from snmp_select_info() is correct.

At least on Solaris, man select documents this problem. The size of an fd_set
defaults to 1024 file descriptors. If you are going to use more (by calling
setrlimit), you must
#define FD_SETSIZE 4096
before
#include <sys/types.h>

Linux has no documentation for this, but a cursory look through the include
files suggests that the following MIGHT work:

#include <sys/types.h>
#undef __FD_SETSIZE
#define __FD_SETSIZE 4096
fd_set reads_fds, ...

>::::GOOD CALL FOR 1021 NODE POLLS IN 1021 SESSIONS:::::
>BEFORE:0=snmp_select_info(fds=0,fdset,timeout,1)
>AFTER: 1020=snmp_select_info(fds=1024,fdset,timeout,0)

This is not good, but shows memory corruption. snmp_select_info cannot
legitimately change the value of fds from 0 to 1024. Something was overwritten.

/Niels

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Re: Maximum size of a trap packet

[Sudheer T. <stu...@re...>]

Hi,
        Dave, thanks for the help. I changed the SNMP_MAX_MSG_SIZE #define from
1472 to 64000. It works perfectly when doing an snmp_send(). But when the snmpd
gets a big packet and needs to forward it to a subagent, it gives a segmentation
fault and quits in some instances. At other times, the subagent gets
RESERVE1, RESERVE2 and some ACTION updates but stops after that without COMMIT. I
suspect this is something to do with AgentX packet size. I checked snmp_agent.h but
found the SNMP_MAX_PDU_SIZE already set to 64000. Is there any other place where
there is a size limit and if it is, how can I extend it?

TIA,
Sudheer

Dave Shield wrote:

> > Looks like the PDU I'm trying to send chokes when it reaches a little over 300
> > OIDs (20 + (13 entries per row * 22 rows)). Some of the OIDs have octect
> > string values and I guess the exact number varies depending on the length of
> > these strings.
>
> That sounds plausible.  Checking the code, the size of the encoded PDU is
> restricted by the size of the (static) buffer used to build it. This is set
> at SNMP_MAX_MSG_SIZE  - defined to be 1472 bytes.
>
>   One option would be to increase the value of this definition, so that
> your normal requirements do not hit this limit.
>
> >              I am just looking for a method to tell me when the PDU is full
> > so I can stop stuffing it further with OIDs.
>
> Sorry - there isn't any such indication.  And the current design of the
> packet encoding is such that it wouldn't be simple to add one.  There's
> no concept of "partially building" a packet - the expectation is that
> the packet is complete before it's encoded.
>
>   It might be possible to hack something together - perhaps by calling
> 'snmp_build' and testing the return code (and discarding the encoded
> packet), but this would probably be fairly inefficient.
>
>   The alternative would be to build the full packet as you'd like to
> send it, and strip off excess OIDs until the send call succeeds.
>
> Sorry if this isn't of much help to you.
>
> Dave
>
> _______________________________________________
> Net-snmp-users mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-users

Re: Perl SNMP doc update questions

[Wes H. <wjh...@uc...>]

>>>>> On Mon, 20 Nov 2000 18:33:56 -0500, "G. S. Marzot" <ma...@ti...> said:

G> I won't mention ucd-snmp.ucdavis.edu since it sounds like it may go
G> away during the active lifetime of these docs.

Well, its an "unknown", so thats probably safe.

G> I think that the SNMP module will change less frequently than the
G> main library (being a higher level API this should be true).

I'm glad you have confidence in that, but I distinctly remember times
when the perl module released a couple of minor versions more
frequently than the ucd-snmp source (followed quickly by the reverse,
of course).

It's up to you of course!
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Perl SNMP doc update questions

[G. S. M. <ma...@ti...>]

Wes Hardaker wrote:

> >>>>> On Mon, 20 Nov 2000 10:12:41 -0500, "G. S. Marzot" <ma...@ti...> said:
>
> G> Is there an ftp:// url I can use for source access or do we force
> G> peopl to go through the web page?
>
> We will be placing it on the anonymous ftp server at sourceforge as
> well, and the next release will be at the old site as well (for a
> while at least, till they do something with the box that I no longer
> control).
>
> We do prefer the web, however, as it keeps track of usage statistics
> better...

ok so for the docs I will mention

http://download.sourceforge.net/net-snmp

I won't mention ucd-snmp.ucdavis.edu since it sounds like it may go away during
the active lifetime of these docs.

>
>
> G> I was also thinking to synchronize the the Perl SNMP module version
> G> number with the NET-SNMP version number...at least in the first two
> G> positions. so when x.y.z of NET-SNMP goes out the Perl SNMP module
> G> will always be at least x.y.0. thoughts?
>
> That makes sense to me and is certainly easier for other people to
> understand.  I'd try to synchronize it almost exactly, so that the
> perl release would be x.y.z unless it needed an independent update and
> then would become x.y.z.1 (or whatever).

I think that the SNMP module will change less frequently than the main library
(being a higher level API this should be true). Minor fix releases like x.y.1
will probably not require any change to perl SNMP x.y.0 so the former suggestion
may reduce the cases where the version number advances but no code has changed
(which can be confusing too).

Plus 4 version numbers are too many ;) we could just let the 3rd position keep
track of independent changes.

-GSM