net-snmp-patches — Patch database updates (DO NOT POST TO THIS LIST - use "Patches" link above)

[Net-snmp-patches] create_user_from_session is removed from snmp_api.c between net-snmp version 5.5 to 5.7.2-20

[Hegde, R. (CMS) <ra...@hp...>]

Hello All,
 
Problem Description: In the below snmp_api.c red part is missing in 5.7.2
version of net-snmp but  present in version 5.5
 
In snmp_api.c,
 
In function
static int
_sess_async_send(void *sessp,
                 netsnmp_pdu *pdu, snmp_callback callback, void *cb_data)
{
 
.
..
  /*
     * check to see if we need a v3 engineID probe
     */
    if ((pdu->version == SNMP_VERSION_3) &&
        (pdu->flags & UCD_MSG_FLAG_EXPECT_RESPONSE) &&
        (session->securityEngineIDLen == 0) &&
        (0 == (session->flags & SNMP_FLAGS_DONT_PROBE))) {
        int rc;
        DEBUGMSGTL(("snmpv3_build", "delayed probe for engineID\n"));
        rc = snmpv3_engineID_probe(slp, session);
        if (rc == 0)
            return 0; /* s_snmp_errno already set */
    }
 
    /*
     * check to see if we need to create a v3 user from the session info
     */
    if (create_user_from_session(session) != SNMPERR_SUCCESS) {
        session->s_snmp_errno = SNMPERR_UNKNOWN_USER_NAME;  /* XX?? */
        DEBUGMSGTL(("snmp_api",
                    "snmp_send(): failed(2) to create a new user from
session\n"));
        return 0;
    }
 
    if ((pktbuf = (u_char *)malloc(2048)) == NULL) {
        DEBUGMSGTL(("sess_async_send",
                    "couldn't malloc initial packet buffer\n"));
        session->s_snmp_errno = SNMPERR_MALLOC;
        return 0;
    } else {
        pktbuf_len = 2048;
    }
.
..
=======
 
Consequence:    It used to create user list from the session earlier and the
list is empty now since this function is no more invoked on latest version.
We are trying to send snmpv3 traps with security level authPriv using
net-snmp libraries which works fine on RHEL6 (net-snmp 2.5) and the same
fails on RHEL 7 with following error.  The error is logged from cimserver
since we use cimsever SNMPIndicationHandler for  sending SNMPV3 traps.
"cimserver[10724]: Failed to deliver an indication: Snmp Indication Handler
failed to send the trap: USM unknown security name (no such user exists)" 
 
 
Questions:
 
*         Why invocation of function create_user_from_session is removed on
5.7.2 version of net-snmp?
*         Is there any other way we can populate this list? Currently
whatever security name and authkey/privkey and Engine ID we are subscribing
using cimserver does not match with usm_user_list as it shows NULL.
 
Regards
 
Ramesh Hegde
Project Manager- ACE OCMP/USP-M

 <mailto:ra...@hp...> ra...@hp...
T +91 80 338 66486
M +91 8197863555
Hewlett-Packard Company
No.192, Whitefield Road
Bangalore, Karnataka, 560048
India

 <http://www.hp.com/> 
 
 
Follow us on:   <https://www.facebook.com/HP>    <https://twitter.com/HP>
<http://www.youtube.com/hp> 
 

[Net-snmp-patches] Monitoring Failed Disk

[Nadilson S. <nad...@gm...>]

Hy,

My name is Nadilson and live in brazil.

I have a Appliance with Avance and i'm trying monitoring if any disk
failed.  I get  snmpwalk information:

hrPartitionLabel.3103.1 = STRING: "node0: /dev/sda1"
hrPartitionLabel.3103.2 = STRING: "node0: /dev/sda2"
hrPartitionLabel.3103.3 = STRING: "node0: /dev/sda3"
hrPartitionLabel.3104.1 = STRING: "node1: /dev/sda1"
hrPartitionLabel.3104.2 = STRING: "node1: /dev/sda2"
hrPartitionLabel.3104.3 = STRING: "node1: /dev/sda3"

I retired the disk of appliance and execute snmpwalk again,but,not return
the information what i need. Could someone help me?



-- 
Nadilson S. Santana
Desenvolvedor de Soluções

[Net-snmp-patches] [ net-snmp-Patches-3585368 ] memory leak(s) in python bindings - Varbind

[SourceForge.net <no...@so...>]

Patches item #3585368, was opened at 2012-11-08 03:12
Message generated for change (Tracker Item Submitted) made by altego4441
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3585368&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: altego4441 (altego4441)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak(s) in python bindings - Varbind

Initial Comment:
In python bindings, Varbind vars were not always disposed of, leading to memory leaks. The fix is easy, please see attached patch (against latest stable version, 5.7.2).

I would be happy if this could be applied to core so I don't have to patch future versions.

Happy coding!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3585368&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3580458 ] snmpd crashes/hangs when subagent disconnects during GetNext

[SourceForge.net <no...@so...>]

Patches item #3580458, was opened at 2012-10-26 01:42
Message generated for change (Comment added) made by jcervenka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jiri Cervenka (jcervenka)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmpd crashes/hangs when subagent disconnects during GetNext

Initial Comment:
This is my attempt to extend patch 1633670. This patch is created
against 5.7.2 plus patch 1633670.

Problems addressed:

1) Inifinite loop in delegated requests removal

In my opionion, the for-loop iteration on asp->requests in
netsnmp_remove_delegated_requests_for_session() is incorrect, as it
may end up flagging only a subset of asp's requests (depending on how
many different subtrees (and hence treecaches) this asp's requests
OIDs fall in). 

The loop situation occurs when the asp->requests[0] request has
already been answered (and is not part of any treecache), whereas some
other requests on this asp still have the delegated flag on
(reproducible by GetNext requests which contain both a variable
pointing to subtree belonging to the closing session, and another one
pointing to a range preceding that very subtree (but not fulfilled by
any preceding handler).

I think this for-loop should walk all asp->vbcount items on the
asp->requests array instead.

2) Crashes on dangling subtree pointers after AgentX Close PDU

The same crash patterns as those described in patch 1633670 appear
when a session gets closed via an explicit Close PDU from a subagent.
So, I think we need to go through the remove delegated requests loop
also when a valid sessid has been passed to close_agentx_session().

Adding this change caused double frees on delegated caches in
agentx_got_response() ('response is too late') -- apparently caused by
responses to retries, and also by callback from snmp_sess_close(). I
think this can be fixed by returning 1 from agentx_got_response() on
this occasion, thus letting _sess_process_packet() delete the request
from the session pending requests list.


Tested with 5.7.2 w/ patch 1633670, on x86_64 Linux, RHEL 5.5.

I tested the patch also with the subagent and traffic generating
script attached to bug 3565004 -- and it worked for me.


----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-11-07 11:21

Message:
Uploaded alt-cancel-next-walk-v2.patch.

We don't want to start handling queued requests (from
netsnmp_agent_queued_list) when on the close session path. Decoupled
the delegated list check into a new function.


----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-11-06 08:12

Message:
While running some additional tests I have hit another inifinite loop
around delegated requests removal (this one triggered by requests
containing OIDs delegated to multiple different subagents).

This got me thinking whether the iterate-next-loop approach taken by
patch 1633670 is really necessary (it seems to me that -- apart from
the infinite loop risk -- there is also the effect of pausing new
request processing by favouring next loop iteration for a subset of
requests).

I am currently testing an alternative approach (uploaded as
alt-cancel-next-walk.patch). The basic idea is to a) mark the whole
asp explicitly as canceled (we cannot rely on the 'delegated' flag
alone), and b) break out of the next walk when cancel is in progress
(the asp is destined to fail with genError anyway).

While this patch has so far passed my crash/leak tests, I consider it
to be of preliminary status (I am aware of several open questions,
e.g. I don't like the idea of adding a new variable to
netsnmp_agent_session structure).

The patch is created against plain 5.7.2.

Any feedback gladly welcome.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-11-01 05:14

Message:
OK, with the right version of the 1633670 patch, that works a lot better!

Passes my tests (flat out traffic generation into both our production
application and the test subagent at the same time) and also a looped
SNMP-SET test (which was the original problem that got us started down the
1633670 patch road).

With the inevitable large queues of pending transactions generated by these
tests, the SET test does cause the snmpd to pause a bit, but it never falls
over, and always comes back and starts responding, with SETs still
operational.  It also seems to pass valgrind pretty much.

We're going to deploy the patched 5.7.2 into automated test, and create a
formal patch of our system for further testing next week.

Overall though, this looks like a winner.

Thanks very much, you've succeeded where we had failed miserably!

Ken.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 09:19

Message:
Thanks for that, I'll re-test with the updated 1633670 and 5.7.2 stock -
testing with my hacked together version stayed up for about 2 hours, but
then started hanging up for long periods and chewing up memory.

Much better than anything that we achieved, but not quite there yet - I'll
tell you how testing went after it has had an overnight soak.

----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-10-29 05:52

Message:
Tha patch is meant to be applied against the final version of the patch
1633670 committed on trunk,
i.e. the 43cd9db4 commit 'CHANGES: PATCH 1633670: fixed snmpd crashing when
an AgentX subagent disconnect in the middle of processing of a request.'.

The final version contains two additional delegated cache memory leaks
fixes.

I have added the final version to this tracker artifact as
'patch-1633670-commit.patch'.

Sorry for confusion.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 05:17

Message:
Thanks for the patch!

Having problems applying it to 5.7.2 though, as the patch fails when
applied to the released 5.7.2 tarball after applying the final (v3) 1633670
patch.

Failed chunk is:

more master.c.rej
***************
*** 219,228 ****
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
-         /* response is too late, free the cache */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
-         return 0;
      }
      requests = cache->requests;

--- 219,231 ----
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
+         /*
+          * Response is too late, free the cache and return 1
+          * so that the session pending request list item can be deleted
+          */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
+         return 1;
      }
      requests = cache->requests;

Fails because:

          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);

isn't present, am I missing a patch to be applied to 5.7.2? Or am I working
with the wrong version of the original patch?

Meanwhile, I've manually applied the change and I'm testing with that - has
not crashed yet...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3580458 ] snmpd crashes/hangs when subagent disconnects during GetNext

[SourceForge.net <no...@so...>]

Patches item #3580458, was opened at 2012-10-26 01:42
Message generated for change (Comment added) made by jcervenka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jiri Cervenka (jcervenka)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmpd crashes/hangs when subagent disconnects during GetNext

Initial Comment:
This is my attempt to extend patch 1633670. This patch is created
against 5.7.2 plus patch 1633670.

Problems addressed:

1) Inifinite loop in delegated requests removal

In my opionion, the for-loop iteration on asp->requests in
netsnmp_remove_delegated_requests_for_session() is incorrect, as it
may end up flagging only a subset of asp's requests (depending on how
many different subtrees (and hence treecaches) this asp's requests
OIDs fall in). 

The loop situation occurs when the asp->requests[0] request has
already been answered (and is not part of any treecache), whereas some
other requests on this asp still have the delegated flag on
(reproducible by GetNext requests which contain both a variable
pointing to subtree belonging to the closing session, and another one
pointing to a range preceding that very subtree (but not fulfilled by
any preceding handler).

I think this for-loop should walk all asp->vbcount items on the
asp->requests array instead.

2) Crashes on dangling subtree pointers after AgentX Close PDU

The same crash patterns as those described in patch 1633670 appear
when a session gets closed via an explicit Close PDU from a subagent.
So, I think we need to go through the remove delegated requests loop
also when a valid sessid has been passed to close_agentx_session().

Adding this change caused double frees on delegated caches in
agentx_got_response() ('response is too late') -- apparently caused by
responses to retries, and also by callback from snmp_sess_close(). I
think this can be fixed by returning 1 from agentx_got_response() on
this occasion, thus letting _sess_process_packet() delete the request
from the session pending requests list.


Tested with 5.7.2 w/ patch 1633670, on x86_64 Linux, RHEL 5.5.

I tested the patch also with the subagent and traffic generating
script attached to bug 3565004 -- and it worked for me.


----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-11-06 08:12

Message:
While running some additional tests I have hit another inifinite loop
around delegated requests removal (this one triggered by requests
containing OIDs delegated to multiple different subagents).

This got me thinking whether the iterate-next-loop approach taken by
patch 1633670 is really necessary (it seems to me that -- apart from
the infinite loop risk -- there is also the effect of pausing new
request processing by favouring next loop iteration for a subset of
requests).

I am currently testing an alternative approach (uploaded as
alt-cancel-next-walk.patch). The basic idea is to a) mark the whole
asp explicitly as canceled (we cannot rely on the 'delegated' flag
alone), and b) break out of the next walk when cancel is in progress
(the asp is destined to fail with genError anyway).

While this patch has so far passed my crash/leak tests, I consider it
to be of preliminary status (I am aware of several open questions,
e.g. I don't like the idea of adding a new variable to
netsnmp_agent_session structure).

The patch is created against plain 5.7.2.

Any feedback gladly welcome.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-11-01 05:14

Message:
OK, with the right version of the 1633670 patch, that works a lot better!

Passes my tests (flat out traffic generation into both our production
application and the test subagent at the same time) and also a looped
SNMP-SET test (which was the original problem that got us started down the
1633670 patch road).

With the inevitable large queues of pending transactions generated by these
tests, the SET test does cause the snmpd to pause a bit, but it never falls
over, and always comes back and starts responding, with SETs still
operational.  It also seems to pass valgrind pretty much.

We're going to deploy the patched 5.7.2 into automated test, and create a
formal patch of our system for further testing next week.

Overall though, this looks like a winner.

Thanks very much, you've succeeded where we had failed miserably!

Ken.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 09:19

Message:
Thanks for that, I'll re-test with the updated 1633670 and 5.7.2 stock -
testing with my hacked together version stayed up for about 2 hours, but
then started hanging up for long periods and chewing up memory.

Much better than anything that we achieved, but not quite there yet - I'll
tell you how testing went after it has had an overnight soak.

----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-10-29 05:52

Message:
Tha patch is meant to be applied against the final version of the patch
1633670 committed on trunk,
i.e. the 43cd9db4 commit 'CHANGES: PATCH 1633670: fixed snmpd crashing when
an AgentX subagent disconnect in the middle of processing of a request.'.

The final version contains two additional delegated cache memory leaks
fixes.

I have added the final version to this tracker artifact as
'patch-1633670-commit.patch'.

Sorry for confusion.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 05:17

Message:
Thanks for the patch!

Having problems applying it to 5.7.2 though, as the patch fails when
applied to the released 5.7.2 tarball after applying the final (v3) 1633670
patch.

Failed chunk is:

more master.c.rej
***************
*** 219,228 ****
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
-         /* response is too late, free the cache */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
-         return 0;
      }
      requests = cache->requests;

--- 219,231 ----
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
+         /*
+          * Response is too late, free the cache and return 1
+          * so that the session pending request list item can be deleted
+          */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
+         return 1;
      }
      requests = cache->requests;

Fails because:

          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);

isn't present, am I missing a patch to be applied to 5.7.2? Or am I working
with the wrong version of the original patch?

Meanwhile, I've manually applied the change and I'm testing with that - has
not crashed yet...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3559420 ] support OpenBSD 5.x kvm_getprocs

[SourceForge.net <no...@so...>]

Patches item #3559420, was opened at 2012-08-19 06:02
Message generated for change (Comment added) made by nba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3559420&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: sthen (sthen23934)
>Assigned to: Niels Baggesen (nba)
Summary: support OpenBSD 5.x kvm_getprocs

Initial Comment:
Since OpenBSD 5.0 the transitional name kvm_getproc2() was renamed to kvm_getprocs and associated struct kinfo_proc2 renamed to kinfo_proc. Attached diff handles this change.

This has been used in our port for a while and doesn't change things for other OS.

----------------------------------------------------------------------

Comment By: Niels Baggesen (nba)
Date: 2012-11-05 12:26

Message:
Thanks for the patch!  It has been applied to the 5.5.x and later code
branches and the main development tree, and will appear in future releases
of the Net-SNMP package.

----------------------------------------------------------------------

Comment By: sthen (sthen23934)
Date: 2012-08-29 15:07

Message:
obsd5_kvm_getprocs.2.diff is updated following nba's commits in this area.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3559420&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3580458 ] snmpd crashes/hangs when subagent disconnects during GetNext

[SourceForge.net <no...@so...>]

Patches item #3580458, was opened at 2012-10-26 01:42
Message generated for change (Comment added) made by kenfagilent
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jiri Cervenka (jcervenka)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmpd crashes/hangs when subagent disconnects during GetNext

Initial Comment:
This is my attempt to extend patch 1633670. This patch is created
against 5.7.2 plus patch 1633670.

Problems addressed:

1) Inifinite loop in delegated requests removal

In my opionion, the for-loop iteration on asp->requests in
netsnmp_remove_delegated_requests_for_session() is incorrect, as it
may end up flagging only a subset of asp's requests (depending on how
many different subtrees (and hence treecaches) this asp's requests
OIDs fall in). 

The loop situation occurs when the asp->requests[0] request has
already been answered (and is not part of any treecache), whereas some
other requests on this asp still have the delegated flag on
(reproducible by GetNext requests which contain both a variable
pointing to subtree belonging to the closing session, and another one
pointing to a range preceding that very subtree (but not fulfilled by
any preceding handler).

I think this for-loop should walk all asp->vbcount items on the
asp->requests array instead.

2) Crashes on dangling subtree pointers after AgentX Close PDU

The same crash patterns as those described in patch 1633670 appear
when a session gets closed via an explicit Close PDU from a subagent.
So, I think we need to go through the remove delegated requests loop
also when a valid sessid has been passed to close_agentx_session().

Adding this change caused double frees on delegated caches in
agentx_got_response() ('response is too late') -- apparently caused by
responses to retries, and also by callback from snmp_sess_close(). I
think this can be fixed by returning 1 from agentx_got_response() on
this occasion, thus letting _sess_process_packet() delete the request
from the session pending requests list.


Tested with 5.7.2 w/ patch 1633670, on x86_64 Linux, RHEL 5.5.

I tested the patch also with the subagent and traffic generating
script attached to bug 3565004 -- and it worked for me.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-11-01 05:14

Message:
OK, with the right version of the 1633670 patch, that works a lot better!

Passes my tests (flat out traffic generation into both our production
application and the test subagent at the same time) and also a looped
SNMP-SET test (which was the original problem that got us started down the
1633670 patch road).

With the inevitable large queues of pending transactions generated by these
tests, the SET test does cause the snmpd to pause a bit, but it never falls
over, and always comes back and starts responding, with SETs still
operational.  It also seems to pass valgrind pretty much.

We're going to deploy the patched 5.7.2 into automated test, and create a
formal patch of our system for further testing next week.

Overall though, this looks like a winner.

Thanks very much, you've succeeded where we had failed miserably!

Ken.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 09:19

Message:
Thanks for that, I'll re-test with the updated 1633670 and 5.7.2 stock -
testing with my hacked together version stayed up for about 2 hours, but
then started hanging up for long periods and chewing up memory.

Much better than anything that we achieved, but not quite there yet - I'll
tell you how testing went after it has had an overnight soak.

----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-10-29 05:52

Message:
Tha patch is meant to be applied against the final version of the patch
1633670 committed on trunk,
i.e. the 43cd9db4 commit 'CHANGES: PATCH 1633670: fixed snmpd crashing when
an AgentX subagent disconnect in the middle of processing of a request.'.

The final version contains two additional delegated cache memory leaks
fixes.

I have added the final version to this tracker artifact as
'patch-1633670-commit.patch'.

Sorry for confusion.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 05:17

Message:
Thanks for the patch!

Having problems applying it to 5.7.2 though, as the patch fails when
applied to the released 5.7.2 tarball after applying the final (v3) 1633670
patch.

Failed chunk is:

more master.c.rej
***************
*** 219,228 ****
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
-         /* response is too late, free the cache */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
-         return 0;
      }
      requests = cache->requests;

--- 219,231 ----
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
+         /*
+          * Response is too late, free the cache and return 1
+          * so that the session pending request list item can be deleted
+          */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
+         return 1;
      }
      requests = cache->requests;

Fails because:

          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);

isn't present, am I missing a patch to be applied to 5.7.2? Or am I working
with the wrong version of the original patch?

Meanwhile, I've manually applied the change and I'm testing with that - has
not crashed yet...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3582283 ] Subagent use tcp port 161 for agentx connection

[SourceForge.net <no...@so...>]

Patches item #3582283, was opened at 2012-10-31 11:09
Message generated for change (Comment added) made by bvassche
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3582283&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: qqshka (qqshka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Subagent use tcp port 161 for agentx connection

Initial Comment:
Bug introduced here http://net-snmp.git.sourceforge.net/git/gitweb.cgi?p=net-snmp/net-snmp;a=commitdiff;h=7b9e03441c3dc3a07670ed01f5d04791a82c750c

You should NOT remove val() macros.

val(AGENTX_PORT) expands to the string "705", while __STRING(AGENTX_PORT) expands to the string "AGENTX_PORT" which is not what we want.

You probably have to read this http://gcc.gnu.org/onlinedocs/cpp/Stringification.html

Found in version 5.7.2.rc1, linux, gentoo, but I checked git head, seems bug is still there.

Thanks.

----------------------------------------------------------------------

>Comment By:  (bvassche)
Date: 2012-10-31 13:00

Message:
Sorry that this happened. Reverted commit 7b9e034 via commit aef76ca.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3582283&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3582283 ] Subagent use tcp port 161 for agentx connection

[SourceForge.net <no...@so...>]

Patches item #3582283, was opened at 2012-10-31 11:09
Message generated for change (Tracker Item Submitted) made by qqshka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3582283&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: qqshka (qqshka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Subagent use tcp port 161 for agentx connection

Initial Comment:
Bug introduced here http://net-snmp.git.sourceforge.net/git/gitweb.cgi?p=net-snmp/net-snmp;a=commitdiff;h=7b9e03441c3dc3a07670ed01f5d04791a82c750c

You should NOT remove val() macros.

val(AGENTX_PORT) expands to the string "705", while __STRING(AGENTX_PORT) expands to the string "AGENTX_PORT" which is not what we want.

You probably have to read this http://gcc.gnu.org/onlinedocs/cpp/Stringification.html

Found in version 5.7.2.rc1, linux, gentoo, but I checked git head, seems bug is still there.

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3582283&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3580458 ] snmpd crashes/hangs when subagent disconnects during GetNext

[SourceForge.net <no...@so...>]

Patches item #3580458, was opened at 2012-10-26 01:42
Message generated for change (Comment added) made by kenfagilent
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jiri Cervenka (jcervenka)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmpd crashes/hangs when subagent disconnects during GetNext

Initial Comment:
This is my attempt to extend patch 1633670. This patch is created
against 5.7.2 plus patch 1633670.

Problems addressed:

1) Inifinite loop in delegated requests removal

In my opionion, the for-loop iteration on asp->requests in
netsnmp_remove_delegated_requests_for_session() is incorrect, as it
may end up flagging only a subset of asp's requests (depending on how
many different subtrees (and hence treecaches) this asp's requests
OIDs fall in). 

The loop situation occurs when the asp->requests[0] request has
already been answered (and is not part of any treecache), whereas some
other requests on this asp still have the delegated flag on
(reproducible by GetNext requests which contain both a variable
pointing to subtree belonging to the closing session, and another one
pointing to a range preceding that very subtree (but not fulfilled by
any preceding handler).

I think this for-loop should walk all asp->vbcount items on the
asp->requests array instead.

2) Crashes on dangling subtree pointers after AgentX Close PDU

The same crash patterns as those described in patch 1633670 appear
when a session gets closed via an explicit Close PDU from a subagent.
So, I think we need to go through the remove delegated requests loop
also when a valid sessid has been passed to close_agentx_session().

Adding this change caused double frees on delegated caches in
agentx_got_response() ('response is too late') -- apparently caused by
responses to retries, and also by callback from snmp_sess_close(). I
think this can be fixed by returning 1 from agentx_got_response() on
this occasion, thus letting _sess_process_packet() delete the request
from the session pending requests list.


Tested with 5.7.2 w/ patch 1633670, on x86_64 Linux, RHEL 5.5.

I tested the patch also with the subagent and traffic generating
script attached to bug 3565004 -- and it worked for me.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 09:19

Message:
Thanks for that, I'll re-test with the updated 1633670 and 5.7.2 stock -
testing with my hacked together version stayed up for about 2 hours, but
then started hanging up for long periods and chewing up memory.

Much better than anything that we achieved, but not quite there yet - I'll
tell you how testing went after it has had an overnight soak.

----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-10-29 05:52

Message:
Tha patch is meant to be applied against the final version of the patch
1633670 committed on trunk,
i.e. the 43cd9db4 commit 'CHANGES: PATCH 1633670: fixed snmpd crashing when
an AgentX subagent disconnect in the middle of processing of a request.'.

The final version contains two additional delegated cache memory leaks
fixes.

I have added the final version to this tracker artifact as
'patch-1633670-commit.patch'.

Sorry for confusion.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 05:17

Message:
Thanks for the patch!

Having problems applying it to 5.7.2 though, as the patch fails when
applied to the released 5.7.2 tarball after applying the final (v3) 1633670
patch.

Failed chunk is:

more master.c.rej
***************
*** 219,228 ****
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
-         /* response is too late, free the cache */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
-         return 0;
      }
      requests = cache->requests;

--- 219,231 ----
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
+         /*
+          * Response is too late, free the cache and return 1
+          * so that the session pending request list item can be deleted
+          */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
+         return 1;
      }
      requests = cache->requests;

Fails because:

          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);

isn't present, am I missing a patch to be applied to 5.7.2? Or am I working
with the wrong version of the original patch?

Meanwhile, I've manually applied the change and I'm testing with that - has
not crashed yet...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3580458 ] snmpd crashes/hangs when subagent disconnects during GetNext

[SourceForge.net <no...@so...>]

Patches item #3580458, was opened at 2012-10-26 01:42
Message generated for change (Comment added) made by jcervenka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jiri Cervenka (jcervenka)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmpd crashes/hangs when subagent disconnects during GetNext

Initial Comment:
This is my attempt to extend patch 1633670. This patch is created
against 5.7.2 plus patch 1633670.

Problems addressed:

1) Inifinite loop in delegated requests removal

In my opionion, the for-loop iteration on asp->requests in
netsnmp_remove_delegated_requests_for_session() is incorrect, as it
may end up flagging only a subset of asp's requests (depending on how
many different subtrees (and hence treecaches) this asp's requests
OIDs fall in). 

The loop situation occurs when the asp->requests[0] request has
already been answered (and is not part of any treecache), whereas some
other requests on this asp still have the delegated flag on
(reproducible by GetNext requests which contain both a variable
pointing to subtree belonging to the closing session, and another one
pointing to a range preceding that very subtree (but not fulfilled by
any preceding handler).

I think this for-loop should walk all asp->vbcount items on the
asp->requests array instead.

2) Crashes on dangling subtree pointers after AgentX Close PDU

The same crash patterns as those described in patch 1633670 appear
when a session gets closed via an explicit Close PDU from a subagent.
So, I think we need to go through the remove delegated requests loop
also when a valid sessid has been passed to close_agentx_session().

Adding this change caused double frees on delegated caches in
agentx_got_response() ('response is too late') -- apparently caused by
responses to retries, and also by callback from snmp_sess_close(). I
think this can be fixed by returning 1 from agentx_got_response() on
this occasion, thus letting _sess_process_packet() delete the request
from the session pending requests list.


Tested with 5.7.2 w/ patch 1633670, on x86_64 Linux, RHEL 5.5.

I tested the patch also with the subagent and traffic generating
script attached to bug 3565004 -- and it worked for me.


----------------------------------------------------------------------

Comment By: Jiri Cervenka (jcervenka)
Date: 2012-10-29 05:52

Message:
Tha patch is meant to be applied against the final version of the patch
1633670 committed on trunk,
i.e. the 43cd9db4 commit 'CHANGES: PATCH 1633670: fixed snmpd crashing when
an AgentX subagent disconnect in the middle of processing of a request.'.

The final version contains two additional delegated cache memory leaks
fixes.

I have added the final version to this tracker artifact as
'patch-1633670-commit.patch'.

Sorry for confusion.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 05:17

Message:
Thanks for the patch!

Having problems applying it to 5.7.2 though, as the patch fails when
applied to the released 5.7.2 tarball after applying the final (v3) 1633670
patch.

Failed chunk is:

more master.c.rej
***************
*** 219,228 ****
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
-         /* response is too late, free the cache */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
-         return 0;
      }
      requests = cache->requests;

--- 219,231 ----
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
+         /*
+          * Response is too late, free the cache and return 1
+          * so that the session pending request list item can be deleted
+          */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
+         return 1;
      }
      requests = cache->requests;

Fails because:

          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);

isn't present, am I missing a patch to be applied to 5.7.2? Or am I working
with the wrong version of the original patch?

Meanwhile, I've manually applied the change and I'm testing with that - has
not crashed yet...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3580458 ] snmpd crashes/hangs when subagent disconnects during GetNext

[SourceForge.net <no...@so...>]

Patches item #3580458, was opened at 2012-10-26 01:42
Message generated for change (Comment added) made by kenfagilent
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jiri Cervenka (jcervenka)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmpd crashes/hangs when subagent disconnects during GetNext

Initial Comment:
This is my attempt to extend patch 1633670. This patch is created
against 5.7.2 plus patch 1633670.

Problems addressed:

1) Inifinite loop in delegated requests removal

In my opionion, the for-loop iteration on asp->requests in
netsnmp_remove_delegated_requests_for_session() is incorrect, as it
may end up flagging only a subset of asp's requests (depending on how
many different subtrees (and hence treecaches) this asp's requests
OIDs fall in). 

The loop situation occurs when the asp->requests[0] request has
already been answered (and is not part of any treecache), whereas some
other requests on this asp still have the delegated flag on
(reproducible by GetNext requests which contain both a variable
pointing to subtree belonging to the closing session, and another one
pointing to a range preceding that very subtree (but not fulfilled by
any preceding handler).

I think this for-loop should walk all asp->vbcount items on the
asp->requests array instead.

2) Crashes on dangling subtree pointers after AgentX Close PDU

The same crash patterns as those described in patch 1633670 appear
when a session gets closed via an explicit Close PDU from a subagent.
So, I think we need to go through the remove delegated requests loop
also when a valid sessid has been passed to close_agentx_session().

Adding this change caused double frees on delegated caches in
agentx_got_response() ('response is too late') -- apparently caused by
responses to retries, and also by callback from snmp_sess_close(). I
think this can be fixed by returning 1 from agentx_got_response() on
this occasion, thus letting _sess_process_packet() delete the request
from the session pending requests list.


Tested with 5.7.2 w/ patch 1633670, on x86_64 Linux, RHEL 5.5.

I tested the patch also with the subagent and traffic generating
script attached to bug 3565004 -- and it worked for me.


----------------------------------------------------------------------

Comment By: Ken Farnen (kenfagilent)
Date: 2012-10-29 05:17

Message:
Thanks for the patch!

Having problems applying it to 5.7.2 though, as the patch fails when
applied to the released 5.7.2 tarball after applying the final (v3) 1633670
patch.

Failed chunk is:

more master.c.rej
***************
*** 219,228 ****
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
-         /* response is too late, free the cache */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
-         return 0;
      }
      requests = cache->requests;

--- 219,231 ----
      if (!cache) {
          DEBUGMSGTL(("agentx/master", "response too late on session
%8p\n",
                      session));
+         /*
+          * Response is too late, free the cache and return 1
+          * so that the session pending request list item can be deleted
+          */
          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);
+         return 1;
      }
      requests = cache->requests;

Fails because:

          if (magic)
              netsnmp_free_delegated_cache((netsnmp_delegated_cache*)
magic);

isn't present, am I missing a patch to be applied to 5.7.2? Or am I working
with the wrong version of the original patch?

Meanwhile, I've manually applied the change and I'm testing with that - has
not crashed yet...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3580458 ] snmpd crashes/hangs when subagent disconnects during GetNext

[SourceForge.net <no...@so...>]

Patches item #3580458, was opened at 2012-10-26 01:42
Message generated for change (Tracker Item Submitted) made by jcervenka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: jcervenka (jcervenka)
Assigned to: Nobody/Anonymous (nobody)
Summary: snmpd crashes/hangs when subagent disconnects during GetNext

Initial Comment:
This is my attempt to extend patch 1633670. This patch is created
against 5.7.2 plus patch 1633670.

Problems addressed:

1) Inifinite loop in delegated requests removal

In my opionion, the for-loop iteration on asp->requests in
netsnmp_remove_delegated_requests_for_session() is incorrect, as it
may end up flagging only a subset of asp's requests (depending on how
many different subtrees (and hence treecaches) this asp's requests
OIDs fall in). 

The loop situation occurs when the asp->requests[0] request has
already been answered (and is not part of any treecache), whereas some
other requests on this asp still have the delegated flag on
(reproducible by GetNext requests which contain both a variable
pointing to subtree belonging to the closing session, and another one
pointing to a range preceding that very subtree (but not fulfilled by
any preceding handler).

I think this for-loop should walk all asp->vbcount items on the
asp->requests array instead.

2) Crashes on dangling subtree pointers after AgentX Close PDU

The same crash patterns as those described in patch 1633670 appear
when a session gets closed via an explicit Close PDU from a subagent.
So, I think we need to go through the remove delegated requests loop
also when a valid sessid has been passed to close_agentx_session().

Adding this change caused double frees on delegated caches in
agentx_got_response() ('response is too late') -- apparently caused by
responses to retries, and also by callback from snmp_sess_close(). I
think this can be fixed by returning 1 from agentx_got_response() on
this occasion, thus letting _sess_process_packet() delete the request
from the session pending requests list.


Tested with 5.7.2 w/ patch 1633670, on x86_64 Linux, RHEL 5.5.

I tested the patch also with the subagent and traffic generating
script attached to bug 3565004 -- and it worked for me.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3580458&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-1627049 ] netsnmp api extension to deal with large file handles

[SourceForge.net <no...@so...>]

Patches item #1627049, was opened at 2007-01-03 07:19
Message generated for change (Comment added) made by bvassche
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=1627049&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Private: No
Submitted By: joyceanmachine (joyceanmachine)
Assigned to: Dave Shield (dts12)
Summary: netsnmp api extension to deal with large file handles

Initial Comment:
Hi all,

Currently the netsnmp library crashes when you try to use file desriptors larger than FD_SETSIZE. The snmp_read and snmp_select_info methods rely on filedescriptors being communicated through fd_sets,
which can contain only filedescriptors up to FD_SETSIZE (which is 1024 on most linux systems).

The attached patch contains an extension of the netsnmp api to deal with this problem. It allows the user to interact with netsnmp using arrays with arbitrarily large filehandles. 

Is there already someone working on this? If not, what would be the procedure to get this fix into the official distribution? 

Enabling netsnmp to deal with arbitrarily large filedescriptors is achieved (while maintinging backward compatibility) by introducing an interface in the style of the poll() command.

The patch introduces four new functions:
* snmp_read_extd
* snmp_sess_read_extd
* snmp_poll_info
* _sess_selpol_info
and modifies the interface of the function
* _sess_read

These methods all stick as closely as possible to the interface of the poll() command. They been tested with a couple of small examples on aix and linux.

Who would be the person to talk to about this stuff? 

Feedback and questions are most welcome.
Best regards,
Thijs

----------------------------------------------------------------------

>Comment By:  (bvassche)
Date: 2012-10-24 02:29

Message:
Renato, please create a new ticket for epoll support. Also, please update
the patch such that it applies on the latest master branch code. I'm going
to close this ticket.

----------------------------------------------------------------------

Comment By: Renato Westphal (rwestphal)
Date: 2012-10-02 05:59

Message:
Hi all,

"I reserve the right to consider the pollfdarr solution a more elegant
solution... ;-)"

Not only more elegant but far more efficient. Using the net-snmp current
API I just can't take advantage of the Linux epoll performance improvements
over the traditional select/poll interfaces.

"The reason we submitted this patch is that it allows the user to choose
whichever system calls it wants to use inside his/her event loop. The
struct pollfdarr is just a more convenient means to transport the file
descriptors than using fd_set if you have large filedescriptors. Also, it
can be used in any event handling framework. It doesn't force you to use
poll(). It only uses to the pollfdarr to transport the filedescriptors."

I think that's the main point here. The fd_set struct returned by
snmp_select_info() is very inconvenient if you are not using select()...

It would be great if the net-snmp team could review this patch once again,
I think it adds a lot to the project.

Renato.

----------------------------------------------------------------------

Comment By: joyceanmachine (joyceanmachine)
Date: 2010-08-27 10:18

Message:
To Bart: Thanks for the quick response.

At the first glance, that looks like it should do the trick as well. That's
great!
Will look at it more carefully over the coming weeks (I will probably have
to adapt our code to deal with the new interface), so I'll get back to you
if it doesn't satisfy our needs... ;-)

I reserve the right to consider the pollfdarr solution a more elegant
solution... ;-)

Have a nice weekend!
Thijs

----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2010-08-27 08:23

Message:
To Thijs: recent Net-SNMP versions already have support for more than 1024
file descriptors. Please have a look at the data structures and functions
declared in include/net-snmp/library/large_fd_set.h, and also at the
functions in include/net-snmp/session_api.h that accept a  large fd set as
argument. Do these satisfy your needs ?

----------------------------------------------------------------------

Comment By: joyceanmachine (joyceanmachine)
Date: 2010-08-27 07:58

Message:
Hello, haven't looked at this thing in ages. I think I classified it in the
back of my brain as 'done' after the last post from dts12.

To Magnus: Yes, ideally this is what we want (including pony ;-) ).
Actually, nice guess: we do have an ACE-style IO handling class. :-)
However, as you noted yourself below, creating callbacks would require a
(major) rewrite (of the interface). Instead, we just calculate the deltas
ourselves.

To Bart: Yes, this is what would be useful for us. :-) That's why I
submitted this patch.

Ok, maybe a bit more explanation is justified:
Our primary objective was not something that's faster than fd_set. Our
primary objective was to create a convenient way for netsnmp to communicate
filedescriptors > 1024 to the user, without completely changing the
interface. 
The reason we submitted this patch is that it allows the user to choose
whichever system calls it wants to use inside his/her event loop. The
struct pollfdarr is just a more convenient means to transport the
filedescriptors than using fd_set if you have large filedescriptors. Also,
it can be used in any event handling framework. It doesn't force you to use
poll(). It only uses to the pollfdarr to transport the filedescriptors.

Hope this clarifies a bit.

So what happens now?

Cheers,
Thijs



----------------------------------------------------------------------

Comment By: Magnus Fromreide (magfr)
Date: 2009-04-18 10:39

Message:
To Bart: Not for me, but possibly for the original poster.

If I were to get what I want (and a pony!) then i really would like to
get a callbacks when the library wants to
 * Register a socket for reading (today: when it get added to the fdset)
 * Deregister a socket for reading (today: when it get removed from
   the fdset)
 * A timeout is created
 * A timeout is removed since it is uninteresting

And yes - the reason this interests me is that I look at general event
handling frameworks that have their own abstractions - quite effective
ones but they do not match neither the poll nor the select model.

Other examples of an alternate event handlers are
 * imagine that we want to enable the messages to be handled by
   GetMessage in Windows.
 * imagine that we want the messages to be handled by an ACE IO
   handling class.


----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-18 10:21

Message:
To Magnus: would it be a solution if an snmp_poll_info() function would be
available that a.o. fills in a struct pollfd array ?

----------------------------------------------------------------------

Comment By: Magnus Fromreide (magfr)
Date: 2009-04-18 10:08

Message:
To Bart: No, snmp_select_info is made to work with select. While it is
possible to dig the file descriptors out of the returned fd_set and do
whatever processing you want with them it still pretends to know that
you wish to run select and that is what I think the original poster
had issues with as well since he wanted to use poll (there are
different cost calculations for poll and select).


----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-18 09:51

Message:
To Magnus: I agree that a user should be able to query the Net-SNMP file
descriptor and timeouts such that the user can build its own event loop. If
I'm not mistaken this is already possible via the snmp_select_info()
function ?


----------------------------------------------------------------------

Comment By: Magnus Fromreide (magfr)
Date: 2009-04-18 09:44

Message:
While I agree with Bart that it is horrible with all the event loops
that are hidden in netsnmp I think that the real problem is that the
library misbehaves and thinks that it should own the event loop - this
is generally false for libraries.

Thus I think that what really is needed is to change the library
interface to provide callbacks that the library user get file
descriptors and timeouts with and then it is up to the user if they
wish to use select, epoll or some windowsy method to figure out when
there is traffic on the descriptors or some timeout and then call back
to the lib and tell it that it must do something now.

Of course I fear that this is a rather large change put that is one of
my long (sadly very long) term visions for Net-SNMP.


----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2009-04-18 06:43

Message:
Bart, would you be able/willing to propose an alternate patch, ideally
within the 5.5.preX period?

----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-17 12:35

Message:
Note: if you would like to add API functions for Linux that work faster
than select() for large numbers of socket descriptors, you need the
epoll_create() / epoll_ctl() / epoll_wait() system calls in their
implementation, not the poll() system call. See e.g.
http://lwn.net/Articles/16026/ or <sys/epoll.h>.

----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-17 10:48

Message:
This patch has been written for the wrong reason. At least on Windows and
on Linux it is possible to pass more than 1024 file descriptors / socket
descriptors to the select() function -- I'm not sure about other Unix
systems. You can do this as follows on Linux:
* Make sure that /proc/sys/fs/file-max is large enough (the default value
on my Linux PC is 344507).
* Allocate (nfds + 8 * sizeof(int) - 1) / 8 bytes of memory instead of
using fd_set.
* When passing fd_set's between functions, always pass a pointer to an
fd_set, never the fd_set itself.
* See also http://opengroup.org/onlinepubs/007908775/xsh/select.html for
the SUSv2 specification of select().
* See also the source file fs/select.c in the Linux kernel tree for the
select() implementation.
And on Windows if you want to pass more than 64 sockets at a time to
select(), proceed as follows:
* Allocate sizeof(u_int) + nfds * sizeof(SOCKET) bytes of memory and use
that memory instead of an fd_set.
* When passing fd_set's between functions, always pass a pointer to an
fd_set, never the fd_set itself.
* See also http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx and
http://msdn.microsoft.com/en-us/library/ms737873(VS.85).aspx.


----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2007-03-23 01:59

Message:
Logged In: YES 
user_id=88893
Originator: NO

Thanks for the patch!  It has been applied to the current
development code, and will appear in the next major release
of the Net-SNMP package.


----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2007-03-23 01:59

Message:
Logged In: YES 
user_id=88893
Originator: NO

Note that I haven't attempted to address the issues you raised
(which is why this tracker entry has been left open).  But
with the code in place, there's more chance of people actually
commenting on these!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-04 03:39

Message:
Logged In: NO 

Ah yes, to get the patch working, you need to link against openssl >=
0.9.8.d

----------------------------------------------------------------------

Comment By: joyceanmachine (joyceanmachine)
Date: 2007-01-03 07:37

Message:
Logged In: YES 
user_id=1682471
Originator: YES

Open issues:
- The patch adds the line #include <sys/poll.h> to
include/net-snmp/library/snmp_api.h This is unelegant at best, since this
file does not contain any other includes (and probably shouldn't). Don't
know how to solve this properly (ok, I admit it, I didn't spend a lot of
time trying to figure it out...)

- It adds poll.h to configure and configure.in. Don't know if this is
correct and / or sufficient.

- Not sure if we want the POLLRDNORM and POLLRDBAND stuff in snmp_api.c

- FIXME in snmp_api.c which leads to quadratic behaviour in the number of
sessions. To fix this we need a hash table.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=1627049&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3565922 ] memory leak in "unload_all_mibs"

[SourceForge.net <no...@so...>]

Patches item #3565922, was opened at 2012-09-08 15:46
Message generated for change (Comment added) made by nba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3565922&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Doug Manley (tekkamanendless)
Assigned to: Niels Baggesen (nba)
Summary: memory leak in "unload_all_mibs"

Initial Comment:
When unloading MIBs (particularly when "snmp_shutdown" is called), the "description" field is never freed, leading to a lot of leaked memory.  To tell net-snmp to save the descriptions, set NETSNMP_DS_LIB_SAVE_MIB_DESCRS in this way:
netsnmp_ds_set_boolean( NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_SAVE_MIB_DESCRS, 1 );

All that is needed in parse.c is a tiny little "if" statement to clean up descriptions if they're set.

--- snmplib/parse.c.original    2012-09-08 18:25:45.925354050 -0400
+++ snmplib/parse.c     2012-09-08 18:26:05.805354558 -0400
@@ -4196,6 +4196,8 @@
         free(ptc->descriptor);
         if (ptc->hint)
             free(ptc->hint);
+       if (ptc->description)
+           free(ptc->description);
     }
     memset(tclist, 0, MAXTC * sizeof(struct tc));


----------------------------------------------------------------------

>Comment By: Niels Baggesen (nba)
Date: 2012-10-24 00:30

Message:
Actually, it was applied to 5.4.x too :-)

----------------------------------------------------------------------

Comment By: Niels Baggesen (nba)
Date: 2012-10-24 00:29

Message:
Thanks for the patch!  It has been applied to the 5.5.x and later code
branches and the main development tree, and will appear in future releases
of the Net-SNMP package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3565922&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3565922 ] memory leak in "unload_all_mibs"

[SourceForge.net <no...@so...>]

Patches item #3565922, was opened at 2012-09-08 15:46
Message generated for change (Comment added) made by nba
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3565922&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Doug Manley (tekkamanendless)
>Assigned to: Niels Baggesen (nba)
Summary: memory leak in "unload_all_mibs"

Initial Comment:
When unloading MIBs (particularly when "snmp_shutdown" is called), the "description" field is never freed, leading to a lot of leaked memory.  To tell net-snmp to save the descriptions, set NETSNMP_DS_LIB_SAVE_MIB_DESCRS in this way:
netsnmp_ds_set_boolean( NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_SAVE_MIB_DESCRS, 1 );

All that is needed in parse.c is a tiny little "if" statement to clean up descriptions if they're set.

--- snmplib/parse.c.original    2012-09-08 18:25:45.925354050 -0400
+++ snmplib/parse.c     2012-09-08 18:26:05.805354558 -0400
@@ -4196,6 +4196,8 @@
         free(ptc->descriptor);
         if (ptc->hint)
             free(ptc->hint);
+       if (ptc->description)
+           free(ptc->description);
     }
     memset(tclist, 0, MAXTC * sizeof(struct tc));


----------------------------------------------------------------------

Comment By: Niels Baggesen (nba)
Date: 2012-10-24 00:29

Message:
Thanks for the patch!  It has been applied to the 5.5.x and later code
branches and the main development tree, and will appear in future releases
of the Net-SNMP package.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3565922&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-1627049 ] netsnmp api extension to deal with large file handles

[SourceForge.net <no...@so...>]

Patches item #1627049, was opened at 2007-01-03 07:19
Message generated for change (Comment added) made by rwestphal
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=1627049&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Private: No
Submitted By: joyceanmachine (joyceanmachine)
Assigned to: Dave Shield (dts12)
Summary: netsnmp api extension to deal with large file handles

Initial Comment:
Hi all,

Currently the netsnmp library crashes when you try to use file desriptors larger than FD_SETSIZE. The snmp_read and snmp_select_info methods rely on filedescriptors being communicated through fd_sets,
which can contain only filedescriptors up to FD_SETSIZE (which is 1024 on most linux systems).

The attached patch contains an extension of the netsnmp api to deal with this problem. It allows the user to interact with netsnmp using arrays with arbitrarily large filehandles. 

Is there already someone working on this? If not, what would be the procedure to get this fix into the official distribution? 

Enabling netsnmp to deal with arbitrarily large filedescriptors is achieved (while maintinging backward compatibility) by introducing an interface in the style of the poll() command.

The patch introduces four new functions:
* snmp_read_extd
* snmp_sess_read_extd
* snmp_poll_info
* _sess_selpol_info
and modifies the interface of the function
* _sess_read

These methods all stick as closely as possible to the interface of the poll() command. They been tested with a couple of small examples on aix and linux.

Who would be the person to talk to about this stuff? 

Feedback and questions are most welcome.
Best regards,
Thijs

----------------------------------------------------------------------

Comment By: Renato Westphal (rwestphal)
Date: 2012-10-02 05:59

Message:
Hi all,

"I reserve the right to consider the pollfdarr solution a more elegant
solution... ;-)"

Not only more elegant but far more efficient. Using the net-snmp current
API I just can't take advantage of the Linux epoll performance improvements
over the traditional select/poll interfaces.

"The reason we submitted this patch is that it allows the user to choose
whichever system calls it wants to use inside his/her event loop. The
struct pollfdarr is just a more convenient means to transport the file
descriptors than using fd_set if you have large filedescriptors. Also, it
can be used in any event handling framework. It doesn't force you to use
poll(). It only uses to the pollfdarr to transport the filedescriptors."

I think that's the main point here. The fd_set struct returned by
snmp_select_info() is very inconvenient if you are not using select()...

It would be great if the net-snmp team could review this patch once again,
I think it adds a lot to the project.

Renato.

----------------------------------------------------------------------

Comment By: joyceanmachine (joyceanmachine)
Date: 2010-08-27 10:18

Message:
To Bart: Thanks for the quick response.

At the first glance, that looks like it should do the trick as well. That's
great!
Will look at it more carefully over the coming weeks (I will probably have
to adapt our code to deal with the new interface), so I'll get back to you
if it doesn't satisfy our needs... ;-)

I reserve the right to consider the pollfdarr solution a more elegant
solution... ;-)

Have a nice weekend!
Thijs

----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2010-08-27 08:23

Message:
To Thijs: recent Net-SNMP versions already have support for more than 1024
file descriptors. Please have a look at the data structures and functions
declared in include/net-snmp/library/large_fd_set.h, and also at the
functions in include/net-snmp/session_api.h that accept a  large fd set as
argument. Do these satisfy your needs ?

----------------------------------------------------------------------

Comment By: joyceanmachine (joyceanmachine)
Date: 2010-08-27 07:58

Message:
Hello, haven't looked at this thing in ages. I think I classified it in the
back of my brain as 'done' after the last post from dts12.

To Magnus: Yes, ideally this is what we want (including pony ;-) ).
Actually, nice guess: we do have an ACE-style IO handling class. :-)
However, as you noted yourself below, creating callbacks would require a
(major) rewrite (of the interface). Instead, we just calculate the deltas
ourselves.

To Bart: Yes, this is what would be useful for us. :-) That's why I
submitted this patch.

Ok, maybe a bit more explanation is justified:
Our primary objective was not something that's faster than fd_set. Our
primary objective was to create a convenient way for netsnmp to communicate
filedescriptors > 1024 to the user, without completely changing the
interface. 
The reason we submitted this patch is that it allows the user to choose
whichever system calls it wants to use inside his/her event loop. The
struct pollfdarr is just a more convenient means to transport the
filedescriptors than using fd_set if you have large filedescriptors. Also,
it can be used in any event handling framework. It doesn't force you to use
poll(). It only uses to the pollfdarr to transport the filedescriptors.

Hope this clarifies a bit.

So what happens now?

Cheers,
Thijs



----------------------------------------------------------------------

Comment By: Magnus Fromreide (magfr)
Date: 2009-04-18 10:39

Message:
To Bart: Not for me, but possibly for the original poster.

If I were to get what I want (and a pony!) then i really would like to
get a callbacks when the library wants to
 * Register a socket for reading (today: when it get added to the fdset)
 * Deregister a socket for reading (today: when it get removed from
   the fdset)
 * A timeout is created
 * A timeout is removed since it is uninteresting

And yes - the reason this interests me is that I look at general event
handling frameworks that have their own abstractions - quite effective
ones but they do not match neither the poll nor the select model.

Other examples of an alternate event handlers are
 * imagine that we want to enable the messages to be handled by
   GetMessage in Windows.
 * imagine that we want the messages to be handled by an ACE IO
   handling class.


----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-18 10:21

Message:
To Magnus: would it be a solution if an snmp_poll_info() function would be
available that a.o. fills in a struct pollfd array ?

----------------------------------------------------------------------

Comment By: Magnus Fromreide (magfr)
Date: 2009-04-18 10:08

Message:
To Bart: No, snmp_select_info is made to work with select. While it is
possible to dig the file descriptors out of the returned fd_set and do
whatever processing you want with them it still pretends to know that
you wish to run select and that is what I think the original poster
had issues with as well since he wanted to use poll (there are
different cost calculations for poll and select).


----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-18 09:51

Message:
To Magnus: I agree that a user should be able to query the Net-SNMP file
descriptor and timeouts such that the user can build its own event loop. If
I'm not mistaken this is already possible via the snmp_select_info()
function ?


----------------------------------------------------------------------

Comment By: Magnus Fromreide (magfr)
Date: 2009-04-18 09:44

Message:
While I agree with Bart that it is horrible with all the event loops
that are hidden in netsnmp I think that the real problem is that the
library misbehaves and thinks that it should own the event loop - this
is generally false for libraries.

Thus I think that what really is needed is to change the library
interface to provide callbacks that the library user get file
descriptors and timeouts with and then it is up to the user if they
wish to use select, epoll or some windowsy method to figure out when
there is traffic on the descriptors or some timeout and then call back
to the lib and tell it that it must do something now.

Of course I fear that this is a rather large change put that is one of
my long (sadly very long) term visions for Net-SNMP.


----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2009-04-18 06:43

Message:
Bart, would you be able/willing to propose an alternate patch, ideally
within the 5.5.preX period?

----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-17 12:35

Message:
Note: if you would like to add API functions for Linux that work faster
than select() for large numbers of socket descriptors, you need the
epoll_create() / epoll_ctl() / epoll_wait() system calls in their
implementation, not the poll() system call. See e.g.
http://lwn.net/Articles/16026/ or <sys/epoll.h>.

----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2009-04-17 10:48

Message:
This patch has been written for the wrong reason. At least on Windows and
on Linux it is possible to pass more than 1024 file descriptors / socket
descriptors to the select() function -- I'm not sure about other Unix
systems. You can do this as follows on Linux:
* Make sure that /proc/sys/fs/file-max is large enough (the default value
on my Linux PC is 344507).
* Allocate (nfds + 8 * sizeof(int) - 1) / 8 bytes of memory instead of
using fd_set.
* When passing fd_set's between functions, always pass a pointer to an
fd_set, never the fd_set itself.
* See also http://opengroup.org/onlinepubs/007908775/xsh/select.html for
the SUSv2 specification of select().
* See also the source file fs/select.c in the Linux kernel tree for the
select() implementation.
And on Windows if you want to pass more than 64 sockets at a time to
select(), proceed as follows:
* Allocate sizeof(u_int) + nfds * sizeof(SOCKET) bytes of memory and use
that memory instead of an fd_set.
* When passing fd_set's between functions, always pass a pointer to an
fd_set, never the fd_set itself.
* See also http://msdn.microsoft.com/en-us/library/ms740141(VS.85).aspx and
http://msdn.microsoft.com/en-us/library/ms737873(VS.85).aspx.


----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2007-03-23 01:59

Message:
Logged In: YES 
user_id=88893
Originator: NO

Thanks for the patch!  It has been applied to the current
development code, and will appear in the next major release
of the Net-SNMP package.


----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2007-03-23 01:59

Message:
Logged In: YES 
user_id=88893
Originator: NO

Note that I haven't attempted to address the issues you raised
(which is why this tracker entry has been left open).  But
with the code in place, there's more chance of people actually
commenting on these!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-04 03:39

Message:
Logged In: NO 

Ah yes, to get the patch working, you need to link against openssl >=
0.9.8.d

----------------------------------------------------------------------

Comment By: joyceanmachine (joyceanmachine)
Date: 2007-01-03 07:37

Message:
Logged In: YES 
user_id=1682471
Originator: YES

Open issues:
- The patch adds the line #include <sys/poll.h> to
include/net-snmp/library/snmp_api.h This is unelegant at best, since this
file does not contain any other includes (and probably shouldn't). Don't
know how to solve this properly (ok, I admit it, I didn't spend a lot of
time trying to figure it out...)

- It adds poll.h to configure and configure.in. Don't know if this is
correct and / or sufficient.

- Not sure if we want the POLLRDNORM and POLLRDBAND stuff in snmp_api.c

- FIXME in snmp_api.c which leads to quadratic behaviour in the number of
sessions. To fix this we need a hash table.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=1627049&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3569650 ] logMatch variable for matched text

[SourceForge.net <no...@so...>]

Patches item #3569650, was opened at 2012-09-19 13:59
Message generated for change (Comment added) made by jregovich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3569650&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Regovich (jregovich)
Assigned to: Nobody/Anonymous (nobody)
Summary: logMatch variable for matched text

Initial Comment:
Addition of a new variable, logMatchLastMatch that contains the text of the last match, allowin notifications to show the matched text.

----------------------------------------------------------------------

>Comment By: Jim Regovich (jregovich)
Date: 2012-09-19 14:00

Message:
Tested on CentOs 5 and 6

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3569650&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3569650 ] logMatch variable for matched text

[SourceForge.net <no...@so...>]

Patches item #3569650, was opened at 2012-09-19 13:59
Message generated for change (Tracker Item Submitted) made by jregovich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3569650&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Regovich (jregovich)
Assigned to: Nobody/Anonymous (nobody)
Summary: logMatch variable for matched text

Initial Comment:
Addition of a new variable, logMatchLastMatch that contains the text of the last match, allowin notifications to show the matched text.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3569650&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3564180 ] writing to oid with invalid type does not fail (correctly)

[SourceForge.net <no...@so...>]

Patches item #3564180, was opened at 2012-09-02 10:03
Message generated for change (Comment added) made by tanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3564180&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Finzel Stefan (fis04268)
Assigned to: Nobody/Anonymous (nobody)
Summary: writing to oid with invalid type does not fail (correctly)

Initial Comment:
net-snmp-5-7-2-rc2:

- IP-MIB::ipForwarding is Integer32 but writable as Counter32, Unsigned32, TimeTicks.
- IP-MIB::ipForwarding is Interger32, but writing with as IpAddress will not return error wrongType but wrongValue.
- ipAddressSpinLock is Interger32, but writing as  Counter32, Unsigned32, TimeTick, IpAddress will not return error wrongType but inconsistentValue

snmpset -v2c -cprivate 192.168.0.39 1.3.6.1.2.1.4.1.0 u 1
iso.3.6.1.2.1.4.1.0 = Gauge32: 1

snmpset -v2c -cprivate 192.168.0.39 1.3.6.1.2.1.4.1.0 a 1
Error in packet.
Reason: wrongValue (The set value is illegal or unsupported in some way)
Failed object: iso.3.6.1.2.1.4.1.0

snmpset -v2c -cprivate 192.168.0.39 1.3.6.1.2.1.4.33.0 u 1
Error in packet.
Reason: inconsistentValue (The set value is illegal or unsupported in some way)
Failed object: iso.3.6.1.2.1.4.33.0



	ERROR	set	1.3.6.1.2.1.4.1.0	Integer32 is writable as Counter32
	ERROR	set	1.3.6.1.2.1.4.1.0	Integer32 is writable as Unsigned32
	ERROR	set	1.3.6.1.2.1.4.1.0	Integer32 is writable as TimeTicks
	ERROR	set	1.3.6.1.2.1.4.1.0	Integer32 as IpAddress returns wrongValue 0 {1.3.6.1.2.1.4.1.0 IpAddress 0.0.0.0}
	ERROR	set	1.3.6.1.2.1.4.33.0	Integer32 as Counter32 returns inconsistentValue 0 {1.3.6.1.2.1.4.33.0 Counter32 1}
	ERROR	set	1.3.6.1.2.1.4.33.0	Integer32 as Unsigned32 returns inconsistentValue 0 {1.3.6.1.2.1.4.33.0 Unsigned32 1}
	ERROR	set	1.3.6.1.2.1.4.33.0	Integer32 as TimeTicks returns inconsistentValue 0 {1.3.6.1.2.1.4.33.0 TimeTicks 1}
	ERROR	set	1.3.6.1.2.1.4.33.0	Integer32 as IpAddress returns inconsistentValue 0 {1.3.6.1.2.1.4.33.0 IpAddress 0.0.0.0}


----------------------------------------------------------------------

>Comment By: Thomas Anders (tanders)
Date: 2012-09-17 05:49

Message:
moving to patches

----------------------------------------------------------------------

Comment By: Finzel Stefan (fis04268)
Date: 2012-09-17 05:14

Message:
fiexed by

--- net-snmp-5.7.2.rc2/agent/mibgroup/ip-mib/ip_scalars.c	2012-09-01
19:20:47.000000000 +0200
+++ net-snmp-5.7.2.rc2/agent/mibgroup/ip-mib/ip_scalars.c.new	2012-09-17
14:01:27.657974001 +0200
@@ -133,7 +133,10 @@
          *
http://www.net-snmp.org/tutorial-5/toolkit/mib_module/set-actions.jpg
          */
         case MODE_SET_RESERVE1:
-            break;
+	    if (requests->requestvb->type != ASN_INTEGER) {
+	      (void) netsnmp_set_request_error(reqinfo, requests,
SNMP_ERR_WRONGTYPE);
+	    }
+	    break;
 
         case MODE_SET_RESERVE2:
             /*
@@ -237,7 +240,10 @@
          *
http://www.net-snmp.org/tutorial-5/toolkit/mib_module/set-actions.jpg
          */
     case MODE_SET_RESERVE1:
-        break;
+	if (requests->requestvb->type != ASN_INTEGER) {
+	  (void) netsnmp_set_request_error(reqinfo, requests,
SNMP_ERR_WRONGTYPE);
+	}
+	break;
 
     case MODE_SET_RESERVE2:
         /*
@@ -332,6 +338,10 @@
          *
http://www.net-snmp.org/tutorial-5/toolkit/mib_module/set-actions.jpg
          */
         case MODE_SET_RESERVE1:
+	    if (requests->requestvb->type != ASN_INTEGER) {
+	      (void) netsnmp_set_request_error(reqinfo, requests,
SNMP_ERR_WRONGTYPE);
+	    }
+	    break;
         case MODE_SET_RESERVE2:
             /* just check the value */
             value =  *(requests->requestvb->val.integer);


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3564180&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3565922 ] memory leak in "unload_all_mibs"

[SourceForge.net <no...@so...>]

Patches item #3565922, was opened at 2012-09-08 15:46
Message generated for change (Tracker Item Submitted) made by tekkamanendless
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3565922&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Doug Manley (tekkamanendless)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak in "unload_all_mibs"

Initial Comment:
When unloading MIBs (particularly when "snmp_shutdown" is called), the "description" field is never freed, leading to a lot of leaked memory.  To tell net-snmp to save the descriptions, set NETSNMP_DS_LIB_SAVE_MIB_DESCRS in this way:
netsnmp_ds_set_boolean( NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_SAVE_MIB_DESCRS, 1 );

All that is needed in parse.c is a tiny little "if" statement to clean up descriptions if they're set.

--- snmplib/parse.c.original    2012-09-08 18:25:45.925354050 -0400
+++ snmplib/parse.c     2012-09-08 18:26:05.805354558 -0400
@@ -4196,6 +4196,8 @@
         free(ptc->descriptor);
         if (ptc->hint)
             free(ptc->hint);
+       if (ptc->description)
+           free(ptc->description);
     }
     memset(tclist, 0, MAXTC * sizeof(struct tc));


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3565922&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3563210 ] memory leak when using a insert filter (net snmpd 5.7.1)

[SourceForge.net <no...@so...>]

Patches item #3563210, was opened at 2012-08-30 02:05
Message generated for change (Comment added) made by kbij
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3563210&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Koen bijttebier (kbij)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak when using a insert filter (net snmpd 5.7.1)

Initial Comment:
We use a container insert filter. When this filter is used, a large memory leak occurs. It consumes all available memory after a few days. I changed the code in two files (container.c and interface_linux.c)
net snmp version 5.6.1
tested on opensuse 64-bit


----------------------------------------------------------------------

>Comment By: Koen bijttebier (kbij)
Date: 2012-09-03 03:35

Message:
Not sure what you mean. We downloaded the 5.7.1 sources, and modified them.

----------------------------------------------------------------------

Comment By: Magnus Fromreide (magfr)
Date: 2012-08-30 15:03

Message:
This is basically a partial backport of svn revision 16804 (git
aea04dda70bc348a6d0ff33fa9ae8c0e27501b7f), isn't it? Why not do a full
backport with both the header part and the implementation part?

----------------------------------------------------------------------

Comment By: Koen bijttebier (kbij)
Date: 2012-08-30 07:12

Message:
uploaded new diff.
Thank you for your patience ;-)

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2012-08-30 06:47

Message:
Please use the GNU diff --ignore-all-space option to suppress white space
changes when creating the diff.

----------------------------------------------------------------------

Comment By: Koen bijttebier (kbij)
Date: 2012-08-30 05:55

Message:
I have added the unified diff files. Please note that the diff contains a
lot of differences due to white space. I guess my editor removes white
spaces (code blocks)
The actual differences are rather small.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2012-08-30 03:05

Message:
Thanks for the patch! Could you please post the patch in unified diff
("diff -u") format?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3563210&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3560473 ] Handle TimeTicks when pretty-printing OID

[SourceForge.net <no...@so...>]

Patches item #3560473, was opened at 2012-08-21 14:19
Message generated for change (Comment added) made by hardaker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3560473&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Bill Fenner (fenner)
>Assigned to: Wes Hardaker (hardaker)
Summary: Handle TimeTicks when pretty-printing OID

Initial Comment:
When walking a table with a TimeTicks column in the INDEX, any further objects aren't pretty-printed since the TimeTicks value causes the pretty-printer to abort.  This patch allows the pretty-printer to keep pretty-printing.

It prints the column as an integer unless -OX, in which case it prints it as a formatted time.

----------------------------------------------------------------------

Comment By: Wes Hardaker (hardaker)
Date: 2012-09-01 09:52

Message:
Thanks for the patch!  It has been applied to the 5.4.x and above code
branches and the main development tree, and will appear in future releases
of the Net-SNMP package.

----------------------------------------------------------------------

Comment By: Bill Fenner (fenner)
Date: 2012-08-21 14:23

Message:
Sample output without this patch:

ARISTA-ACL-MIB::aristaIpAclRuleStatsPktCount.0.25.100.101.102.97.117.108.116.45.99.111.110.116.114.111.108.45.112.108.97.110.101.45.97.99.108.50
= Counter64: 203

With this patch:

ARISTA-ACL-MIB::aristaIpAclRuleStatsPktCount.0."default-control-plane-acl".50
= Counter64: 203

or with -OX:

ARISTA-ACL-MIB::aristaIpAclRuleStatsPktCount[0:0:00:00.00][default-control-plane-acl][50]


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3560473&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3563210 ] memory leak when using a insert filter (net snmpd 5.7.1)

[SourceForge.net <no...@so...>]

Patches item #3563210, was opened at 2012-08-30 02:05
Message generated for change (Comment added) made by magfr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3563210&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Koen bijttebier (kbij)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak when using a insert filter (net snmpd 5.7.1)

Initial Comment:
We use a container insert filter. When this filter is used, a large memory leak occurs. It consumes all available memory after a few days. I changed the code in two files (container.c and interface_linux.c)
net snmp version 5.6.1
tested on opensuse 64-bit


----------------------------------------------------------------------

>Comment By: Magnus Fromreide (magfr)
Date: 2012-08-30 15:03

Message:
This is basically a partial backport of svn revision 16804 (git
aea04dda70bc348a6d0ff33fa9ae8c0e27501b7f), isn't it? Why not do a full
backport with both the header part and the implementation part?

----------------------------------------------------------------------

Comment By: Koen bijttebier (kbij)
Date: 2012-08-30 07:12

Message:
uploaded new diff.
Thank you for your patience ;-)

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2012-08-30 06:47

Message:
Please use the GNU diff --ignore-all-space option to suppress white space
changes when creating the diff.

----------------------------------------------------------------------

Comment By: Koen bijttebier (kbij)
Date: 2012-08-30 05:55

Message:
I have added the unified diff files. Please note that the diff contains a
lot of differences due to white space. I guess my editor removes white
spaces (code blocks)
The actual differences are rather small.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2012-08-30 03:05

Message:
Thanks for the patch! Could you please post the patch in unified diff
("diff -u") format?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3563210&group_id=12694

[Net-snmp-patches] [ net-snmp-Patches-3563210 ] memory leak when using a insert filter (net snmpd 5.7.1)

[SourceForge.net <no...@so...>]

Patches item #3563210, was opened at 2012-08-30 02:05
Message generated for change (Comment added) made by kbij
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3563210&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Koen bijttebier (kbij)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak when using a insert filter (net snmpd 5.7.1)

Initial Comment:
We use a container insert filter. When this filter is used, a large memory leak occurs. It consumes all available memory after a few days. I changed the code in two files (container.c and interface_linux.c)
net snmp version 5.6.1
tested on opensuse 64-bit


----------------------------------------------------------------------

Comment By: Koen bijttebier (kbij)
Date: 2012-08-30 07:12

Message:
uploaded new diff.
Thank you for your patience ;-)

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2012-08-30 06:47

Message:
Please use the GNU diff --ignore-all-space option to suppress white space
changes when creating the diff.

----------------------------------------------------------------------

Comment By: Koen bijttebier (kbij)
Date: 2012-08-30 05:55

Message:
I have added the unified diff files. Please note that the diff contains a
lot of differences due to white space. I guess my editor removes white
spaces (code blocks)
The actual differences are rather small.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2012-08-30 03:05

Message:
Thanks for the patch! Could you please post the patch in unified diff
("diff -u") format?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3563210&group_id=12694