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

[REQUEST FOR VOTES] snmpd: Call fclose() after fdopen() but not close()

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

>From https://pubs.opengroup.org/onlinepubs/9699919799/functions/fclose.html:
"The fclose() function shall perform the equivalent of a close() on the file
descriptor that is associated with the stream pointed to by stream."

See also https://github.com/net-snmp/net-snmp/issues/157 .

Fixes: fd9a42d142d8 ("- (pass-persist.c pass-persist.h): moved to pass_persist.[ch].")
Fixes: a36188e50dcc ("Patch #760417 from Bob Rowlands/Sun for fixing Bug #751920")
---
 agent/mibgroup/ucd-snmp/pass_persist.c | 24 ++----------------------
 agent/snmpd.c                          |  6 +-----
 2 files changed, 3 insertions(+), 27 deletions(-)

diff --git a/agent/mibgroup/ucd-snmp/pass_persist.c b/agent/mibgroup/ucd-snmp/pass_persist.c
index 4d88ff2b54bf..173510aa51c5 100644
--- a/agent/mibgroup/ucd-snmp/pass_persist.c
+++ b/agent/mibgroup/ucd-snmp/pass_persist.c
@@ -775,32 +775,12 @@ close_persist_pipe(int iindex)
         fclose(persist_pipes[iindex].fOut);
         persist_pipes[iindex].fOut = (FILE *) 0;
     }
-    if (persist_pipes[iindex].fdOut != -1) {
-#ifndef WIN32
-        /*
-         * The sequence open()/fdopen()/fclose()/close() triggers an access
-         * violation with the MSVC runtime. Hence skip the close() call when
-         * using the MSVC runtime.
-         */
-        close(persist_pipes[iindex].fdOut);
-#endif
-        persist_pipes[iindex].fdOut = -1;
-    }
+    persist_pipes[iindex].fdOut = -1;
     if (persist_pipes[iindex].fIn) {
         fclose(persist_pipes[iindex].fIn);
         persist_pipes[iindex].fIn = (FILE *) 0;
     }
-    if (persist_pipes[iindex].fdIn != -1) {
-#ifndef WIN32
-        /*
-         * The sequence open()/fdopen()/fclose()/close() triggers an access
-         * violation with the MSVC runtime. Hence skip the close() call when
-         * using the MSVC runtime.
-         */
-        close(persist_pipes[iindex].fdIn);
-#endif
-        persist_pipes[iindex].fdIn = -1;
-    }
+    persist_pipes[iindex].fdIn = -1;
 
 #ifdef __uClinux__
 	/*remove the pipes*/
diff --git a/agent/snmpd.c b/agent/snmpd.c
index ae73eda1390e..2c925d8ff408 100644
--- a/agent/snmpd.c
+++ b/agent/snmpd.c
@@ -955,17 +955,13 @@ main(int argc, char *argv[])
             }
         } else {
             if ((PID = fdopen(fd, "w")) == NULL) {
+                close(fd);
                 snmp_log_perror(pid_file);
                 goto out;
             } else {
                 fprintf(PID, "%d\n", (int) getpid());
                 fclose(PID);
             }
-#ifndef _MSC_VER
-            /* The sequence open()/fdopen()/fclose()/close() makes MSVC crash,
-               hence skip the close() call when using the MSVC runtime. */
-            close(fd);
-#endif
         }
     }
 #endif

Re: Newly built 5.8 on QNX 7

[Aferjes B. R. <are...@gm...>]

Hi Ian,

Everything seems to be fine. Not sure why "tabreq" is getting NULL in
netsnmp_get_table_handler.

I have a suggestion. I see the same implementation with slight modification
in init_icmp() function in agent/mibgroup/mibII/icmp.c. There I can see the
table is using a different function "netsnmp_register_table_iterator2" to
register the table. Maybe this function might help you.

I'm not sure whether this will solve the issue. Just a suggestion so that
you can try.

Thanks,
Aferjes Blesswin Redeemson M

On Fri, Aug 7, 2020 at 12:21 AM Ian C via Net-snmp-coders <
net...@li...> wrote:

> I took Wes' advice and ran with -DALL, along with some extra DEBUGMSGTLs
> in suspect areas (-DALL output follows):
> void
> initialize_table_chAsinHwSbcNtpTable(void)
> {
>     syslog( LOG_ERR, "initialize_table_chAsinHwSbcNtpTable()");
>     const oid chAsinHwSbcNtpTable_oid[] = {1,3,6,1,4,1,25228,3,3,1,9,6,6};
>     const size_t chAsinHwSbcNtpTable_oid_len   =
> OID_LENGTH(chAsinHwSbcNtpTable_oid);
>     netsnmp_handler_registration    *reg;
>     netsnmp_iterator_info           *iinfo;
>     netsnmp_table_registration_info *table_info;
>
>     DEBUGMSGTL(("chAsinHwSbcNtpTable", "initializing table
> chAsinHwSbcNtpTable\n"));
>
>     reg = netsnmp_create_handler_registration(
>               "chAsinHwSbcNtpTable",     chAsinHwSbcNtpTable_handler,
>               chAsinHwSbcNtpTable_oid, chAsinHwSbcNtpTable_oid_len,
>               HANDLER_CAN_RONLY
>               );
>
>     table_info = SNMP_MALLOC_TYPEDEF( netsnmp_table_registration_info );
>     if(table_info == NULL) {
>         DEBUGMSGTL(("chAsinHwSbcNtpTable", "after SNMP_MALLOC_TYPEDEF( )
> table_info is _N_U_L_L!\n"));
>     }
>     else {
>         DEBUGMSGTL(("chAsinHwSbcNtpTable", "after SNMP_MALLOC_TYPEDEF( )
> table_info _NOT_ null\n"));
>     }
>     netsnmp_table_helper_add_indexes(table_info,
>                            ASN_OCTET_STR,  /* index: chAsinHwSbcNtpSbcName
> */
>                            0);
>     if(table_info == NULL) {
>         DEBUGMSGTL(("chAsinHwSbcNtpTable", "after
> netsnmp_table_helper_add_indexes( ) table_info is _N_U_L_L!\n"));
>     }
>     else {
>         DEBUGMSGTL(("chAsinHwSbcNtpTable", "after
> netsnmp_table_helper_add_indexes( ) table_info _NOT_ null\n"));
>     }
>     table_info->min_column = COLUMN_CHASINHWSBCNTPSBCNAME;
>     table_info->max_column = COLUMN_CHASINHWSBCNTPSTATUSSTRING;
>
>     iinfo = SNMP_MALLOC_TYPEDEF( netsnmp_iterator_info );
>     iinfo->get_first_data_point = chAsinHwSbcNtpTable_get_first_data_point;
>     iinfo->get_next_data_point  = chAsinHwSbcNtpTable_get_next_data_point;
>     iinfo->table_reginfo        = table_info;
>     iinfo->free_loop_context_at_end = nsModuleTable_loop_free;
>     iinfo->free_data_context = freeTableEntry;
>
>     if(iinfo->table_reginfo == NULL) {
>         DEBUGMSGTL(("chAsinHwSbcNtpTable", "before
> netsnmp_register_table_iterator( ) iinfo->table_reginfo is _N_U_L_L!\n"));
>     }
>     else {
>         DEBUGMSGTL(("chAsinHwSbcNtpTable", "before
> netsnmp_register_table_iterator( ) iinfo->table_reginfo  _NOT_ null\n"));
>     }
>     netsnmp_register_table_iterator( reg, iinfo );
>
>     /* Initialise the contents of the table here */
> }
>
>
> Now a snippet from the -DALL logging, but nothing stands out to me,
> perhaps someone on the list may have some idea:
>
> 9:callback:lock: locked (LIB,POST_READ_CONFIG)
> trace: netsnmp_register_callback(): callback.c, 296:
> callback: registered (0,0) at 806c818 with priority 0
> trace: _callback_unlock(): callback.c, 170:
> 9:callback:lock: unlocked (LIB,POST_READ_CONFIG)
> trace: subagent_init(): mibgroup/agentx/subagent.c, 162:
> agentx/subagent: initializing....  DONE
> trace: internal_register_config_handler(): read_config.c, 219:
> 9:read_config:register_handler: registering ./icSNMPntpSubAgentChA.exe
> com2sec
> trace: internal_register_config_handler(): read_config.c, 219:
> 9:read_config:register_handler: registering ./icSNMPntpSubAgentChA.exe
> com2sec6
> trace: internal_register_config_handler(): read_config.c, 219:
> 9:read_config:register_handler: registering ./icSNMPntpSubAgentChA.exe
> com2secunix
> trace: initialize_table_chAsinHwSbcNtpTable():
> C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp,
> 60:
> chAsinHwSbcNtpTable: initializing table chAsinHwSbcNtpTable
> trace: initialize_table_chAsinHwSbcNtpTable():
> C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp,
> 73:
> chAsinHwSbcNtpTable: after SNMP_MALLOC_TYPEDEF( ) table_info _NOT_ null
> trace: initialize_table_chAsinHwSbcNtpTable():
> C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp,
> 82:
> chAsinHwSbcNtpTable: after netsnmp_table_helper_add_indexes( ) table_info
> _NOT_ null
> trace: initialize_table_chAsinHwSbcNtpTable():
> C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp,
> 98:
> chAsinHwSbcNtpTable: before netsnmp_register_table_iterator( )
> iinfo->table_reginfo  _NOT_ null
> trace: netsnmp_inject_handler_before(): agent_handler.c, 444:
> handler:inject: injecting table_iterator before chAsinHwSbcNtpTable
> netsnmp_get_table_handler(NULL) called
> could not create table handler
>
> Thanks again Wes, and everyone else reading this!
>
> Ian
>
>
>
>
> On Thursday, August 6, 2020, 9:56:00 a.m. EDT, Ian C <mc...@ya...>
> wrote:
>
>
> Thanks Wes, will try this soon.
>
> On Wednesday, August 5, 2020, 1:47:24 p.m. EDT, Wes Hardaker <
> har...@us...> wrote:
>
>
> Ian C via Net-snmp-coders <net...@li...>
>
> writes:
>
> > Hi,
> >
> > We previously had net-snmp 5.6 running on QNX 6.5 (from pkgsrc), and had
> various
> > sub-agents retrieving data and working well. However we've recently
> migrated our OS
> > to QNX 7.0 and since there are no pkgsrc packages available for that OS
> we've
> > upgraded and compiled net-snmp 5.8 ourselves.
> >
> > Most of the system has ported well, GETs for scalars are fine; snmp
> table queries
> > for system OIDs such as ifTable & atTable also work, however any table
> query for our
> > own table-based subagents fail. While digging into this I noticed that
> upon start-up
> > our subagent reports:
> >
> > Qnx7->SubAgentChA.exe -Lo -d
> > netsnmp_get_table_handler(NULL) called
> > could not create table handler
>
>
> I'd run with -DALL in order to get a *lot* of debug output (assuming you
> didn't turn off debugging output).  Specifically, look for the same
> error message to figure out where in the code the problem is triggered
> from in the output trace.  Because this is where the code is:
>
>     netsnmp_mib_handler *
>     netsnmp_get_table_handler(netsnmp_table_registration_info *tabreq)
>     {
>         netsnmp_mib_handler *ret = NULL;
>
>         if (!tabreq) {
>             snmp_log(LOG_INFO, "netsnmp_get_table_handler(NULL) called\n");
>             return NULL;
>         }
>
> Which means that the function is getting called with a NULL input, which
> certainly shouldn't happen.  But *where* is calling it?
>
> -DALL should help identify that
> --
> Wes Hardaker
> Please mail all replies to net...@li...
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

Net-SNMP v5.9.rc2 available for testing

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

The next release candidate of Net-SNMP (5.9.rc2) is available at

https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9-pre-releases/

This is barely different from 5.8.1.rc1, but contains a 5.9 version
number instead.  There were too many API changes (though small) under
the V5-8-branches git branch to justify a 5.8.1 release, so we've
changed the pending version number 5.9.

This will hopefully be the last release of the 5.9 pre-releases.  Only
show stopping bug fixes should be committed at this point.

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

Re: Newly built 5.8 on QNX 7

[Ian C <mc...@ya...>]

 I took Wes' advice and ran with -DALL, along with some extra DEBUGMSGTLs in suspect areas (-DALL output follows):void
initialize_table_chAsinHwSbcNtpTable(void)
{
    syslog( LOG_ERR, "initialize_table_chAsinHwSbcNtpTable()");
    const oid chAsinHwSbcNtpTable_oid[] = {1,3,6,1,4,1,25228,3,3,1,9,6,6};
    const size_t chAsinHwSbcNtpTable_oid_len   = OID_LENGTH(chAsinHwSbcNtpTable_oid);
    netsnmp_handler_registration    *reg;
    netsnmp_iterator_info           *iinfo;
    netsnmp_table_registration_info *table_info;

    DEBUGMSGTL(("chAsinHwSbcNtpTable", "initializing table chAsinHwSbcNtpTable\n"));

    reg = netsnmp_create_handler_registration(
              "chAsinHwSbcNtpTable",     chAsinHwSbcNtpTable_handler,
              chAsinHwSbcNtpTable_oid, chAsinHwSbcNtpTable_oid_len,
              HANDLER_CAN_RONLY
              );

    table_info = SNMP_MALLOC_TYPEDEF( netsnmp_table_registration_info );
    if(table_info == NULL) {
        DEBUGMSGTL(("chAsinHwSbcNtpTable", "after SNMP_MALLOC_TYPEDEF( ) table_info is _N_U_L_L!\n"));
    }
    else {
        DEBUGMSGTL(("chAsinHwSbcNtpTable", "after SNMP_MALLOC_TYPEDEF( ) table_info _NOT_ null\n"));
    }
    netsnmp_table_helper_add_indexes(table_info,
                           ASN_OCTET_STR,  /* index: chAsinHwSbcNtpSbcName */
                           0);
    if(table_info == NULL) {
        DEBUGMSGTL(("chAsinHwSbcNtpTable", "after netsnmp_table_helper_add_indexes( ) table_info is _N_U_L_L!\n"));
    }
    else {
        DEBUGMSGTL(("chAsinHwSbcNtpTable", "after netsnmp_table_helper_add_indexes( ) table_info _NOT_ null\n"));
    }
    table_info->min_column = COLUMN_CHASINHWSBCNTPSBCNAME;
    table_info->max_column = COLUMN_CHASINHWSBCNTPSTATUSSTRING;
    
    iinfo = SNMP_MALLOC_TYPEDEF( netsnmp_iterator_info );
    iinfo->get_first_data_point = chAsinHwSbcNtpTable_get_first_data_point;
    iinfo->get_next_data_point  = chAsinHwSbcNtpTable_get_next_data_point;
    iinfo->table_reginfo        = table_info;
    iinfo->free_loop_context_at_end = nsModuleTable_loop_free;
    iinfo->free_data_context = freeTableEntry;
    
    if(iinfo->table_reginfo == NULL) {
        DEBUGMSGTL(("chAsinHwSbcNtpTable", "before netsnmp_register_table_iterator( ) iinfo->table_reginfo is _N_U_L_L!\n"));
    }
    else {
        DEBUGMSGTL(("chAsinHwSbcNtpTable", "before netsnmp_register_table_iterator( ) iinfo->table_reginfo  _NOT_ null\n"));
    }
    netsnmp_register_table_iterator( reg, iinfo );

    /* Initialise the contents of the table here */
}

Now a snippet from the -DALL logging, but nothing stands out to me, perhaps someone on the list may have some idea:
9:callback:lock: locked (LIB,POST_READ_CONFIG)
trace: netsnmp_register_callback(): callback.c, 296:
callback: registered (0,0) at 806c818 with priority 0
trace: _callback_unlock(): callback.c, 170:
9:callback:lock: unlocked (LIB,POST_READ_CONFIG)
trace: subagent_init(): mibgroup/agentx/subagent.c, 162:
agentx/subagent: initializing....  DONE
trace: internal_register_config_handler(): read_config.c, 219:
9:read_config:register_handler: registering ./icSNMPntpSubAgentChA.exe com2sec
trace: internal_register_config_handler(): read_config.c, 219:
9:read_config:register_handler: registering ./icSNMPntpSubAgentChA.exe com2sec6
trace: internal_register_config_handler(): read_config.c, 219:
9:read_config:register_handler: registering ./icSNMPntpSubAgentChA.exe com2secunix
trace: initialize_table_chAsinHwSbcNtpTable(): C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp, 60:
chAsinHwSbcNtpTable: initializing table chAsinHwSbcNtpTable
trace: initialize_table_chAsinHwSbcNtpTable(): C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp, 73:
chAsinHwSbcNtpTable: after SNMP_MALLOC_TYPEDEF( ) table_info _NOT_ null
trace: initialize_table_chAsinHwSbcNtpTable(): C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp, 82:
chAsinHwSbcNtpTable: after netsnmp_table_helper_add_indexes( ) table_info _NOT_ null
trace: initialize_table_chAsinHwSbcNtpTable(): C:/Users/clougia/workspace/SIN_4/SIN_QNX7/seg_src/SNMP/sinHwSbcNTPtable/channelA/chAsinHwSbcNtpTable.cpp, 98:
chAsinHwSbcNtpTable: before netsnmp_register_table_iterator( ) iinfo->table_reginfo  _NOT_ null
trace: netsnmp_inject_handler_before(): agent_handler.c, 444:
handler:inject: injecting table_iterator before chAsinHwSbcNtpTable
netsnmp_get_table_handler(NULL) called
could not create table handler
Thanks again Wes, and everyone else reading this!
Ian




    On Thursday, August 6, 2020, 9:56:00 a.m. EDT, Ian C <mc...@ya...> wrote:  
 
  Thanks Wes, will try this soon.

    On Wednesday, August 5, 2020, 1:47:24 p.m. EDT, Wes Hardaker <har...@us...> wrote:  
 
 Ian C via Net-snmp-coders <net...@li...>
writes:

> Hi,
> 
> We previously had net-snmp 5.6 running on QNX 6.5 (from pkgsrc), and had various
> sub-agents retrieving data and working well. However we've recently migrated our OS
> to QNX 7.0 and since there are no pkgsrc packages available for that OS we've
> upgraded and compiled net-snmp 5.8 ourselves. 
> 
> Most of the system has ported well, GETs for scalars are fine; snmp table queries
> for system OIDs such as ifTable & atTable also work, however any table query for our
> own table-based subagents fail. While digging into this I noticed that upon start-up
> our subagent reports:
> 
> Qnx7->SubAgentChA.exe -Lo -d
> netsnmp_get_table_handler(NULL) called
> could not create table handler

I'd run with -DALL in order to get a *lot* of debug output (assuming you
didn't turn off debugging output).  Specifically, look for the same
error message to figure out where in the code the problem is triggered
from in the output trace.  Because this is where the code is:

    netsnmp_mib_handler *
    netsnmp_get_table_handler(netsnmp_table_registration_info *tabreq)
    {
        netsnmp_mib_handler *ret = NULL;

        if (!tabreq) {
            snmp_log(LOG_INFO, "netsnmp_get_table_handler(NULL) called\n");
            return NULL;
        }

Which means that the function is getting called with a NULL input, which
certainly shouldn't happen.  But *where* is calling it?

-DALL should help identify that
-- 
Wes Hardaker
Please mail all replies to net...@li...
    

Re: Newly built 5.8 on QNX 7

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

Ian C via Net-snmp-coders <net...@li...>
writes:

> Hi,
> 
> We previously had net-snmp 5.6 running on QNX 6.5 (from pkgsrc), and had various
> sub-agents retrieving data and working well. However we've recently migrated our OS
> to QNX 7.0 and since there are no pkgsrc packages available for that OS we've
> upgraded and compiled net-snmp 5.8 ourselves. 
> 
> Most of the system has ported well, GETs for scalars are fine; snmp table queries
> for system OIDs such as ifTable & atTable also work, however any table query for our
> own table-based subagents fail. While digging into this I noticed that upon start-up
> our subagent reports:
> 
> Qnx7->SubAgentChA.exe -Lo -d
> netsnmp_get_table_handler(NULL) called
> could not create table handler

I'd run with -DALL in order to get a *lot* of debug output (assuming you
didn't turn off debugging output).  Specifically, look for the same
error message to figure out where in the code the problem is triggered
from in the output trace.  Because this is where the code is:

    netsnmp_mib_handler *
    netsnmp_get_table_handler(netsnmp_table_registration_info *tabreq)
    {
        netsnmp_mib_handler *ret = NULL;

        if (!tabreq) {
            snmp_log(LOG_INFO, "netsnmp_get_table_handler(NULL) called\n");
            return NULL;
        }

Which means that the function is getting called with a NULL input, which
certainly shouldn't happen.  But *where* is calling it?

-DALL should help identify that
-- 
Wes Hardaker
Please mail all replies to net...@li...

Newly built 5.8 on QNX 7

[Ian C <mc...@ya...>]

Hi,
We previously had net-snmp 5.6 running on QNX 6.5 (from pkgsrc), and had various sub-agents retrieving data and working well. However we've recently migrated our OS to QNX 7.0 and since there are no pkgsrc packages available for that OS we've upgraded and compiled net-snmp 5.8 ourselves.  

Most of the system has ported well, GETs for scalars are fine; snmp table queries for system OIDs such as ifTable & atTable also work, however any table query for our own table-based subagents fail. While digging into this I noticed that upon start-up our subagent reports:
Qnx7->SubAgentChA.exe -Lo -dnetsnmp_get_table_handler(NULL) calledcould not create table handler

The subagent will run but no queries ever reach it.  If anyone has any thoughts on how to resolve this I'd love to get the feedback.
thanks,Ian

Re: SNMP proxy timeout lockup other requests

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

François Isabelle <fra...@gm...> writes:

> I just want to being your attention to the issue reported on GitHub 
> https://github.com/net-snmp/net-snmp/issues/147 and the corresponding
> pull-request I submitted.

Coincidentally I merged this patch yesterday, and just now found this message.
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Regarding .packlist in net-snmp code

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

Narendra Kumar S S <ssn...@gm...> writes:

> When I build net-snmp code, I am getting a file by name .packlist,
> which contains the list of file that will get delivered when the
> package is installed.  I want to understand the significance of this
> file and whether this file is used in the installed system?

The .packlist is created by the perl module specific build system.  You
can safely ignore the files as part of the build process I believe (I'm
not an expert in how they're used).
-- 
Wes Hardaker
Please mail all replies to net...@li...

Net-SNMP 5.8.1.rc1 available for testing

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

The first release candidate of Net-SNMP 5.8.1 is available at

https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8.1-pre-releases/

About release candidates: as a reminder, Net-SNMP development policy [1]
is that any changes that are to go into the V5-8-patches branch to be
included in this release from now on must have +3 people on -coders
vouch for it as being a change that should go into the release.
Proposed changes should be posted here (-coders) or as a pull request
with a reference to it posted here.


The CHANGES file entries for 5.8.1:

*5.8.1*
    snmplib:
      - Add IPv6 support to DTLSUDP transport
      - use new netsnmp_sockaddr_storage in netsnmp_addr_pair
      - add base_transport ptr for tunneled transports
      - Add support for OpenSSL 1.1.1
      - Dtls: overhaul of debug
      - Remove inline versions of container funcs

    snmpd:
      - Use ETHTOOL_GLINKSETTINGS when available Newer Linux kernels
	support ETHTOOL_GLINKSETTINGS. Use it when available instead of the
	older and deprecated ETHTOOL_GSET. This patch avoids that the Linux
	kernel reports the following kernel warning: warning: 'snmpd' uses
	legacy ethtool link settings API, link modes are only partially
	reported See also https://sourceforge.net/p/net-snmp/patches/1387/.
	[bvanassche: reworked this patch significantly]
      - Reduce the time needed to execute "pass" scripts on BSD systems See
	also https://github.com/net-snmp/net-snmp/issues/8.
      - [BUG 2926]: Make it possible to set agentXPingInterval for a
	subagent - register agentXPingInterval for the subagent list
	handler, before it was registered for snmp - added agentxTimeout to
	the subagent list handler. It's now possible to set for snmpd and
	the subagent. See 'man snmpd.conf' - added agentxRetries to the
	subagent list handler. See 'man snmpd.conf'. It's never used in the
	subagent, but it's now following the documentation Signed-off-by:
	Anders Wallin <wal...@gm...>

    snmptrap:
      - BUG: 2899: Patch from Drew Roedersheimer to set library
	engineboots/time values before sending

    snmptrapd:
      - Add support for the latest libmysqlclient version

    libsnmp:
      - Scan MIB directories in alphabetical order This guarantees that
	e.g. mibs/RFC1213-MIB.txt is read before mibs/SNMPv2-MIB.txt. The
	order in which these MIBs is read matters because both define
	sysLocation but with different attributes.

    unspecified:
      - [BUG 2930]: Fix a Solaris hrSWInst crash Avoid that snmpd crashes
	on Solaris when querying software packages with an empty CATEGORY
	field. See also https://sourceforge.net/p/net-snmp/bugs/2930/. See
	also https://sourceforge.net/p/net-snmp/patches/1390/.

    FreeBSD:
      - Fix first byte of IF-MIB::ifPhysAddress   Don't write past the
	interface name, and use temporary copy instead. This fixes the
	first byte of ifPhysAddress always being 0 on FreeBSD. See also
	https://sourceforge.net/p/net-snmp/code/merge-requests/20/. [
	bvanassche: edited patch title / added test for malloc() result /
	reduced number of free(if_name) calls ]

    Win32:
      - BUG: 2779541 Fixed handle leak in pass_persist.

[1] http://www.net-snmp.org/dev/release-policy.html
-- 
Wes Hardaker
Please mail all replies to net...@li...

Regarding .packlist in net-snmp code

[Narendra K. S S <ssn...@gm...>]

Hi,

When I build net-snmp code, I am getting a file by name .packlist, which
contains the list of file that will get delivered when the package is
installed.
I want to understand the significance of this file and whether this file is
used in the installed system?

Regards,
Narendra

SNMP proxy timeout lockup other requests

[François I. <fra...@gm...>]

Hi.
I just want to being your attention to the issue reported on GitHub
https://github.com/net-snmp/net-snmp/issues/147 and the corresponding
pull-request I submitted.

Thanks
Regards.
Frank

snmp-response form a source_ip

[SURYA T S <sur...@gm...>]

does snmpget (with netsnmp library) compare the src IP of the source
ip of response pkt to the dest IP of the request packet?

I have made changes for snmp response from a source ip, but on
verifying the changes am getting a timeout error.

How can we verify the changes without a timeout error.

root@Ubuntu3381:~# snmpwalk -v2c -c public 10.1.1.1 .1.3.6.1.2.1.17.1.1
12:39:49.623579 IP 10.1.1.2.42888 > 10.1.1.1.snmp:  GetNextRequest(28)  17.1.1
12:39:49.645601 IP 10.100.74.208.snmp > 10.1.1.2.42888:
GetResponse(35)  17.1.1.0=90_20_c2_25_cc_80
......
......
12:39:54.629226 IP 10.1.1.2.42888 > 10.1.1.1.snmp:  GetNextRequest(28)  17.1.1
12:39:54.631532 IP 10.100.74.208.snmp > 10.1.1.2.42888:
GetResponse(35)  17.1.1.0=90_20_c2_25_cc_80

Timeout: No Response from 10.1.1.1

[SURYA T S <sur...@gm...>]

does snmpget (with netsnmp library) compare the src IP of the source
ip of response pkt to the dest IP of the request packet?

I have made changes for snmp response from a source ip, but on
verifying the changes am getting a timeout error.

How can we verify the changes without a timeout error.

root@Ubuntu3381:~# snmpwalk -v2c -c public 10.1.1.1 .1.3.6.1.2.1.17.1.1
12:39:49.623579 IP 10.1.1.2.42888 > 10.1.1.1.snmp:  GetNextRequest(28)  17.1.1
12:39:49.645601 IP 10.100.74.208.snmp > 10.1.1.2.42888:
GetResponse(35)  17.1.1.0=90_20_c2_25_cc_80
......
......
12:39:54.629226 IP 10.1.1.2.42888 > 10.1.1.1.snmp:  GetNextRequest(28)  17.1.1
12:39:54.631532 IP 10.100.74.208.snmp > 10.1.1.2.42888:
GetResponse(35)  17.1.1.0=90_20_c2_25_cc_80

Timeout: No Response from 10.1.1.1

Re: Release timeline

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

Wes Hardaker <har...@us...> writes:

> That one should be easy to fix and I think should go in.  Wanted to bug
> Robert first though.

Looks like it'll slip to next week due to a scheduled vacation.

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

Re: Is Net-snmp Supported AS400 Servers???

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

"Satpute, Niranjan" <Nir...@ex...> writes:

> We are trying to inventory of AS400 devices using Net-SNMP with SNMPv3. We are
> not able to pull the data from AS400 device as everything is configured
> correctly.

There is no reason it shouldn't work.  Make sure you understand how
net-snmp with version 3 works:

http://www.net-snmp.org/wiki/index.php/TUT:SNMPv3_Options
-- 
Wes Hardaker
Please mail all replies to net...@li...

Is Net-snmp Supported AS400 Servers???

[Satpute, N. <Nir...@ex...>]

**This message has been automatically created by the Saint-Gobain emails Antivirus protection**

A file directly attached to this message or included in an attached zip or archive file has been removed. Its extension is not allowed by the Saint-Gobain Security Policy. If you want to send or receive this file, please use the Secure File Transfer (SFTS) that is available on the Saint-Gobain Portal / “Collaboration Tools”.

**Ce message a été automatiquement généré par la protection antivirale Saint-Gobain des emails **

Hello Team,

We are trying to inventory of AS400 devices using Net-SNMP with SNMPv3. We are not able to pull the data from AS400 device as everything is configured correctly.

Could you please confirm us If Net-SNMP is supported for AS400 Device?  We are able to connect to AS400 device with Paeslers SNMP Tester but not with Net-SNMP.

We have also put all required MIB's but still not get luck on it.

We are waiting for your reply.


[cid:image001.png@01D4574C.D7099F10]



Niranjan Satpute
Systems Engineer


Cloud Factory
Saint-Gobain DSI Groupe
SG INDEC, Mumbai, India
Mob :+91-9175014446
E-mail: Nir...@ex...<mailto:Nir...@ex...>



[Discover Cloud Factory][logo-cloud-factory-blanc]<https://portal.saint-gobain.com/fr/web/cloud-factory>  [mySG_512] <https://my.saint-gobain.com/groups/cloud-factory>

Re: RedHat errors in packaging

[Josef R. <jr...@re...>]

Hi Magnus,

sorry for delay. I have to admit, I've lost this bug report from my sight.
Due this is downstream issue, I'll deal with it.

Once again, I'm sorry for inconveniences.

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

----- Original Message -----
| From: "Magnus Fromreide" <ma...@ly...>
| To: net...@li..., jr...@re...
| Sent: Sunday, July 5, 2020 6:18:42 PM
| Subject: RedHat errors in packaging
| 
| Hello!
| 
| I found a bug in the RedHat/Fedora net-snmp packaging a few months back and
| wrote a bug report (https://bugzilla.redhat.com/show_bug.cgi?id=1815984) but
| nothing have happend with it.
| 
| This broke my intended use of --compile-subagent
| 
| The problem is that they have added a wrapper script for net-snmp-config and
| fails to properly quote the arguments they are passing on so any spaces
| embedded in arguments are mangled into argument separators.
| 
| This is an obvious case of using $* where "$@" is needed.
| 
| Anyway, how does one go about getting that bug resolved downstream?
| 
| /MF
| 
| 

Re: Release timeline

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

Magnus Fromreide <ma...@ly...> writes:

> On Mon, Jun 29, 2020 at 07:11:16AM -0700, Wes Hardaker via Net-snmp-coders wrote:
> > Hugh McMaster <hug...@ou...> writes:
> > 
> > > net-snmp v5.8.1.pre2 was released a little over four months ago.
> > > 
> > > Following a lot of excellent work by Bart and others since then, what
> > > is the proposed timeline for the next pre-release or final v5.8.1?
> > 
> > We don't have a good proposed timeline.  So let's come up with one:
> > 
> > + We could release 5.8.1.pre3 this week
> >     + (and people should test it)
> > + We could then freeze development in that  branch and shift into
> >   release mode
> > + Push 5.8.1.rc1 next week and start "really freezing"
> > 
> > Is there consensus that 5.8.1 is "ready" to really lock down.  It's
> > certainly beyond time it gets out the door.
> 
> I think 5-8-patches looks good at the moment.

There was one bug I hit Friday while I was starting the process that I
wanted to look into.

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

That one should be easy to fix and I think should go in.  Wanted to bug
Robert first though.
-- 
Wes Hardaker
Please mail all replies to net...@li...

RedHat errors in packaging

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

Hello!

I found a bug in the RedHat/Fedora net-snmp packaging a few months back and
wrote a bug report (https://bugzilla.redhat.com/show_bug.cgi?id=1815984) but
nothing have happend with it.

This broke my intended use of --compile-subagent

The problem is that they have added a wrapper script for net-snmp-config and
fails to properly quote the arguments they are passing on so any spaces 
embedded in arguments are mangled into argument separators.

This is an obvious case of using $* where "$@" is needed.

Anyway, how does one go about getting that bug resolved downstream?

/MF

Re: Release timeline

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

On Mon, Jun 29, 2020 at 07:11:16AM -0700, Wes Hardaker via Net-snmp-coders wrote:
> Hugh McMaster <hug...@ou...> writes:
> 
> > net-snmp v5.8.1.pre2 was released a little over four months ago.
> > 
> > Following a lot of excellent work by Bart and others since then, what
> > is the proposed timeline for the next pre-release or final v5.8.1?
> 
> We don't have a good proposed timeline.  So let's come up with one:
> 
> + We could release 5.8.1.pre3 this week
>     + (and people should test it)
> + We could then freeze development in that  branch and shift into
>   release mode
> + Push 5.8.1.rc1 next week and start "really freezing"
> 
> Is there consensus that 5.8.1 is "ready" to really lock down.  It's
> certainly beyond time it gets out the door.

I think 5-8-patches looks good at the moment.

/MF

Re: Release timeline

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

On 2020-06-29 07:11, Wes Hardaker via Net-snmp-coders wrote:
> Hugh McMaster <hug...@ou...> writes:
> 
>> net-snmp v5.8.1.pre2 was released a little over four months ago.
>>
>> Following a lot of excellent work by Bart and others since then, what
>> is the proposed timeline for the next pre-release or final v5.8.1?
> 
> We don't have a good proposed timeline.  So let's come up with one:
> 
> + We could release 5.8.1.pre3 this week
>     + (and people should test it)
> + We could then freeze development in that  branch and shift into
>   release mode
> + Push 5.8.1.rc1 next week and start "really freezing"
> 
> Is there consensus that 5.8.1 is "ready" to really lock down.  It's
> certainly beyond time it gets out the door.

Not sure what others think but I'm fine with locking down 5.8.1.

Thanks,

Bart.

Re: Disable snmpv2 and v1, and enable snmpv3.

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

Craig Small <csmall@dropbear.xyz> writes:

>     Observed NETSNMP_DISABLE_SNMPV2C, NETSNMP_DISABLE_SNMPV1 defines. How
>     can we set and unset it?
> 
> That's done at compile time with things like configure
> --disable-snmpv1

Specifically, the only real benifit in doing so is that it removes the
actual code that implements v1/v2c.  That code is fairly small, the
savings is minimal.  It was developed as a sponsored effort by someone
that wanted to be ultra-sure that v1/v2c wouldn't be used.
-- 
Wes Hardaker
Please mail all replies to net...@li...

Re: Release timeline

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

Hugh McMaster <hug...@ou...> writes:

> net-snmp v5.8.1.pre2 was released a little over four months ago.
> 
> Following a lot of excellent work by Bart and others since then, what
> is the proposed timeline for the next pre-release or final v5.8.1?

We don't have a good proposed timeline.  So let's come up with one:

+ We could release 5.8.1.pre3 this week
    + (and people should test it)
+ We could then freeze development in that  branch and shift into
  release mode
+ Push 5.8.1.rc1 next week and start "really freezing"

Is there consensus that 5.8.1 is "ready" to really lock down.  It's
certainly beyond time it gets out the door.

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

Re: Trap engine ID eth0

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

Philippe Denis <phd...@gm...> writes:

> Hello all,
> 
> I have a question linked to snmp traps in V3 version.
>

Sorry for responding so late, but you should read this page which
discusses how v3 traps and informs work with respect to engineIDs:

http://www.net-snmp.org/wiki/index.php/TUT:snmptrap_SNMPv3

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

Re: source ip for snmp-responses

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

SURYA T S <sur...@gm...> writes:

> Please suggest me better way to change srcip in snmpresponses,

Have you set the "agentaddress" token in snmpd.conf?  This should have
an effect.

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