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

Bug or resource limit?

[Daniel L. Needles<dne...@jp...>]

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.

Any ideas?

CODE SNIP:
 if (first) 
   fprintf(stderr,"BEFORE:%d=snmp_select_info(fds=%d,fdset,timeout,%d)\n",opensocks,fds,block);

 opensocks=snmp_select_info(&fds, &fdset, &timeout, &block);
 if (first) 
   fprintf(stderr,"AFTER: %d=snmp_select_info(fds=%d, fdset,timeout,%d)\n",opensocks,fds,block);

/* WAIT ONLY 5 SECONDS */
 timeout.tv_sec = 15;
 timeout.tv_usec = 0;
 block=0;
 if (first) 
   fprintf(stderr,"BEFORE:%d=select(fds=%d, fdset,X,X,%d)\n",fds,fds,block);

 fds = select(fds, &fdset, NULL, NULL, block ? NULL : &timeout);
 if (first) 
   fprintf(stderr,"AFTER:%d=select(fds=%d,fdset,X,X,%d)\n",fds,fds,block);
 if (fds > 0) {
   snmp_read(&fdset);
 } else if ( fds == 0 ) {
   snmp_timeout();
 } else {
   fprintf(stderr,"select failed with errno==%d\n",errno);
   exit(4);
 } 

::::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)
BEFORE:1024=select(fds=1024,fdset,X,X,0)
AFTER:385=select(fds=385,fdset,X,X,0)

::::BAD CALL FOR 1021 NODE POLLS IN 1021 SESSIONS:::::
BEFORE:0=snmp_select_info(fds=0,fdset,timeout,1)
AFTER: 1021=snmp_select_info(fds=1025,fdset,timeout,0)
BEFORE:1025=select(fds=1025,fdset,X,X,0)
AFTER:-1=select(fds=-1,fdset,X,X,0)
select failed with errno==22

Re: Using C multiple OIDS in a single ASYNC packet.

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

On Mon, 20 Nov 2000 08:53:27 -0800 "Daniel L. Needles" <dne...@jp...> wrote:
>  OK. I got everything.  The only thing I never could find was
>RLIMIT_NOFILES parameter in the kernel.  If you happen to know it that would
>be great for Linux Red Hat.  Also, although the hard set value was set at
>1024 using setrlimit() or ulimit -n I could raise the soft limit ABOVE the
>hard limit (according to getrlimit()) for root only?  Do you know why?

Sorry, I never played with these things, so I can't help your there. I only 
know the principles ... doesn't man setrlimit or man ulimit explain anything?
Btw, saying Linux RedHat is not really helpful. What can make a difference is 
the kernel version (2.0.x, 2.2.y, 2.4.z ?)

/Niels

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

Re: Perl SNMP doc update questions

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

>>>>> 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...

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).

G> last bit of administravia - there is a Net::SNMP perl module out on
G> CPAN currently and there is already some level of confusion between
G> our SNMP module and that one. I expect that level to rise some...I
G> guess this is just fair warning seeing as its too late to change
G> the name again.  Ideally our perl SNMP module would be named
G> Net::SNMP but I don't see that happening either.

True...  I hadn't thought of that naming conflict.  I think the other
one is still being developed/maintained at least minimally too
(Simon's right?).

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

Re: 4.2.pre2 available

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

>>>>> On Mon, 20 Nov 2000 09:59:36 +0100, RADMAN Stefan <Ste...@CT...> said:

RADMAN> Tested on Solaris 2.6

Excellent.  Thanks for the report.

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

Re: 4.2.pre2 available

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

>>>>> On Sun, 19 Nov 2000 17:46:00 +0100 (CET), Bert Driehuis <dri...@pl...> said:

Bert> I'm impressed with the test harness... Works really well.

Thanks....  I've been slowing building on it for a while now...

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

Re: latest cvs source segvs on linux 2.2.12-20 (egcs-2.91.66)

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

>>>>> On Mon, 20 Nov 2000 10:04:03 -0500, "G. S. Marzot" <ma...@ti...> said:

G> Don't know how to explain it but I did a make distclean with the
G> latest from cvs and now the segv's went away. Don't have time to
G> figure it out but my guess is that there was some stack
G> corruption...??

Well, at least that sort of good. kinda. I guess.

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

Re: Help ! New Leak report

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

 [ snip ]

> To summarize: At line 891 of the file snmp_agent.c In the function
> handle_one_var, there is some memory allocated (for variable saved->statP),
> and the pointer on this new memory will be lost latter. Thus this memory
> cannot be freed.

This is/was bug #326 in the old database and was discussed at length.  The 
fix is not to do the malloc() and copy but rather simply to copy the pointer.

John

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

Re: Help ! New Leak report

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

 [ snip ]

> To summarize: At line 891 of the file snmp_agent.c In the function
> handle_one_var, there is some memory allocated (for variable saved->statP),
> and the pointer on this new memory will be lost latter. Thus this memory
> cannot be freed.

This is/was bug #326 in the old database and was discussed at length.  The 
fix is not to do the malloc() and copy but rather simply to copy the pointer.

John

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

Re: Help ! New Leak report

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

 [ snip ]

> To summarize: At line 891 of the file snmp_agent.c In the function
> handle_one_var, there is some memory allocated (for variable saved->statP),
> and the pointer on this new memory will be lost latter. Thus this memory
> cannot be freed.

This is/was bug #326 in the old database and was discussed at length.  The fix is not to do the malloc() and copy but rather simply to copy the pointer.

John

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

Re: Using C multiple OIDS in a single ASYNC packet.

[Daniel L. N. <dne...@jp...>]

Niels.,
  OK. I got everything.  The only thing I never could find was
RLIMIT_NOFILES parameter in the kernel.  If you happen to know it that would
be great for Linux Red Hat.  Also, although the hard set value was set at
1024 using setrlimit() or ulimit -n I could raise the soft limit ABOVE the
hard limit (according to getrlimit()) for root only?  Do you know why?

Thanks,
Daniel L. Needles

Help ! New Leak report

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

    Hi all !

Again a memory leak and a report.
I have tested the brand new "UCD-SNMP version 4.2.pre2" with PURIFY from Rational Soft.

No memory leak exists for GET and GETNEXT which is just find !!!

Memory leaks at INIT or at EXIT of master agent or of subagent can be ignored.
But there is a memory leaks when issuing a SET on both the master agent and the subagent. 

As usual, I need help to correct these memory leaks ...
I'm working on the source files to fix this last leak.


Version : UCD-SNMP version 4.2.pre2 
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 |    708 | * 6880 |   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 | *   42 |      0 | Subagent |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
SET           |   Master | *   13 | *   21 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+
              |          |        |        |          |
Exit          | Subagent | *   57 | *    0 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+



Here is a PURIFY report for :
--------------+----------+--------+--------+----------+
              |          |        |        |          |
SET           |   Master | *   13 | *   21 |   Master |
              |          |        |        |          |
--------------+----------+--------+--------+----------+

New memory leaked: 13 bytes (0.0128%); potentially leaked: 0 bytes (0%)
   MLK: 13 bytes leaked at 0x985a0
   This memory was allocated from:
         malloc         [rtlib.o]
         handle_one_var [snmp_agent.c:891]
                                        return SNMP_ERR_GENERR;
                                    }
                                    saved->write_method = write_method;
         =>                         saved->statP = (u_char *)malloc((statLen)?statLen:1);
                                    if ( saved->statP && statP )
                                        memcpy( saved->statP, statP, statLen );
                                    saved->statType     = statType;
         handle_var_list [snmp_agent.c:719]
                while (1) {
                    count++;
                    asp->index = count;
         =>         status = handle_one_var(asp, varbind_ptr);
 
                    if ( status != SNMP_ERR_NOERROR ) {
                        return status;
         handle_next_pass [snmp_agent.c:654]
 
                    if ( asp->outstanding_requests != NULL )
                        return SNMP_ERR_NOERROR;
         =>         status = handle_var_list( asp );
                    if ( asp->outstanding_requests != NULL ) {
                        if ( status == SNMP_ERR_NOERROR ) {
                            /* Send out any subagent requests */
         handle_snmp_packet [snmp_agent.c:482]
                        snmp_increment_statistic(STAT_SNMPINSETREQUESTS);
                        asp->rw      = WRITE;
 
         =>             status = handle_next_pass( asp );
 
                        if ( status != SNMP_ERR_NOERROR )
                            asp->mode = FREE;
         _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); */
                    }
                }
   Purify Heap Analysis (combining suppressed and unsuppressed blocks)
                            Blocks        Bytes
                 Leaked          3           47
     Potentially Leaked         13         8290
                 In-Use        656        93428
     ----------------------------------------
        Total Allocated        672       101765
 

To summarize: At line 891 of the file snmp_agent.c In the function handle_one_var, there is some memory allocated (for variable saved->statP), and the pointer on this new memory will be lost latter. Thus this memory cannot be freed.


Thanks in advance for any coment or bug fixes...



    Jerome

Re: Regarding usage of pass directive in snmpd.conf file.

[Sumathi G. <su...@cc...>]

following up on my 2 previous mails ..
I issued the command : 'snmpwalk peacock public ucdSnmpAgent' and got 
the result : 'End of MIB'

Following was a portion of the debugging output on the agent side :
'

trace: asn_parse_objid(): asn1.c, 880
dump_recv:         ASN ObjID: enterprises.ucdavis.ucdSnmpAgent
trace: asn_parse_header(): asn1.c, 590
dump_recv:       05 00
trace: asn_parse_header(): asn1.c, 590
dump_recv:         ASN Header: 0x05, len = 0 (0x0)
trace: snmp_call_callbacks(): callback.c, 89
callback: START calling callbacks for maj=1 min=5
trace: snmp_call_callbacks(): callback.c, 95
callback: calling a callback for maj=1 min=5
trace: vacm_in_view(): mibgroup/mibII/vacm_vars.c, 638
mibII/vacm_vars: vacm_in_view: ver=0, source=0100007f, community=public
trace: vacm_in_view(): mibgroup/mibII/vacm_vars.c, 676
mibII/vacm_vars: vacm_in_view: sn=notConfigUser, gn=notConfigGroup, Done 
checking setup
trace: snmp_call_callbacks(): callback.c, 102
callback: END calling callbacks for maj=1 min=5
trace: getStatPtr(): snmp_vars.c, 422
snmp_vars: Looking for: enterprises.ucdavis.ucdSnmpAgent ...
trace: getStatPtr(): snmp_vars.c, 429
snmp_vars: Trying tree: .iso ...
trace: getStatPtr(): snmp_vars.c, 429
snmp_vars: Trying tree: enterprises.ucdavis.255 ...
trace: search_subtree_vars(): snmp_vars.c, 312
snmp_vars: Trying variable: enterprises.ucdavis.255 ...
trace: var_extensible_pass(): mibgroup/ucd-snmp/pass.c, 212
ucd-snmp/pass: pass-running:  /bin/sh 
/usr/doc/ucd-snmp-4.1.1/local/passtest  -n .1.3.6.1.4.1.2021.255
trace: search_subtree_vars(): snmp_vars.c, 320
snmp_vars: Returned (null)
trace: search_subtree_vars(): snmp_vars.c, 338
snmp_vars: evil_client: enterprises.ucdavis.ucdSnmpAgent =>.iso
trace: getStatPtr(): snmp_vars.c, 429
snmp_vars: Trying tree: .iso ...
trace: getStatPtr(): snmp_vars.c, 429
snmp_vars: Trying tree: 
.iso.org.dod.internet.snmpV2.snmpModules.snmpFrameworkMIB.snmpFrameworkMIBObjects.snmpEngine 
...

'

which means that it is indeed recognizing the MIB OID!! but it returns 
no information to the Manager !! My guess is that the problem is with 
the 'view' being 'systemviewtrace' , sn being notConfigUser etc.

PLease clarify..

Thankyou,
Sumathi Gopal
Research Associate,
C&C Research Labs, NEC USA Inc.

Perl SNMP doc update questions

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

trying to update the perl/SNMP docs a bit to be inkeeping with the new
location and name etc.

Is there an ftp:// url I can use for source access or do we force peopl
to go through the web page?

I was also thinking to synchronize the the Perl SNMP  module version
number with the NET-SNMP version number...at least in the first two
positions. so when x.y.z of NET-SNMP goes out the Perl SNMP module will
always be at least x.y.0. thoughts?

last bit of administravia - there is a Net::SNMP perl module out on CPAN
currently and there is already some level of confusion between our SNMP
module and that one. I expect that level to rise some...I guess this is
just fair warning seeing as its too late to change the name again.
Ideally our perl SNMP module would be named Net::SNMP but I don't see
that happening either.

regards, GSM

Re: latest cvs source segvs on linux 2.2.12-20 (egcs-2.91.66)

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

Don't know how to explain it but I did a make distclean with the latest from
cvs and now the segv's went away. Don't have time to figure it out but my
guess is that there was some stack corruption...??

-GSM


Michael Slifcak wrote:

> Are you loading non-English NLS (nat'l language support)
> or setting the LANG environment ?  Is your compiler doing this ?
>
> Which platform/OS/Version compiler/version are you using ?
>
> "G. S. Marzot" wrote:
> >
> > I am getting all tests failing and segv just starting up any of the
> > apps. It looks like it croaks in MIB parsing but in a very improbable
> > place so I am guessing stack corruption. electric fence is running but I
> > guess this does not catch all stack overwrites. I don't suppose this is
> > happening for anyone but me otherwise there would be more hew-and-cry.
> > perhaps my environement is hosed but nothing showed up like this before
> >
> > [ gmarzot@donzi net-snmp]$ apps/snmpwalk localhost public .1
> >
> >   Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
> > Segmentation fault (core dumped)
> >
> > [gmarzot@donzi net-snmp]$ gdb -c core snmpwalk
> > GNU gdb 4.18
> > Copyright 1998 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "i386-redhat-linux"...
> > Core was generated by `apps/snmpwalk -Dall localhost public .1'.
> > Program terminated with signal 11, Segmentation fault.
> > Reading symbols from /lib/libdl.so.2...done.
> > Reading symbols from /usr/lib/librpm.so.0...done.
> > Reading symbols from /lib/libdb.so.2...done.
> > Reading symbols from /usr/lib/libz.so.1...done.
> > Reading symbols from /lib/libm.so.6...done.
> > Reading symbols from /lib/libc.so.6...done.
> > Reading symbols from /lib/ld-linux.so.2...done.
> > Reading symbols from /usr/lib/libbz2.so.0...done.
> > Reading symbols from /lib/libnss_files.so.2...done.
> > Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
> > #0  gconv (step=0x410d3fc8, data=0xbfffde7c, inbuf=0xbfffde70,
> >     inbufend=0x40176d24 "", written=0xbfffde74, do_flush=0)
> >     at ../iconv/skeleton.c:204
> > 204 ../iconv/skeleton.c: No such file or directory.
> > (gdb) where
> > #0  gconv (step=0x410d3fc8, data=0xbfffde7c, inbuf=0xbfffde70,
> >     inbufend=0x40176d24 "", written=0xbfffde74, do_flush=0)
> >     at ../iconv/skeleton.c:204
> > #1  0x400f893b in __mbrtowc (pwc=0xbfffdf64, s=0x40176d23 ".", n=1,
> >     ps=0xbfffdf68) at mbrtowc.c:67
> > #2  0x400e30f6 in _IO_vfscanf (s=0xbfffdfd4,
> >     format=0x80957d1 "%2d%2d%2d%2d%2d", argptr=0xbfffe09c, errp=0x0)
> >     at vfscanf.c:254
> > #3  0x400e896e in _IO_vsscanf (string=0xbffff0f0 "9411010000Z",
> >     format=0x80957d1 "%2d%2d%2d%2d%2d", args=0xbfffe09c) at
> > iovsscanf.c:44
> > #4  0x400e673f in sscanf (s=0xbffff0f0 "9411010000Z",
> >     format=0x80957d1 "%2d%2d%2d%2d%2d") at sscanf.c:38
> > #5  0x8053519 in check_utc (utc=0xbffff0f0 "9411010000Z") at
> > parse.c:2880
> > #6  0x805365b in parse_moduleIdentity (fp=0x40425f50, name=0xbffff1b0
> > "ipMIB")
> >     at parse.c:2925
> > #7  0x8055122 in parse (fp=0x40425f50, root=0x0) at parse.c:3788
> > #8  0x8054279 in read_module_internal (name=0x40421f10 "IP-MIB")
> >     at parse.c:3294
> > #9  0x8054411 in read_module (name=0x40421f10 "IP-MIB") at parse.c:3361
> > #10 0x804cdee in init_mib () at mib.c:1189
> > #11 0x8056f21 in init_snmp (type=0x80992c0 "snmpapp") at snmp_api.c:638
> > #12 0x8067e2a in snmp_parse_args (argc=5, argv=0xbffffcb4,
> > session=0xbffffb9c,
> >     localOpts=0x8092929 "C:", proc=0x804a010 <optProc>)
> > ---Type <return> to continue, or q <return> to quit---
> >     at snmp_parse_args.c:411
> > #13 0x804a0e3 in main (argc=5, argv=0xbffffcb4) at snmpwalk.c:169
> > (
> >
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...
> > http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders

RE: 4.2.pre2 available

[RADMAN S. <Ste...@CT...>]

Tested on Solaris 2.6
configured with-mib-modules: host smux target notification agentx
ucd-snmp/diskio ucd-snmp/dlmod
All 31(!) tests passed (21,22,28 SKIPPED)
quick glance at snmpwalk output looks good

This was the quickest build out of the box ever :)

Stefan
---------
Stefan Radman
Network Specialist
CTBTO/IDC
Email:	mailto://Ste...@ct...
Phone:	+43 (1) 26030-6182
Fax:	+43 (1) 260308-6182

Re: Using C multiple OIDS in a single ASYNC packet.

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

On Sun, 19 Nov 2000 23:31:55 -0800 "Daniel L. Needles" <dne...@jp...> wrote:
>Niel & all,
>  I think I found it.  How do you increase the socket limit?  I tried
>bumping up  /proc/sys/fs/file-max without impact.  However, I didn't reboot.
>Is that necessisary?  Is there another parm that handles the socket limit on
>UNIX?

You don't have to quote the whole conversation in each mail.

setrlimit can change the per-process limit on many Unix variants, at least
Linux, Solaris and *BSD. If you hit a system-wide limit, you may need to
recompile the kernel after changing some #define (doesn't apply to Solaris :-).

/Niels

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

Re: Using C multiple OIDS in a single ASYNC packet.

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

On Sun, 19 Nov 2000 20:12:22 -0800 "Daniel L. Needles" <dne...@jp...> wrote:
>Niels & others,
>  Ah, I spoke too soon!  The memory over ride is unrelated.  I have found
>the following behavior on:
>
>Sollaris 2.6 using 4.1.2 I get upto only 73 packets before getting the
>error:
>Linux Red Hat 3 2.2.14-5.0 fares better getting to 1021 packets before
>getting the error.
>
>After that point any further attempts to instaniate a session error with a
>call to snmp_open():
>
>snmp_open: Unknown host (hostname)
>
>This happens even for the same hostnames that worked in previous calls! Any
>ideas on what resource I have to increase?

Number of open file (maybe settable with setrlimit). But actually you dont need
a session per remote host, unless you use SNMPv3. You can set peer address and
community directly in the pdu. The session is strictly required for SNMPv3,
because it holds discovered engineID information.

/Niels

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

Re: Using C multiple OIDS in a single ASYNC packet.

[Daniel L. N. <dne...@jp...>]

Niel & all,
  I think I found it.  How do you increase the socket limit?  I tried
bumping up  /proc/sys/fs/file-max without impact.  However, I didn't reboot.
Is that necessisary?  Is there another parm that handles the socket limit on
UNIX?

Thanks,
Daniel L. Needles

----- Original Message -----
From: Daniel L. Needles <dne...@jp...>
To: Daniel L. Needles <dne...@jp...>; <ni...@ba...>;
<net...@li...>
Sent: Sunday, November 19, 2000 8:12 PM
Subject: Re: Using C multiple OIDS in a single ASYNC packet.


> Niels & others,
>   Ah, I spoke too soon!  The memory over ride is unrelated.  I have found
> the following behavior on:
>
> Sollaris 2.6 using 4.1.2 I get upto only 73 packets before getting the
> error:
> Linux Red Hat 3 2.2.14-5.0 fares better getting to 1021 packets before
> getting the error.
>
> After that point any further attempts to instaniate a session error with a
> call to snmp_open():
>
> snmp_open: Unknown host (hostname)
>
> This happens even for the same hostnames that worked in previous calls!
Any
> ideas on what resource I have to increase?  Increasing or decreasing the
> number of oids doesn't effect the behavior. It definitely seems to be some
> sort of session limit.  What resources do sessions take up?
>
> Thanks,
> Daniel L. Needles
>
>
> ----- Original Message -----
> From: Daniel L. Needles <dne...@jp...>
> To: <ni...@ba...>; <net...@li...>
> Sent: Sunday, November 19, 2000 7:52 PM
> Subject: Re: Using C multiple OIDS in a single ASYNC packet.
>
>
> > Niels,
> >   Never mind. I over ran the table causing the abnormal errors. My fault
> for
> > not looking more carefully.
> >
> > Thanks,
> > Daniel L. Needles
> >
> > ----- Original Message -----
> > From: Daniel L. Needles <dne...@jp...>
> > To: <ni...@ba...>; <net...@li...>
> > Sent: Sunday, November 19, 2000 2:57 PM
> > Subject: Re: Using C multiple OIDS in a single ASYNC packet.
> >
> >
> > > Niels,
> > > Thanks again for all your help.  I've run into a little problem. I got
> the
> > > async thing with multiple oids working. However, I'm running into a
> limit
> > of
> > > 73 SESSIONs.
> > >
> > > I create a session for each node query of 5 oids.  After 73
snmp_open()
> > > things grind to a halt and I get the error:
> > > snmp_open: Unknown host (hostname1)
> > > for each sucessive attempt to snmp_open() after a timeout of about 5
> > > seconds.
> > >
> > > I decreased the oid count to 3 for each node and still it stalls at
73.
> > So
> > > I'm assuming this is not a memory problem but some limit with
SESSIONS.
> > >
> > > What limitation have I ran into?
> > > Is there a way to increase the limit?  I was hoping to get to at least
> 1K.
> > >
> > > Thanks,
> > > Daniel L. Needles
> > > ----- Original Message -----
> > > From: <ni...@ba...>
> > > To: <dne...@jp...>; <net...@li...>
> > > Sent: Sunday, November 19, 2000 7:40 AM
> > > Subject: Re: Using C multiple OIDS in a single ASYNC packet.
> > >
> > >
> > > > On Sun, 19 Nov 2000 04:36:57 -0800 "Daniel L. Needles"
> > <dne...@jp...>
> > > wrote:
> > > > >
> > > > >  To the "larger" question. Is there any docs on these calls or are
> > they
> > > in
> > > > >"true engineering spirit" self documenting code?  8~)
> > > >
> > > > Currently yes, it seems. These are part of a partially documented
api
> > that
> > > we
> > > > "enherited", but we do try to catch up when someone point out
> something
> > is
> > > > missing.
> > > >
> > > >
> > > > Maybe I will throw some documentation together, but the apps
directory
> > is
> > > in
> > > > many areas THE documentation.
> > > >
> > > > /Niels
> > > >
> > > > --
> > > > Get your firstname@lastname email for FREE at
> http://Nameplanet.com/?su
> > > > _______________________________________________
> > > > Net-snmp-coders mailing list
> > > > Net...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
> > > >
> > >
> > > _______________________________________________
> > > Net-snmp-coders mailing list
> > > Net...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
> > >
> >
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...
> > http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
> >
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
>

Re: Using C multiple OIDS in a single ASYNC packet.

[Daniel L. N. <dne...@jp...>]

Niels & others,
  Ah, I spoke too soon!  The memory over ride is unrelated.  I have found
the following behavior on:

Sollaris 2.6 using 4.1.2 I get upto only 73 packets before getting the
error:
Linux Red Hat 3 2.2.14-5.0 fares better getting to 1021 packets before
getting the error.

After that point any further attempts to instaniate a session error with a
call to snmp_open():

snmp_open: Unknown host (hostname)

This happens even for the same hostnames that worked in previous calls! Any
ideas on what resource I have to increase?  Increasing or decreasing the
number of oids doesn't effect the behavior. It definitely seems to be some
sort of session limit.  What resources do sessions take up?

Thanks,
Daniel L. Needles


----- Original Message -----
From: Daniel L. Needles <dne...@jp...>
To: <ni...@ba...>; <net...@li...>
Sent: Sunday, November 19, 2000 7:52 PM
Subject: Re: Using C multiple OIDS in a single ASYNC packet.


> Niels,
>   Never mind. I over ran the table causing the abnormal errors. My fault
for
> not looking more carefully.
>
> Thanks,
> Daniel L. Needles
>
> ----- Original Message -----
> From: Daniel L. Needles <dne...@jp...>
> To: <ni...@ba...>; <net...@li...>
> Sent: Sunday, November 19, 2000 2:57 PM
> Subject: Re: Using C multiple OIDS in a single ASYNC packet.
>
>
> > Niels,
> > Thanks again for all your help.  I've run into a little problem. I got
the
> > async thing with multiple oids working. However, I'm running into a
limit
> of
> > 73 SESSIONs.
> >
> > I create a session for each node query of 5 oids.  After 73 snmp_open()
> > things grind to a halt and I get the error:
> > snmp_open: Unknown host (hostname1)
> > for each sucessive attempt to snmp_open() after a timeout of about 5
> > seconds.
> >
> > I decreased the oid count to 3 for each node and still it stalls at 73.
> So
> > I'm assuming this is not a memory problem but some limit with SESSIONS.
> >
> > What limitation have I ran into?
> > Is there a way to increase the limit?  I was hoping to get to at least
1K.
> >
> > Thanks,
> > Daniel L. Needles
> > ----- Original Message -----
> > From: <ni...@ba...>
> > To: <dne...@jp...>; <net...@li...>
> > Sent: Sunday, November 19, 2000 7:40 AM
> > Subject: Re: Using C multiple OIDS in a single ASYNC packet.
> >
> >
> > > On Sun, 19 Nov 2000 04:36:57 -0800 "Daniel L. Needles"
> <dne...@jp...>
> > wrote:
> > > >
> > > >  To the "larger" question. Is there any docs on these calls or are
> they
> > in
> > > >"true engineering spirit" self documenting code?  8~)
> > >
> > > Currently yes, it seems. These are part of a partially documented api
> that
> > we
> > > "enherited", but we do try to catch up when someone point out
something
> is
> > > missing.
> > >
> > >
> > > Maybe I will throw some documentation together, but the apps directory
> is
> > in
> > > many areas THE documentation.
> > >
> > > /Niels
> > >
> > > --
> > > Get your firstname@lastname email for FREE at
http://Nameplanet.com/?su
> > > _______________________________________________
> > > Net-snmp-coders mailing list
> > > Net...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
> > >
> >
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...
> > http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
> >
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
>

Re: Using C multiple OIDS in a single ASYNC packet.

[Daniel L. N. <dne...@jp...>]

Niels,
  Never mind. I over ran the table causing the abnormal errors. My fault for
not looking more carefully.

Thanks,
Daniel L. Needles

----- Original Message -----
From: Daniel L. Needles <dne...@jp...>
To: <ni...@ba...>; <net...@li...>
Sent: Sunday, November 19, 2000 2:57 PM
Subject: Re: Using C multiple OIDS in a single ASYNC packet.


> Niels,
> Thanks again for all your help.  I've run into a little problem. I got the
> async thing with multiple oids working. However, I'm running into a limit
of
> 73 SESSIONs.
>
> I create a session for each node query of 5 oids.  After 73 snmp_open()
> things grind to a halt and I get the error:
> snmp_open: Unknown host (hostname1)
> for each sucessive attempt to snmp_open() after a timeout of about 5
> seconds.
>
> I decreased the oid count to 3 for each node and still it stalls at 73.
So
> I'm assuming this is not a memory problem but some limit with SESSIONS.
>
> What limitation have I ran into?
> Is there a way to increase the limit?  I was hoping to get to at least 1K.
>
> Thanks,
> Daniel L. Needles
> ----- Original Message -----
> From: <ni...@ba...>
> To: <dne...@jp...>; <net...@li...>
> Sent: Sunday, November 19, 2000 7:40 AM
> Subject: Re: Using C multiple OIDS in a single ASYNC packet.
>
>
> > On Sun, 19 Nov 2000 04:36:57 -0800 "Daniel L. Needles"
<dne...@jp...>
> wrote:
> > >
> > >  To the "larger" question. Is there any docs on these calls or are
they
> in
> > >"true engineering spirit" self documenting code?  8~)
> >
> > Currently yes, it seems. These are part of a partially documented api
that
> we
> > "enherited", but we do try to catch up when someone point out something
is
> > missing.
> >
> >
> > Maybe I will throw some documentation together, but the apps directory
is
> in
> > many areas THE documentation.
> >
> > /Niels
> >
> > --
> > Get your firstname@lastname email for FREE at http://Nameplanet.com/?su
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...
> > http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
> >
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
>

Re: Using C multiple OIDS in a single ASYNC packet.

[Daniel L. N. <dne...@jp...>]

Niels,
Thanks again for all your help.  I've run into a little problem. I got the
async thing with multiple oids working. However, I'm running into a limit of
73 SESSIONs.

I create a session for each node query of 5 oids.  After 73 snmp_open()
things grind to a halt and I get the error:
snmp_open: Unknown host (hostname1)
for each sucessive attempt to snmp_open() after a timeout of about 5
seconds.

I decreased the oid count to 3 for each node and still it stalls at 73.  So
I'm assuming this is not a memory problem but some limit with SESSIONS.

What limitation have I ran into?
Is there a way to increase the limit?  I was hoping to get to at least 1K.

Thanks,
Daniel L. Needles
----- Original Message -----
From: <ni...@ba...>
To: <dne...@jp...>; <net...@li...>
Sent: Sunday, November 19, 2000 7:40 AM
Subject: Re: Using C multiple OIDS in a single ASYNC packet.


> On Sun, 19 Nov 2000 04:36:57 -0800 "Daniel L. Needles" <dne...@jp...>
wrote:
> >
> >  To the "larger" question. Is there any docs on these calls or are they
in
> >"true engineering spirit" self documenting code?  8~)
>
> Currently yes, it seems. These are part of a partially documented api that
we
> "enherited", but we do try to catch up when someone point out something is
> missing.
>
>
> Maybe I will throw some documentation together, but the apps directory is
in
> many areas THE documentation.
>
> /Niels
>
> --
> Get your firstname@lastname email for FREE at http://Nameplanet.com/?su
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders
>

Re: 4.2.pre2 available

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

On 18 Nov 2000, Wes Hardaker wrote:

> ucd-snmp-4.2.pre2 is now available [...]

Tested on FreeBSD 4.0 and BSD/OS 4.1. All relevant tests pass, visual
inspection of snmpwalk looks good...

I'm impressed with the test harness... Works really well.

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: recent range checking additions...

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

On 17 Nov 2000 08:28:44 -0800 Wes Hardaker <wjh...@uc...> wrote:
>>>>>> On 17 Nov 2000 08:14:52 -0000, ni...@ba... (Niels Baggesen) said:
>
>Niels> Yes, I want it to do that too, but your threat about a pre2
>Niels> made me do the check-in, so that I could get some more testers.
>
>:-)  I noticed the problem because it broke some of the recent testing
>scripts I've written...

These test scripts are eally nice. Even though I am no perl-hacker I even
tried to run the perl test, but that was really dissapointing. I am just now
trying to see what I can fix there.

/Niels

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

Re: difficulty with mibs

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

On Thu, 16 Nov 2000 16:36:09 -0500 (EST) Jas...@ms... wrote:
>	hi all -- i'm attempting to set up net-snmp here..."most" of the
>mibs work fine (i.e. snmpget and snmpwalk give appropriate results)...but
>for some reason, some (seems like specifically those that require details
>in snmpd.conf) like:

Are you sure it is reding the snmpd.conf as you expect?

>after running snmpwalk as listed above, we get nothing...using -D on the
>daemon does verify that these modules are registered...but this part of
>the tree remains empty...

The modules are registered, but are the configuration lines read? 

>can anyone shed some light on why this behavior is happening?  i did read
>the FAQ and made sure i did all of the recommended suggestions...

How did you install ucd-snmp, and where did you put snmpd.conf? The -Dread_conf
parameter to snmpd may shed some light on this.

/Niels

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

Re: Using C multiple OIDS in a single ASYNC packet.

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

On Sun, 19 Nov 2000 04:36:57 -0800 "Daniel L. Needles" <dne...@jp...> wrote:
>
>  To the "larger" question. Is there any docs on these calls or are they in
>"true engineering spirit" self documenting code?  8~)

Currently yes, it seems. These are part of a partially documented api that we
"enherited", but we do try to catch up when someone point out something is
missing.


Maybe I will throw some documentation together, but the apps directory is in
many areas THE documentation.

/Niels

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