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

Re: [SECURITY] Inquiry about Vulnerability Reporting Process

[Bart V. A. <bva...@ac...>]

On 6/22/25 11:44 AM, JustCoding247 wrote:
> I am writing to inquire about the proper procedure for reporting a 
> potential security vulnerability I have discovered in Net-SNMP.
> 
> While analyzing the Net-SNMP source code, I have identified what appears 
> to be a buffer overflow vulnerability in the network statistics 
> functionality. To follow responsible disclosure practices, I would like 
> to report this issue privately to the project maintainers before any 
> public disclosure.
> 
> Could you please advise on the preferred method for submitting detailed 
> vulnerability reports? Specifically, I would like to know:
> 
> 1. Is there a dedicated security contact email or private reporting channel?
> 2. What information should be included in the vulnerability report?
> 3. What is the typical timeline for security issue resolution?
> 
> I can provide:
> - Detailed technical analysis of the vulnerability
> - Affected code locations and line numbers
> - Potential impact assessment
> - Suggested fix/patch recommendations
> - Proof-of-concept code (if needed)
> 
> I understand the importance of responsible disclosure and am committed 
> to working with the project team to address this issue appropriately.
> 
> Thank you for your time and guidance. I look forward to your response.

My answers to your questions are as follows:
1. Please send the report to net...@li....
2. Any information that allows us to root-cause and/or reproduce the bug
    is fine. Providing a suggested fix will help to get the issue to be
    addressed more quickly. Proof-of-concept code isn't required but if
    it can be provided under a BSD license then we can add it to the test
    suite.
3. Net-SNMP is maintained by a team of volunteers so there are no hard
    guarantees for the resolution time. How quickly the reports gets
    addressed will depend on the severity of the reported issue.

Thanks,

Bart.

[SECURITY] Inquiry about Vulnerability Reporting Process

[JustCoding247 <jus...@gm...>]

Dear Net-SNMP Developers,

I hope this email finds you well.

I am writing to inquire about the proper procedure for reporting a
potential security vulnerability I have discovered in Net-SNMP.

While analyzing the Net-SNMP source code, I have identified what appears to
be a buffer overflow vulnerability in the network statistics functionality.
To follow responsible disclosure practices, I would like to report this
issue privately to the project maintainers before any public disclosure.

Could you please advise on the preferred method for submitting detailed
vulnerability reports? Specifically, I would like to know:

1. Is there a dedicated security contact email or private reporting channel?
2. What information should be included in the vulnerability report?
3. What is the typical timeline for security issue resolution?

I can provide:
- Detailed technical analysis of the vulnerability
- Affected code locations and line numbers
- Potential impact assessment
- Suggested fix/patch recommendations
- Proof-of-concept code (if needed)

I understand the importance of responsible disclosure and am committed to
working with the project team to address this issue appropriately.

Thank you for your time and guidance. I look forward to your response.

Best regards,
JustCoding247

Purpose of netsnmp_pdu.data in mib table

[Pushpa T. <pus...@gm...>]

Hi All,
>From my observations, it appears that some  of MIB table implementations
utilize the dataFreeHook within the netsnmp_pdu structure. I understand
that this hook is intended to release the memory allocated to
netsnmp_pdu.data. I would appreciate further clarification on the role of
netsnmp_pdu.data and the nature of the data it contains in the context of
MIB table implementations.  Kindly guide.

Eg: dataFreeHook = requests->requestvb->dataFreeHook in

_mfd_ipAddressTable_get_values(netsnmp_mib_handler *handler,
                               netsnmp_handler_registration *reginfo,
                               netsnmp_agent_request_info *agtreq_info,
                               netsnmp_request_info *requests)


Thanks,
Pushpa Thimmaiah

Regarding Issue 960

[Feroz <fer...@gm...>]

Hello,
Is this issue known?

https://github.com/net-snmp/net-snmp/issues/960

I performed root walk, with valgrind attached.
Didn't hit this issue in the second iteration.
-- 
Regards,
Feroz Ahmed

Re:

[Pushpa T. <pus...@gm...>]

Hi All,

Can I use attribute *data to send a string token in agentx get pdu

typedef struct variable_list {
   /** NULL for last variable */
   struct variable_list *next_variable;
   /** Object identifier of variable */
   oid            *name;
   /** number of subid's in name */
   size_t          name_length;
   /** ASN type of variable */
   u_char          type;
   /** value of variable */
    netsnmp_vardata val;
   /** the length of the value to be copied into buf */
   size_t          val_len;
   /** buffer to hold the OID */
   oid             name_loc[MAX_OID_LEN];
   /** 90 percentile < 40. */
   u_char          buf[40];
   /** (Opaque) hook for additional data */
   void           *data;  <--------------------------------- Can I pass
string token here
   /** callback to free above */
   void            (*dataFreeHook)(void *);
   int             index;
} netsnmp_variable_list;

Thanks,
Pushpa.T

On Mon, Mar 17, 2025 at 1:43 PM Pushpa Thimmaiah <pus...@gm...>
wrote:

> Hi All,
>
> I am using the SNMPD master and subagent for private MIBs and would like
> to know  if private data can be transmitted to the subagent along with the
> set/get request data.
>
> Specifically, during an SNMP query, I need to pass a unique string token
> from SNMPD to the subagent along with the get request details. The subagent
> will use this token for authentication to retrieve data from the backend.
> This token is intended to remain confidential between SNMPD and the
> subagent.
>
>
> Thanks,
>
> Pushpa.T
>

Re: Net-SNMP 5.10.pre1 released for testing

[Craig S. <cs...@dr...>]

On Sat, 8 Mar 2025 at 10:50, Wes Hardaker via Net-snmp-coders <
net...@li...> wrote:

> only be used for bug fixes at this point.  Please give 5.10.pre1 a
> whirl -- it certainly won't be perfect yet.
>
I've built 5.10~pre1 using the Debian package setup, was a few patches that
needed updating but compiled fine.

I've got a bunch of lintian warnings like:
W: snmp: groff-message troff:<standard input>:562: warning: cannot select
font 'C' [usr/share/man/man1/snmpcmd.1.gz:1]
which are due to lines like:
\fC$ snmpget \-c public \-v 1 localhost sysUpTime.0

It doesn't seem to know what \fC means, or it doesn't know what the 'C'
font is. Which is fine because I don't either.

 - Craig

Re: Net-SNMP 5.10.pre1 released for testing

[Bart V. A. <bva...@ac...>]

On 3/14/25 3:06 PM, Bart Van Assche wrote:
> The above patch has been split and has been submitted as a pull request
> to the ntopng project. See also
> https://github.com/ntop/ntopng/pull/9028#issuecomment-2718468627.

This pull request has been merged.

Bart.

[Pushpa T. <pus...@gm...>]

Hi All,

I am using the SNMPD master and subagent for private MIBs and would like to
know  if private data can be transmitted to the subagent along with the
set/get request data.

Specifically, during an SNMP query, I need to pass a unique string token
from SNMPD to the subagent along with the get request details. The subagent
will use this token for authentication to retrieve data from the backend.
This token is intended to remain confidential between SNMPD and the
subagent.


Thanks,

Pushpa.T

Re: Net-SNMP 5.10.pre1 released for testing

[Bart V. A. <bva...@ac...>]

On 3/10/25 4:27 AM, Stuart Henderson wrote:
> gnugk:
> 
> snmp.cxx:87:11: error: expected '(' for function-style cast or type construction
>          trapOID[ OID_LENGTH(trapOID) - 1 ] = trapNumber;
>                   ^~~~~~~~~~~~~~~~~~~
> /usr/local/include/net-snmp/library/asn1.h:65:56: note: expanded from macro 'OID_LENGTH'
>       sizeof(int[-__builtin_types_compatible_p(typeof(x), typeof(&(x)[0]))]))
>                                                ~~~~~~~~~^
> snmp.cxx:87:11: error: expected '(' for function-style cast or type construction
>          trapOID[ OID_LENGTH(trapOID) - 1 ] = trapNumber;
>                   ^~~~~~~~~~~~~~~~~~~

I can't reproduce this with the gnugk git master branch head. gitgk
builds fine on my Linux workstation with the Net-SNMP master branch
head.

Thanks,

Bart.

Re: Net-SNMP 5.10.pre1 released for testing

[Bart V. A. <bva...@ac...>]

On 3/10/25 5:48 PM, Bart Van Assche wrote:
> diff --git a/include/SNMPSession.h b/include/SNMPSession.h
> index 932b3d96ce17..e12ef0a2f893 100644
> --- a/include/SNMPSession.h
> +++ b/include/SNMPSession.h
> @@ -32,7 +32,7 @@
>   class SNMPSession {
>    public:
>     struct snmp_session session;
> -  void *session_ptr;
> +  decltype(snmp_sess_open(NULL)) session_ptr;
> 
>     SNMPSession();
>     ~SNMPSession();
> diff --git a/src/SNMP.cpp b/src/SNMP.cpp
> index 1763bcac5175..f97e4969a432 100644
> --- a/src/SNMP.cpp
> +++ b/src/SNMP.cpp
> @@ -453,13 +453,16 @@ bool SNMP::send_snmp_request(char *agent_host, 
> u_int version, char *community,
>           if((!strcasecmp(level, "authNoPriv")) ||
>          (!strcasecmp(level, "authPriv"))) {
>             if(!strcasecmp(auth_protocol, "md5")) {
> -            snmpSession->session.securityAuthProto = 
> usmHMACMD5AuthProtocol;
> -            snmpSession->session.securityAuthProtoLen =
> -          sizeof(usmHMACMD5AuthProtocol) / sizeof(oid);
> +            const int len = sizeof(usmHMACMD5AuthProtocol) / sizeof(oid);
> +            snmpSession->session.securityAuthProto =
> +              static_cast<oid *>(netsnmp_memdup(usmHMACMD5AuthProtocol, 
> len));
> +            snmpSession->session.securityAuthProtoLen = len;
>               snmpSession->session.securityAuthKeyLen = USM_AUTH_KU_LEN;
>             } else if(!strcasecmp(auth_protocol, "sha")) {
> -            snmpSession->session.securityAuthProto = 
> usmHMACSHA1AuthProtocol;
> -            snmpSession->session.securityAuthProtoLen = 
> sizeof(usmHMACSHA1AuthProtocol) / sizeof(oid);
> +            const int len = sizeof(usmHMACSHA1AuthProtocol) / sizeof(oid);
> +            snmpSession->session.securityAuthProto =
> +              static_cast<oid 
> *>(netsnmp_memdup(usmHMACSHA1AuthProtocol, len));
> +            snmpSession->session.securityAuthProtoLen = len;
>               snmpSession->session.securityAuthKeyLen = 
> USM_AUTH_KU_LEN; /* CHECK */
>   #ifdef usmHMAC192SHA256AuthProtocol
>             } else if(!strcasecmp(auth_protocol, "sha256")) {

The above patch has been split and has been submitted as a pull request
to the ntopng project. See also
https://github.com/ntop/ntopng/pull/9028#issuecomment-2718468627.

Bart.

Re: [PATCH RFC] Removing NOAUTODEPS support

[Bart V. A. <bva...@ac...>]

On 3/10/25 1:39 PM, Bart Van Assche wrote:
> Are there any objections against removing NOAUTODEPS support? I noticed
> that ./config.status is often run if no changes have been made to any
> configure script. Hence this proposal to remove NOAUTODEPS support and
> instead to let developers run the configure script and/or autoreconf
> when necessary.

An update: a slightly modified version of this patch has been applied.

Bart.

Re: Net-SNMP 5.10.pre1 released for testing

[Bart V. A. <bva...@ac...>]

On 3/10/25 4:27 AM, Stuart Henderson wrote:
> To see how things are going with API changes, I've tested building
> everything in OpenBSD ports which depends on this. (I'm not suggesting
> that Net-SNMP needs to change anything unless these are unexpected, but
> at least giving other package maintainers a heads-up on what might be
> affected).

Thank you for having done this before Net-SNMP version 5.10 is released.

> gnugk:
> 
> snmp.cxx:87:11: error: expected '(' for function-style cast or type construction
>          trapOID[ OID_LENGTH(trapOID) - 1 ] = trapNumber;
>                   ^~~~~~~~~~~~~~~~~~~
> /usr/local/include/net-snmp/library/asn1.h:65:56: note: expanded from macro 'OID_LENGTH'
>       sizeof(int[-__builtin_types_compatible_p(typeof(x), typeof(&(x)[0]))]))
>                                                ~~~~~~~~~^
> snmp.cxx:87:11: error: expected '(' for function-style cast or type construction
>          trapOID[ OID_LENGTH(trapOID) - 1 ] = trapNumber;
                    ^~~~~~~~~~~~~~~~~~~

What compiler and flags have been selected by the configure script of
gnugk? Use of __builtin_types_compatible_p() is guarded as follows in
the Net-SNMP headers:

#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
#define OID_LENGTH(x)                                                   \
     (sizeof(x) / sizeof((x)[0]) +                                       \
      sizeof(int[-__builtin_types_compatible_p(typeof(x), 
typeof(&(x)[0]))]))
#else
#define OID_LENGTH(x)  (sizeof(x) / sizeof((x)[0]))
#endif

> ntopng:
> various from snmp_sess_* functions taking struct session_list * rather
> than void *, and also

Unless anyone objects, I will look into modifying these functions such
that these accept a void * pointer again.

> src/SNMP.cpp:452:47: error: assigning to 'oid *' (aka 'unsigned long *') from incompatible type 'const oid[10]' (aka 'const unsigned long[10]')
>              snmpSession->session.securityAuthProto = usmHMACMD5AuthProtocol;
>                                                       ^~~~~~~~~~~~~~~~~~~~~~

The above error indicates a potential memory corruption issue in ntopng.
Any pointer assigned to snmpSession->session.securityAuthProto should
point at dynamically allocated memory and not to a static array. The
code for freeing session->securityAuthProto in snmplib/snmp_api.c is 26
years old if I interpret the git history correctly.

Bart.

Re: Net-SNMP 5.10.pre1 released for testing

[Bart V. A. <bva...@ac...>]

On 3/10/25 4:27 AM, Stuart Henderson wrote:
> ntopng:
> various from snmp_sess_* functions taking struct session_list * rather
> than void *, and also
> 
> src/SNMP.cpp:452:47: error: assigning to 'oid *' (aka 'unsigned long *') from incompatible type 'const oid[10]' (aka 'const unsigned long[10]')
>              snmpSession->session.securityAuthProto = usmHMACMD5AuthProtocol;

After having taken a closer look at the ntopng source code, how about
submitting the following (untested) patch to the ntopng project? This
patch should be backwards compatible. This means that it works with both
Net-SNMP 5.10 and older versions of Net-SNMP.

Thanks,

Bart.


diff --git a/include/SNMPSession.h b/include/SNMPSession.h
index 932b3d96ce17..e12ef0a2f893 100644
--- a/include/SNMPSession.h
+++ b/include/SNMPSession.h
@@ -32,7 +32,7 @@
  class SNMPSession {
   public:
    struct snmp_session session;
-  void *session_ptr;
+  decltype(snmp_sess_open(NULL)) session_ptr;

    SNMPSession();
    ~SNMPSession();
diff --git a/src/SNMP.cpp b/src/SNMP.cpp
index 1763bcac5175..f97e4969a432 100644
--- a/src/SNMP.cpp
+++ b/src/SNMP.cpp
@@ -453,13 +453,16 @@ bool SNMP::send_snmp_request(char *agent_host, 
u_int version, char *community,
          if((!strcasecmp(level, "authNoPriv")) ||
  	   (!strcasecmp(level, "authPriv"))) {
            if(!strcasecmp(auth_protocol, "md5")) {
-            snmpSession->session.securityAuthProto = 
usmHMACMD5AuthProtocol;
-            snmpSession->session.securityAuthProtoLen =
-	      sizeof(usmHMACMD5AuthProtocol) / sizeof(oid);
+            const int len = sizeof(usmHMACMD5AuthProtocol) / sizeof(oid);
+            snmpSession->session.securityAuthProto =
+              static_cast<oid *>(netsnmp_memdup(usmHMACMD5AuthProtocol, 
len));
+            snmpSession->session.securityAuthProtoLen = len;
              snmpSession->session.securityAuthKeyLen = USM_AUTH_KU_LEN;
            } else if(!strcasecmp(auth_protocol, "sha")) {
-            snmpSession->session.securityAuthProto = 
usmHMACSHA1AuthProtocol;
-            snmpSession->session.securityAuthProtoLen = 
sizeof(usmHMACSHA1AuthProtocol) / sizeof(oid);
+            const int len = sizeof(usmHMACSHA1AuthProtocol) / sizeof(oid);
+            snmpSession->session.securityAuthProto =
+              static_cast<oid 
*>(netsnmp_memdup(usmHMACSHA1AuthProtocol, len));
+            snmpSession->session.securityAuthProtoLen = len;
              snmpSession->session.securityAuthKeyLen = USM_AUTH_KU_LEN; 
/* CHECK */
  #ifdef usmHMAC192SHA256AuthProtocol
            } else if(!strcasecmp(auth_protocol, "sha256")) {

[PATCH RFC] Removing NOAUTODEPS support

[Bart V. A. <bva...@ac...>]

Hi,

Are there any objections against removing NOAUTODEPS support? I noticed
that ./config.status is often run if no changes have been made to any
configure script. Hence this proposal to remove NOAUTODEPS support and
instead to let developers run the configure script and/or autoreconf
when necessary.

Thanks,

Bart.


Subject: [PATCH] Makefile.in: Remove NOAUTODEPS support

While configure script changes are rare, it often happens that config.status
is run when it shouldn't. Remove NOAUTODEPS support such that config.status
is not run automatically if NOAUTODEPS has not been set. Instead, let 
developers
run autoreconf and/or the Net-SNMP configure script when necessary. See also
https://net-snmp.sourceforge.io/wiki/index.php/Build_System.
---
  Makefile.in | 39 ---------------------------------------
  stamp-h     |  1 -
  stamp-h.in  |  1 -
  3 files changed, 41 deletions(-)
  delete mode 100644 stamp-h
  delete mode 100644 stamp-h.in

diff --git a/Makefile.in b/Makefile.in
index 1228065c633c..af115241c089 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -302,16 +302,6 @@ configclean: makefileclean
  touchit:
  	touch configure include/net-snmp/net-snmp-config.h.in
  	touch config.status
-	touch stamp-h stamp-h.in
-
-Makefile: Makefile.in config.status Makefile.rules Makefile.top
-	@if test "x$(NOAUTODEPS)" = "x"; then \
-	    echo "running config.status because the following file(s) changed:"; \
-	    echo "  $?"; \
-	    ./config.status; \
-	else \
-	    echo "WARNING: not running config.status"; \
-	fi

  configure_ac = configure.ac \
  	configure.d/config_modules_agent \
@@ -334,35 +324,6 @@ configure_ac = configure.ac \
  	configure.d/config_project_types \
  	configure.d/config_project_with_enable

-$(srcdir)/include/net-snmp/net-snmp-config.h.in: stamp-h.in
-$(srcdir)/stamp-h.in: $(configure_ac)
-	@if test "x$(NOAUTODEPS)" = "x" -a "x$(AUTOHEADER)" != "x:"; then \
-	    cd ${srcdir} && LC_COLLATE=C $(AUTOHEADER); \
-	    echo timestamp > ${srcdir}/stamp-h.in; \
-	else \
-	    echo "WARNING: not running autoheader"; \
-	fi
-
-include/net-snmp/net-snmp-config.h: stamp-h
-stamp-h: include/net-snmp/net-snmp-config.h.in config.status
-	@if test "x$(NOAUTODEPS)" = "x"; then \
-	    echo "running config.status because the following file(s) changed:"; \
-	    echo "  $?"; \
-	    ./config.status; \
-	    echo timestamp > stamp-h; \
-	else \
-	    echo "WARNING: not running config.status"; \
-	fi
-
-$(srcdir)/configure: $(configure_ac) aclocal.m4
-	@if test "x$(NOAUTODEPS)" = "x" -a "x$(AUTOCONF)" != "x:"; then \
-	    cd ${srcdir} && $(AUTOCONF); \
-	    echo "Please run configure now."; \
-	    sh -c exit 2; \
-	else \
-	    echo "WARNING: not running autoconf"; \
-	fi
-
  gendir=dist/generation-scripts
  generation-scripts: generation-scripts-dirs 
$(gendir)/gen-transport-headers $(gendir)/gen-security-headers

diff --git a/stamp-h b/stamp-h
deleted file mode 100644
index 9788f70238c9..000000000000
--- a/stamp-h
+++ /dev/null
@@ -1 +0,0 @@
-timestamp
diff --git a/stamp-h.in b/stamp-h.in
deleted file mode 100644
index 9788f70238c9..000000000000
--- a/stamp-h.in
+++ /dev/null
@@ -1 +0,0 @@
-timestamp

Re: Net-SNMP 5.10.pre1 released for testing

[Stuart H. <st...@sp...>]

On 2025/03/07 15:34, Wes Hardaker via Net-snmp-coders wrote:
> 
> Greetings all,
> 
> It's been a while ---  time to finally release a 5.10 pre-release
> candidate.  Consider this a feature freeze and the master branch should
> only be used for bug fixes at this point.  Please give 5.10.pre1 a
> whirl -- it certainly won't be perfect yet.

To see how things are going with API changes, I've tested building
everything in OpenBSD ports which depends on this. (I'm not suggesting
that Net-SNMP needs to change anything unless these are unexpected, but
at least giving other package maintainers a heads-up on what might be
affected).

Built ok: sane-backends, php (8.2/8.3/8.4), ifstat, lldpd, mbrowse,
monitoring-plugins, rtg, snmptt, tcl-snmptools, ttg, zabbix, hplip,
fwbuilder, collectd, nut, asterisk (16/18/20/22), kamailio.

I had two failures; gnugk (we are up to date on this; 5.13) and ntopng
(out of date, I can't easily test with a current version).

gnugk:

snmp.cxx:87:11: error: expected '(' for function-style cast or type construction
        trapOID[ OID_LENGTH(trapOID) - 1 ] = trapNumber;
                 ^~~~~~~~~~~~~~~~~~~
/usr/local/include/net-snmp/library/asn1.h:65:56: note: expanded from macro 'OID_LENGTH'
     sizeof(int[-__builtin_types_compatible_p(typeof(x), typeof(&(x)[0]))]))
                                              ~~~~~~~~~^
snmp.cxx:87:11: error: expected '(' for function-style cast or type construction
        trapOID[ OID_LENGTH(trapOID) - 1 ] = trapNumber;
                 ^~~~~~~~~~~~~~~~~~~

ntopng:
various from snmp_sess_* functions taking struct session_list * rather
than void *, and also

src/SNMP.cpp:452:47: error: assigning to 'oid *' (aka 'unsigned long *') from incompatible type 'const oid[10]' (aka 'const unsigned long[10]')
            snmpSession->session.securityAuthProto = usmHMACMD5AuthProtocol;
                                                     ^~~~~~~~~~~~~~~~~~~~~~

Net-SNMP 5.10.pre1 released for testing

[Wes H. <har...@us...>]

Greetings all,

It's been a while ---  time to finally release a 5.10 pre-release
candidate.  Consider this a feature freeze and the master branch should
only be used for bug fixes at this point.  Please give 5.10.pre1 a
whirl -- it certainly won't be perfect yet.

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

Re: [PATCH 1/1] snmp_agent: Fixes incrementation of snmpInTotalSetVars

[Bart V. A. <bva...@ac...>]

On 2/28/25 5:14 AM, Michael Schmidt via Net-snmp-coders wrote:
> diff --git a/agent/snmp_agent.c b/agent/snmp_agent.c
> index 9913a968e1..c728059ac8 100644
> --- a/agent/snmp_agent.c
> +++ b/agent/snmp_agent.c
> @@ -1908,6 +1908,8 @@ netsnmp_wrap_up_request(netsnmp_agent_session *asp, int status)
>       }
>   
>       if (asp->pdu) {
> +	int command = asp->pdu->command;
> +

Please fix the indentation of this declaration and declare 'command'
const.

> @@ -2030,7 +2032,7 @@ netsnmp_wrap_up_request(netsnmp_agent_session *asp, int status)
>           if (status == SNMP_ERR_NOERROR)
>               snmp_increment_statistic_by(
>   #ifndef NETSNMP_NO_WRITE_SUPPORT
> -                (asp->pdu->command == SNMP_MSG_SET ?
> +                (command == SNMP_MSG_SET ?
>                    STAT_SNMPINTOTALSETVARS : STAT_SNMPINTOTALREQVARS),
>   #else
>                   STAT_SNMPINTOTALREQVARS,

Please submit a pull request to the following GitHub project:
https://github.com/net-snmp/net-snmp/

Thanks,

Bart.

Remove me from this group

[Nishant N. <nay...@gm...>]

Hi,
Request anyone to remove me front his mailing list. I don't want to receive
updates anymore.

Regards,
Nishant Nayan

[PATCH 0/1] Patch for snmp_agent.c

[Michael S. <sch...@si...>]

Greetings net-snmp-devs,

this patch fixes an issue in the latest net-snmp version which inhibits the proper incrementation of snmpInTotalSetVars. (Issue: Net-SNMP V5.9.x: No increment of snmpInTotalSetVars #429)

It implements a temporary variable 'command' which is used to save the value of the command-pointer at the start of the if-case and later reused to compare if the issued command was a set or get request.

This prevents modifications of the command-pointer (snmp_agent.c, line 2017) impacting the proper incrementation of the statistic.


Kind regards,

Michael Schmidt

scmi (1):
  snmp_agent: Fixes incrementation of snmpInTotalSetVars

 agent/snmp_agent.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.39.5

[PATCH 1/1] snmp_agent: Fixes incrementation of snmpInTotalSetVars

[Michael S. <sch...@si...>]

From: scmi <sch...@si...>

Implements a temporary variable 'command' which saves the value of the command-pointer before modifications for a later value check.

Signed-off-by: Michael Schmidt <sch...@si...>
---
 agent/snmp_agent.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/agent/snmp_agent.c b/agent/snmp_agent.c
index 9913a968e1..c728059ac8 100644
--- a/agent/snmp_agent.c
+++ b/agent/snmp_agent.c
@@ -1908,6 +1908,8 @@ netsnmp_wrap_up_request(netsnmp_agent_session *asp, int status)
     }
 
     if (asp->pdu) {
+	int command = asp->pdu->command;
+
         /*
          * If we've got an error status, then this needs to be
          *  passed back up to the higher levels....
@@ -2030,7 +2032,7 @@ netsnmp_wrap_up_request(netsnmp_agent_session *asp, int status)
         if (status == SNMP_ERR_NOERROR)
             snmp_increment_statistic_by(
 #ifndef NETSNMP_NO_WRITE_SUPPORT
-                (asp->pdu->command == SNMP_MSG_SET ?
+                (command == SNMP_MSG_SET ?
                  STAT_SNMPINTOTALSETVARS : STAT_SNMPINTOTALREQVARS),
 #else
                 STAT_SNMPINTOTALREQVARS,
-- 
2.39.5

Re: Regarding OID of AES192

[Pushpa T. <pus...@gm...>]

Hi,

Thank you Menase, Laurent,  Craig Small and Magnus Fromreide.


I am using  snmp4j  as snmp-agent and snmptrapd as trap-receiver.  I  would
like to know how  snmptrapd can be configured to authenticate AES192 of
snmp4j ?
If company develop support for AES192 then how will  the generic
snmp-manager(snmptrapd) can recognize the protocol..

I have seen that if snmpagent using AES192C in snmpv3traps and snmp-manager
configured with AES192 then manager will not authenticate
traps-with-AES192C.

Thanks,
Pushpa.T


On Wed, Feb 19, 2025 at 8:50 AM Magnus Fromreide <ma...@ly...>
wrote:

> On Tue, Feb 18, 2025 at 03:19:27PM +0530, Pushpa Thimmaiah wrote:
> > Hi All,
> >
> > I would like to understand why does oid of AES128 and AES192 not in same
> > branch.
> > AES128  : .1.3.6.1.6.3.10.1.2.4
> > AES192 : .1.3.6.1.4.1.14832.1.3
> >
>
> It has to do with timing and processes.
>
> If you look up the OID's you see that .1.3.6.1.6.3.10.1.2.4 is defined in
> SMIv2 - that is STD58 - and changing that document is a rather involved
> process.
>
> In order to get some kind of identifier out there faster  a "private
> organisation" (1.3.6.1.4.1) have defined some other values in order to,
> as taken from the DESCRIPTION in their MIB
>
> "The ESO Consortium is an umbrella organization for registration of
> not-yet-standardized Simple Network Management Protocol (SNMP) security
> modules in the enterprise space. The objects published here are intended to
> provide a common naming and registration for authentication and privacy
> protocol extensions to the SNMP User-based Security Model (USM)
> Module (RFC3414). The authentication and privacy protocol objects specified
> herein are intended to be used as values for usmUserAuthProtocol and
> usmUserPrivProtocol when managing SNMPv3 users via the snmpUsmMIB."
>
> but it seems as if they (SNMP research?) stopped pushing new values towards
> IETF at some point and decided to just use their own values.
>
> In our source code we have the following:
>
> #ifdef NETSNMP_DRAFT_BLUMENTHAL_AES_04
>     /* OIDs from http://www.snmp.com/eso/esoConsortiumMIB.txt */
> const oid usmAES192PrivProtocol[9] = { 1,3,6,1,4,1,14832,1,3 };
> const oid usmAES256PrivProtocol[9] = { 1,3,6,1,4,1,14832,1,4 };
>     /* OIDs from CISCO MIB */
> const oid usmAES192CiscoPrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,1 };
> const oid usmAES256CiscoPrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,2 };
> /*
>  * these OIDs are in pySNMP source as OIDs for AES+Reeder. We'll just
>  * use OIDS from CISCO-SNMP-USM-OIDS-MIB
>  *
> const oid usmAES192Cisco2PrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,101 };
> const oid usmAES256Cisco2PrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,102 };
>  */
> #endif /* NETSNMP_DRAFT_BLUMENTHAL_AES_04 */
>
> where you can see that ESO have defined AES-192 once and Cisco have done it
> twice as they seem to have teo variations of it.
>
> Now, given the above code it looks like net-snmp should recognize
> .1.3.6.1.4.1.14832.1.3 if it is configured that way. The easiest way to
> check is by means of running
>
> snmptrap --help
>
> and look at the -x option, if it lists AES-192 then it should be there.
>
> > I have seen a snmpagent package using 1.3.6.1.4.1.4976.2.2.x.x.x.  as OID
> > of AES192.
> > Does snmptrap receiver  recognise OID   1.3.6.1.4.1.4976.2.2.x.x.x. as
> > AES192?
>
> 1.3.6.1.4.1.4976 is agentpp, another snmp implementor, just like net-snmp
> and
> snmp reserch, I found a copy of their MIB on
>
>
> https://github.com/brettwooldridge/snmp4j/blob/master/mibs/OOSNMP-USM-MIB.txt
>
> and it does in deed declare yet another value for the supposedly same
> thing,
> but in a less proper way.
>
> Net-SNMP does not, as far as I know, recognize the agentpp definition.
>
> /MF
>
> I have always been surprised by the willingness to try to enumerate the
> world that people show.
>
> >
> > Thank you,
> > Pushpa.T
>
>
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
>

Re: Regarding OID of AES192

[Magnus F. <ma...@ly...>]

On Tue, Feb 18, 2025 at 03:19:27PM +0530, Pushpa Thimmaiah wrote:
> Hi All,
> 
> I would like to understand why does oid of AES128 and AES192 not in same
> branch.
> AES128  : .1.3.6.1.6.3.10.1.2.4
> AES192 : .1.3.6.1.4.1.14832.1.3
> 

It has to do with timing and processes.

If you look up the OID's you see that .1.3.6.1.6.3.10.1.2.4 is defined in
SMIv2 - that is STD58 - and changing that document is a rather involved
process.

In order to get some kind of identifier out there faster  a "private
organisation" (1.3.6.1.4.1) have defined some other values in order to,
as taken from the DESCRIPTION in their MIB

"The ESO Consortium is an umbrella organization for registration of
not-yet-standardized Simple Network Management Protocol (SNMP) security
modules in the enterprise space. The objects published here are intended to
provide a common naming and registration for authentication and privacy
protocol extensions to the SNMP User-based Security Model (USM)
Module (RFC3414). The authentication and privacy protocol objects specified
herein are intended to be used as values for usmUserAuthProtocol and
usmUserPrivProtocol when managing SNMPv3 users via the snmpUsmMIB."

but it seems as if they (SNMP research?) stopped pushing new values towards
IETF at some point and decided to just use their own values.

In our source code we have the following:

#ifdef NETSNMP_DRAFT_BLUMENTHAL_AES_04
    /* OIDs from http://www.snmp.com/eso/esoConsortiumMIB.txt */
const oid usmAES192PrivProtocol[9] = { 1,3,6,1,4,1,14832,1,3 };
const oid usmAES256PrivProtocol[9] = { 1,3,6,1,4,1,14832,1,4 };
    /* OIDs from CISCO MIB */
const oid usmAES192CiscoPrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,1 };
const oid usmAES256CiscoPrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,2 };
/*
 * these OIDs are in pySNMP source as OIDs for AES+Reeder. We'll just
 * use OIDS from CISCO-SNMP-USM-OIDS-MIB
 *
const oid usmAES192Cisco2PrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,101 };
const oid usmAES256Cisco2PrivProtocol[11]  = { 1,3,6,1,4,1,9,12,6,1,102 };
 */
#endif /* NETSNMP_DRAFT_BLUMENTHAL_AES_04 */

where you can see that ESO have defined AES-192 once and Cisco have done it
twice as they seem to have teo variations of it.

Now, given the above code it looks like net-snmp should recognize
.1.3.6.1.4.1.14832.1.3 if it is configured that way. The easiest way to
check is by means of running

snmptrap --help

and look at the -x option, if it lists AES-192 then it should be there.

> I have seen a snmpagent package using 1.3.6.1.4.1.4976.2.2.x.x.x.  as OID
> of AES192.
> Does snmptrap receiver  recognise OID   1.3.6.1.4.1.4976.2.2.x.x.x. as
> AES192?

1.3.6.1.4.1.4976 is agentpp, another snmp implementor, just like net-snmp and
snmp reserch, I found a copy of their MIB on

https://github.com/brettwooldridge/snmp4j/blob/master/mibs/OOSNMP-USM-MIB.txt

and it does in deed declare yet another value for the supposedly same thing,
but in a less proper way.

Net-SNMP does not, as far as I know, recognize the agentpp definition.

/MF

I have always been surprised by the willingness to try to enumerate the
world that people show.

> 
> Thank you,
> Pushpa.T


> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

RE: Regarding OID of AES192

[Menase, L. (TS E. R. Team) <lau...@hp...>]

Hi Pushpa
According to http://www.net-snmp.org/wiki/index.php/Strong_Authentication_or_Encryption
1.3.6.1.4.1.14832.1.3 is not supported since not defined by RFC if I read well, but some other RFC defined OID were defined in rfc7860

Which if I am not wrong are:
snmpUsmHmacSha2MIB
1.3.6.1.2.1.235
               usmHMAC128SHA224AuthProtocol
1.3.6.1.6.3.10.1.1.4
               usmHMAC192SHA256AuthProtocol
1.3.6.1.6.3.10.1.1.5
               usmHMAC256SHA384AuthProtocol
1.3.6.1.6.3.10.1.1.6
               usmHMAC384SHA512AuthProtocol
1.3.6.1.6.3.10.1.1.7

Best regards,
Laurent Menase

From: Pushpa Thimmaiah <pus...@gm...>
Sent: Tuesday, February 18, 2025 10:49 AM
To: Net-SNMP Coders <net...@li...>
Subject: Regarding OID of AES192

Hi All,

I would like to understand why does oid of AES128 and AES192 not in same branch.
AES128  : .1.3.6.1.6.3.10.1.2.4
AES192 : .1.3.6.1.4.1.14832.1.3

I have seen a snmpagent package using 1.3.6.1.4.1.4976.2.2.x.x.x.  as OID of AES192.
Does snmptrap receiver  recognise OID   1.3.6.1.4.1.4976.2.2.x.x.x. as AES192?


Thank you,
Pushpa.T

Regarding OID of AES192

[Pushpa T. <pus...@gm...>]

Hi All,

I would like to understand why does oid of AES128 and AES192 not in same
branch.
AES128  : .1.3.6.1.6.3.10.1.2.4
AES192 : .1.3.6.1.4.1.14832.1.3

I have seen a snmpagent package using 1.3.6.1.4.1.4976.2.2.x.x.x.  as OID
of AES192.
Does snmptrap receiver  recognise OID   1.3.6.1.4.1.4976.2.2.x.x.x. as
AES192?


Thank you,
Pushpa.T

Re: (Previous email had a weird formatting) Custom Mib returning wrong values when Magic number is larger than 255

[Neeraj B. <nee...@gm...>]

Thank you for the suggestions. Based on your suggestion, we were trying
different things and figured out a way to make it work.

One of the first things we did was, remove all the warnings since there
were a lot. Then we saw that the compiler was telling us that there are
more than 255 variables which is more than the vp->magic variable can store.

One of the other thing we tested was, if we can see all the OIDs with
"name" variable with the following code:

// Find the OID to match
    memset(tmpsql,0, sizeof(tmpsql));
    memset(buf,0, sizeof(buf));
    for (z = 0; z < *length; z++)
    {
        res = snprintf(buf, sizeof(buf), "%u",name[z]);
        strcat(tmpsql, buf);
        if(z < *length - 1)
        {
            strcat(tmpsql, ".");
        }
    }

// tmpsql contains the OID, match it in a switch case
    for (size_t i = 0; i < NUM_ENTRIES; i++)
    {
        if (strcmp(oidlookupTable[i].oid, tmpsql) == 0)
        {
            matched_code = oidlookupTable[i].device_type;
            break;
        }
    }

And we thought, we can use the OIDs to match up all the data points and
that's what we used in the switch statement. We added a struct as follows
and defined all our variables, which uses the previously defined variables
in header file.

typedef struct OidEntry {
    const char *oid;
    int device_type;
} OidEntry;

This solution seems to work for us and now we can add as many variables as
we want. I hope this solution can help someone else as well.

And again, thank you for your response Craig.

- Neeraj

On Fri, 11 Oct 2024 at 00:16, Craig Small <csmall@dropbear.xyz> wrote:

> Hi,
>   You can definitely have more than 255 custom OIDs, the trick is you only
> have 255 values for magic. I'm surprised hacking the magic value didn't
> crash it before.
>
> There's probably a few options; the good, the bad and the ugly.
>
> Good
> Rebuild the MIB and functions so each type of variable uses a different
> accessor function, so testboard_var becomes testboard_load,
> testboard_temperature etc.
> As long as you don't have 256 temperature sensors or load sensors or same
> things this works. If you have different ways of getting values, it also
> means the
> functions are simpler/smaller because the temperature getter has no code
> for working out system load and vice-versa. It also means you're not
> bothering to fetch the
> temperature when you want to get the load too.
>
> Bad
> Keep the mib as it is, but have several accessor functions which have a
> different magic which you add to the parameters passed to the real accessor.
> Your testboard_var() will need a new parameter, say mymagic which is
> something larger than u_char
>
> testboard_var1(vp, other variables)
>   return (testboard_var(vp->magic, vp, other variables)
> testboard_var2(vp, other_variables)
>   return (testboard_var(vp->magic+256, vp, other_variables)
> testboard_var3(vp, other_variables)
>   return (testboard_var(vp->magic+512, vp, other_variables)
> In your variables array the ones that use 1-255 use testboard_var1,
> 256-511 use testboard_var2 (but use magic-256) etc.
>
> Ugly
> Overload or ignore the magic and match on the OID directly, which is
> called vp->name. There's a reason why this is the ugly option.
>
>  - Craig
>
>
> On Sat, 21 Sept 2024 at 05:24, Neeraj Bansal <nee...@gm...>
> wrote:
>
>> That makes sense Craig. Thank you for your input.
>>
>> To summarize the issue, we are unable to use more than 255 OID entries
>> and would love to get any help on this issue.
>>
>> Is there another way to use more than 255 custom OID's?
>>
>> Thank You to anyone looking into this matter.
>>
>> - Neeraj
>>
>> On Mon, 29 Jul 2024 at 14:26, Craig Small <csmall@dropbear.xyz> wrote:
>>
>>> On Fri, 12 Jul 2024 at 08:31, Neeraj Bansal <nee...@gm...>
>>> wrote:
>>> > We recompile everything and install no problem, but instead of fixing
>>> our problem it caused net-snmp-5.9.3 to not be able to start. The error it
>>> gives is: Bad user id, which could be a red herring. example below:
>>> > [root@testboard: /root# /etc/init.d/S59netsnmp restart
>>> > Stopping SNMP daemon: [OK]
>>> > Starting SNMP daemon: Bad user id: snmp
>>> I think it is a red herring, that error is from the -u option.
>>>
>>> # /usr/sbin/snmpd -u blah
>>> Bad user id: blah
>>>
>>> I know that is not solving your main issue, but its got rid of one thing.
>>>
>>>  - Craig
>>>
>>>
>>>
>>> > [root@testboard: /root#
>>> >
>>> > So, we take our patches out and recompile and install, and it works
>>> again but still has the 255 custom oid limitation.
>>> >
>>> > A snippet from our header file. Too big to paste it all.
>>> >
>>> > #define TEMPC 1
>>> > #define TEMPF 2
>>> > #define   UPTIME_STR 3
>>> > #define   SERIALNUMBER 4
>>> > #define   ALLOFIT 5
>>> > #define   ROOTFSBUILD 6
>>> > #define   KERNELBUILD      7
>>> > #define   OSINFO    8
>>> > ......
>>> > #define PRODUCT_ID 250
>>> > #define RUNSCRIPT 251
>>> > #define TIMER1 252
>>> > #define TIMER2 253
>>> > #define TIMER3 254
>>> > #define TIMER4 255
>>> > #define TIMER5 256 <- This outpts an error because it wraps around and
>>> 0 is not defined.
>>> > #define TIMER6 257 <- This outputs TEMPC value instead of TIMER6.
>>> > #define TIMER7 258
>>> > #define TIMER8 259
>>> > #define TIMER9 260
>>> > #define TIMER10 261
>>> >
>>> > #define    EXAMPLETIMETICKS 3333
>>> > #define EXAMPLEIPADDRESS        4444
>>> > #define   EXAMPLECOUNTER 7777
>>> > #define EXAMPLEGAUGE            8888
>>> > #define EXAMPLETRIGGERTRAP      9999
>>> > #define EXAMPLETRIGGERTRAP2     1000
>>> >
>>> > Notice the example defines above that were provided in the example C
>>> header file, those magic numbers would have never worked because of the
>>> u_char (8-bit) magic variable limitation.
>>> >
>>> > This is a code snippet from our custom mib C file.
>>> >
>>> > struct variable4 testboard_variables[] = {
>>> >    {ROOTFSBUILD, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var,
>>> 2, {7, 1}},
>>> >    {KERNELBUILD, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var,
>>> 2, {7, 2}},
>>> >    {OSINFO, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2, {7,
>>> 3}},
>>> >    {PRODUCT_ID, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, etestboard_var,
>>> 2, {7, 4}},
>>> >    {UPTIME_STR, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2,
>>> {5, 1}},
>>> >    {SERIALNUMBER, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var,
>>> 2, {5, 2}},
>>> >    {TEMPC, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2,
>>> {6,1}},
>>> >    {TEMPF, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2,
>>> {6,2}},
>>> >
>>> > We have poured over the souce code looking for any other instance of
>>> u_char magic that we may have missed, but they are only defined in the two
>>> files mentioned above.
>>> >
>>> > We need some help with this. What else do we need to do in the 5.9
>>> versions to make the magic number not wrap around to zero after 255 and not
>>> crash when we do that?
>>> >
>>> > Thanks,
>>> >
>>> > Neeraj Bansal
>>> > _______________________________________________
>>> > Net-snmp-coders mailing list
>>> > Net...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>>>
>>