GithubHelp home page GithubHelp logo

net-snmp / net-snmp Goto Github PK

View Code? Open in Web Editor NEW
289.0 28.0 211.0 73.26 MB

A SNMP application library, tools and daemon

License: Other

Makefile 0.56% C 88.91% C++ 0.04% Shell 3.88% Perl 4.61% M4 1.26% OpenEdge ABL 0.04% XS 0.38% Python 0.19% Batchfile 0.08% Raku 0.01% Mercury 0.04% HTML 0.01%

net-snmp's Introduction

	       README file for net-snmp Version: 5.10

DISCLAIMER

  The Authors assume no responsibility for damage or loss of system
  performance as a direct or indirect result of the use of this
  software.  This software is provided "as is" without express or
  implied warranty.

TABLE OF CONTENTS

  Disclaimer
  Table Of Contents
  Introduction
* Supported Architectures
  Availability
  Web Page
* Installation
  Copying And Copyrights
* Frequently Asked Questions
  Helping Out
* Code Update Announcements
* Mailing Lists
  Agent Extensibility
  Example Agent Configuration and Usage
  Configuration
  Submitting Bug Reports
  Closing
  Thanks

  * = Required Reading.

INTRODUCTION

  This package was originally based on the CMU 2.1.2.1 snmp code.  It
  has been greatly modified, restructured, enhanced and fixed.  It
  hardly looks the same as anything that CMU has ever released.  It
  was renamed from cmu-snmp to ucd-snmp in 1995 and later renamed from
  ucd-snmp to net-snmp in November 2000.

  This README file serves as a starting place to learn about the
  package, but very little of the documentation is contained within
  this file.  The FAQ is an excellent place to start as well.
  Additionally, there are a bunch of README files for specific
  architectures and specific features.  You might wish to look at some
  of these other files as well.

SUPPORTED ARCHITECTURES

  Please see the FAQ for this information.

  Please let us know if you compile it on other OS versions and it
  works for you so we can add them to the above list.

  Porting:  Please! read the PORTING file.

  Also note that many architecture have architecture specific README
  files, so you should check to see if there is one appropriate to
  your platform.

AVAILABILITY

  Download:
    - http://www.net-snmp.org/download/
  Web page:
    - http://www.net-snmp.org/
  Project Wiki:
    - http://www.net-snmp.org/wiki/
  GitHub Project:
    - https://github.com/net-snmp/net-snmp/
  Sourceforge Project page:
    - http://sourceforge.net/projects/net-snmp

  The old ucd-snmp.ucdavis.edu web site and ftp server is now
  offline and should not be accessed any longer.

WEB PAGES

  http://www.net-snmp.org/
  http://sourceforge.net/projects/net-snmp
  http://www.net-snmp.org/wiki/

INSTALLATION

  See the INSTALL file distributed with this package.

COPYING AND COPYRIGHTS

  See the COPYING file distributed with this package.

FREQUENTLY ASKED QUESTIONS

  See the FAQ file distributed with this package.
  This is also available on the project Wiki at

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

  so that the wider Net-SNMP community can help maintain it!

HELPING OUT

  This is a project worked on by people around the net.  We'd love
  your help, but please read the PORTING file first.  Also, subscribe
  to the net-snmp-coders list described below and mention what you're
  going to work on to make sure no one else is already doing so!
  You'll also need to keep up to date with the latest code snapshot,
  which can be obtained from CVS using the information found at
  http://www.net-snmp.org/cvs/.

  Contributions to the Net-SNMP source code in any form are greatly
  appreciated.  We expect the parties providing such contributions to
  have the right to contribute them to the Net-SNMP project or that
  the parties that do have the right have directed the person
  submitting the contribution to do so.  In addition, all contributors
  need to be aware that if the contribution is accepted and
  incorporated into the Net-SNMP project, it will be redistributed
  under the terms of the license agreement used for the entire body of
  work that comprises the Net-SNMP project (see the COPYING file for
  details).  If this license agreement ever changes the contribution
  will continue to be released under any new licenses as well.  Thank
  you, in advance, for your gracious contributions.

CODE UPDATE ANNOUNCEMENTS

  See the NEWS file and the ChangeLog file for details on what has
  changed between releases.

  We hate broadcasting announce messages to other mailing lists and
  newsgroups, so there is a mailing list set up to handle release
  announcements.  Any time we put new software out for ftp, we'll mail
  this fact to [email protected].  See the
  MAILING LISTS section described below to sign up for these
  announcements.

  We will post new announcements on a very infrequent basis to the
  other channels (the other snmp mailing lists and newsgroups like
  comp.protocols.snmp), but only for major code revisions and not for
  bug-fix patches or small feature upgrades.

MAILING LISTS

  The lists:

    A number of mailing lists have been created for support of the project:
    The main ones are:

      [email protected]  -- For official announcements
      [email protected]     -- For usage discussions
      [email protected]    -- For development discussions

    The -coders list is intended for discussion on development of code
    that will be shipped as part of the package.  The -users list is
    for general discussion on configuring and using the package,
    including issues with coding user-developed applications (clients,
    managers, MIB modules, etc).

    Please do *NOT* send messages to both -users and -coders lists.
    This is completely unnecessary and simply serves to further
    overload (and annoy) the core development team.   If in doubt,
    just use the -users list.


    The other lists of possible interest are:

      [email protected]       -- For cvs update announcements
      [email protected]      -- For Bug database update announcements
      [email protected]   -- For Patch database update announcements

    Please do NOT post messages to these lists (or to the announce list above).
    Bug reports and Patches should be submitted via the Source Forge tracker
    system.  See the main project web pages for details.

    To subscribe to any of these lists, please see:
  
      http://www.net-snmp.org/lists/


  Archives:
    The archives for these mailing lists can be found by following links at

      http://www.net-snmp.org/lists/

AGENT EXTENSIBILITY

  The agent that comes with this package is extensible through use of
  shell scripts and other methods.  See the configuration manual pages
  (like snmpd.conf) and run the snmpconf perl script for further details.

  You can also extend the agent by writing C code directly.  The agent
  is extremely modular in nature and you need only create new files,
  re-run configure and re-compile (or link against its libraries).  No
  modification of the distributed source files are necessary.  See the
  following files for details on how to go about this:
  http://www.net-snmp.org/tutorial-5/toolkit/,
  agent/mibgroup/examples/*.c

  Also, see the local/mib2c program and its README file for help in
  turning a textual mib description into a C code template.

  We now support AgentX for subagent extensibility.  The net-snmp
  agent can run as both a master agent and a subagent.  Additionally,
  a toolkit is provided that enables users of it to easily embed a
  agentx client into external applications.  See the tutorial at
  http://www.net-snmp.org/tutorial-5/toolkit/ for an example of how
  go about doing this.

CONFIGURATION

  See the man/snmp.conf.5 manual page.

  For the agent, additionally see the man/snmpd.conf.5 manual page.

  For the snmptrapd, see the man/snmptrapd.conf.5 manual page.

  You can also run the snmpconf perl script to help you create some of
  these files.

SUBMITTING BUG REPORTS

  Important: *Please* include what version of the net-snmp (or
  ucd-snmp) package you are using and what architecture(s) you're
  using, as well as detailed information about exactly what is wrong.

  To submit a bug report, please use the web interface at
  https://github.com/net-snmp/net-snmp/issues.  It is a full-fledged
  bug-tracking system that will allow you to search for already
  existing bug reports as well as track the status of your report as
  it is processed by the core developers.

  If you intend to submit a patch as well, please read the PORTING
  file before you do so and then submit it as a GitHub pull request.

CLOSING

  We love patches.  Send some to us!  But before you do, please see
  the 'PORTING' file for information on helping us out with the
  process of integrating your patches (regardless of whether it is a new
  feature implementation or a new port).

  Also, We're interested if anyone actually uses/likes/hates/whatever
  this package...  Mail us a note and let us know what you think of it!

  Have fun and may it make your life easier,

    The net-snmp developers

THANKS

  The following people have contributed various patches and
  improvements.  To them we owe our deepest thanks (and you do too!):

    Wes Hardaker <[email protected]>
    Steve Waldbusser <[email protected]>
    Dan A. Dickey <[email protected]>
    Dave Shield <[email protected]>
    Giovanni S. Marzot <[email protected]>
    Niels Baggesen <[email protected]>
    Simon Leinen <[email protected]>
    David T. Perkins <[email protected]>
    Mike Perik <[email protected]>
    Sanjai Narain <[email protected]>
    [email protected]
    Gary Palmer <[email protected]>
    Marc G. Fournier <[email protected]>
    Gary A. Hayward <[email protected]>
    Jennifer Bray <[email protected]>
    Philip Guenther <[email protected]>
    Elwyn B Davies <[email protected]>
    Simon Burge <[email protected]>
    David Paul Zimmerman <[email protected]>
    Alan Batie <[email protected]>
    Michael Douglass <[email protected]>
    Ted Rule <[email protected]>
    Craig Bevins <[email protected]>
    Arther Hyun <[email protected]>
    Cristian Estan <[email protected]>
    Eugene Polovnikov <[email protected]>
    Jakob Ellerstedt <[email protected]>
    Michael J. Slifcak <[email protected]>
    Jonas Olsson <[email protected]>
    James H. Young <[email protected]>
    Jeff Johnson <[email protected]>
    Markku Laukkanen <[email protected]>
    Derek Simkowiak <[email protected]>
    David F. Newman <[email protected]>
    Nick Amato <[email protected]>
    Mike Baer <[email protected]>
    Patrick Lawrence <[email protected]>
    Russ Mundy <[email protected]>
    Olafur Gudmundsson <[email protected]>
    David Reeder <[email protected]>
    Ed Lewis <[email protected]>
    Bill Babson <[email protected]>
    Chris Smith <[email protected]>
    Mike Michaud <[email protected]>
    Andy Hood <[email protected]>
    Robert Story <[email protected]>
    Bert Driehuis <[email protected]>
    Juergen Schoenwaelder <[email protected]>
    Frank Strauss <[email protected]>
    Ragnar Kjørstad <[email protected]>
    Jochen Kmietsch <[email protected]>
    Jun-ichiro itojun Hagino <[email protected]>
    John L Villalovos <[email protected]>
    Christoph Mammitzsch <[email protected]>
    Arne Oesleboe <[email protected]>
    Jeff Cours <[email protected]>
    Karl Schilke <[email protected]>
    John Naylon <[email protected]>
    Ken Hornstein <[email protected]>
    Martin Oldfield <[email protected]>
    Harrie Hazewinkel <[email protected]>
    Mark Ferlatte <[email protected]>
    Marus Meissner <[email protected]>
    Stephan Wenzer <[email protected]>
    Ron Mevissen <[email protected]>
    T.J. Mather <[email protected]>
    Craig Setera <[email protected]>
    Katsuhisa ABE <[email protected]>
    Axel Kittenberger <[email protected]>
    Johannes Schmidt-Fischer <[email protected]>
    Jeffrey Watson <[email protected]>
    Bruce Shaw <[email protected]>
    Stefan Radman <[email protected]>
    Stephen J. Friedl <[email protected]>
    Alex Burger <[email protected]>
    Christophe Varoqui <[email protected]>
    Srikanth Pindiproli <[email protected]>
    Kevin Graham <[email protected]>
    Xiaofeng Ling <[email protected]>
    Brandon Knitter <knitterb@bl...>
    Andrew Findlay <[email protected]>
    Ron Tabor <[email protected]>
    Peter Warasin <[email protected]>
    Bob Rowlands <[email protected]>
    Peter Hicks <[email protected]>
    Andy Smith <[email protected]>
    Nick Barkas <[email protected]>
    Noah Friedman <[email protected]>
    Geert De Peuter <[email protected]>
    Magnus Fromreide <[email protected]>
    Marcus Meissner <[email protected]>
    Andrew Rucker Jones <[email protected]>
    Dai.H. <[email protected]>
    Thomas Anders <[email protected]>
    Vladislav Bogdanov <[email protected]>
    Peter Martin <[email protected]>
    Thomas Lackey <[email protected]>
    Joe Buehler <[email protected]>
    Anders Persson <[email protected]>
    Rojer <[email protected]>
    Bart Van Assche <[email protected]>
    Pablo Carboni <[email protected]>
    Bill Fenner <[email protected]>
    Brian Sipos <[email protected]>
    Eugene M. Kim <[email protected]>
    Anders Wallin <[email protected]>
    Andrew Stormont <[email protected]>
    Keith Mendoza <[email protected]>
    Igor Ryzhov <[email protected]>

  We've probably forgotten people on this list.  Let us know if you've
  contributed code and we've left you out.

net-snmp's People

Contributors

abergmann avatar alexb7 avatar andreasstieger avatar ashamedbit avatar bvanassche avatar davidkorczynski avatar ezenderink avatar fenner avatar feroz-ahmed avatar glebius avatar guillemj avatar hardaker avatar jridky avatar lespocky avatar lukas-wimmer avatar magfr avatar micha137 avatar minfrin avatar moshekaplan avatar ncopa avatar nielsb avatar paveltrushkin avatar pmorch avatar po5857 avatar projectmutilation avatar rstory avatar sea-n avatar sthen avatar thesamesam avatar wallinux avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

net-snmp's Issues

net-snmp-5.8: broken ErrorMsg at ucd-snmp

No error messages at UCD-SNMP-MIB::prErrMessage and UCD-SNMP-MIB::dskErrorMsg

Steps to reproduce:

Create test-fail-snmpd.conf

rocommunity test

disk /mnt/test1 50%
disk /mnt/test2 50%

proc snmpd
proc nonexistent

Populate /mnt

sudo mkdir /mnt/test{1,2}
sudo mount -t tmpfs tmpfs1 -o size=10m /mnt/test1
sudo mount -t tmpfs tmpfs2 -o size=10m /mnt/test2
sudo dd if=/dev/zero of=/mnt/test2/file bs=1M count=9

Run snmpd

sudo snmpd -C -c test-fail-snmpd.conf -f -Le udp:localhost:161

Query disk and proc error mesages

snmpwalk -c test -v1 localhost UCD-SNMP-MIB::prErrMessage
snmpwalk -c test -v1 localhost UCD-SNMP-MIB::dskErrorMsg

There is no data from both snmpwalk queries

Let's make a trick: reorder config lines

Create test-pass-snmpd.conf with reordered proc and disk lines

rocommunity test

disk /mnt/test2 50%
disk /mnt/test1 50%

proc nonexistent
proc snmpd

Rerun snmpd with new config

sudo snmpd -C -c test-pass-snmpd.conf -f -Le udp:localhost:161

Query disk and proc error mesages one more time

snmpwalk -c test -v1 localhost UCD-SNMP-MIB::dskErrorMsg

UCD-SNMP-MIB::dskErrorMsg.1 = STRING: /mnt/test2: less than 50% free (= 10%)
snmpwalk -c test -v1 localhost UCD-SNMP-MIB::prErrMessage

UCD-SNMP-MIB::prErrMessage.1 = STRING: No nonexistent process running

It looks better. But incomplete.

The same tests with both config files for net-snmp-5.7.3 works as expected:

snmpwalk -c test -v1 localhost UCD-SNMP-MIB::dskErrorMsg

UCD-SNMP-MIB::dskErrorMsg.1 = STRING: /mnt/test2: less than 50% free (= 10%)
UCD-SNMP-MIB::dskErrorMsg.2 = STRING: 
snmpwalk -c test -v1 localhost UCD-SNMP-MIB::prErrMessage

UCD-SNMP-MIB::prErrMessage.1 = STRING: No nonexistent process running
UCD-SNMP-MIB::prErrMessage.2 = STRING: 

Environment

The tests were produced on gentoo linux amd64 with current HEAD
net-snmp-v5.8-780-g06c09a117 (06c09a1)

Details

The problem appears at 9b9c0e2

MIBs: Use asprintf() instead of snprintf() to prevent truncation
This patch addresses most gcc 7 warnings about output buffer truncation.

"clientaddr" option doesn't seem to be recognized by snmpset

We are using the clientaddr option to specify the source interface for a lot of our SNMP commands as we have multiple tun interfaces on a monitoring machine.

Running a snmpget command works as expected. Example: snmpget -v2c -cpublic 10.0.0.1 --clientaddr=192.168.0.10 sysContact.0

Running a set command like this
snmpset -v2c -cprivate 10.0.0.1 --clientaddr=192.168.0.10 sysContact.0 s "Test"
results in an error:
clientaddr=192.168.0.10: Bad object type: 1

It appears as if the snmpset command does not recognize the clientaddr option like get/walk commands do.

Memory leak in netsnmp_memdup in file agent_trap.c:1622 (possible fix in description)

Hi,

I found the following memory leak.

Direct leak of 68 byte(s) in 4 object(s) allocated from:
    #0 0x7fbe42082330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x564430bf1b5a in netsnmp_memdup /home/Code/packages/net-snmp/core/snmplib/tools.c:288

SUMMARY: AddressSanitizer: 68 byte(s) leaked in 4 allocation(s).

This is obviously not enough to know why it happens, so I followed our steps on why it happens.

Basically, we enter a function within agent_trap.c called netsnmp_create_v3user_notification_session. In here memory is duplicated at line 1622:

    /** engineId */
    session.contextEngineID = netsnmp_memdup(usmUser->engineID,
                                         usmUser->engineIDLen);
    session.contextEngineIDLen = usmUser->engineIDLen;

However at some point we enter the goto bail; part and the following is performed, at line 1662:

  bail:
    /** free any allocated mem in session */
    SNMP_FREE(session.securityAuthProto);
    SNMP_FREE(session.securityPrivProto);

When adding SNMP_FREE(session.contextEngineID); , changing it to:

  bail:
    /** free any allocated mem in session */
    SNMP_FREE(session.securityAuthProto);
    SNMP_FREE(session.securityPrivProto);
    SNMP_FREE(session.contextEngineID);

The memory leak is gone.

Timeout issue with snmpwalk command

Hi Team,

We have timeout issue with snmpwalk command, we have planned to manually fetch below values instead of snmpwalk.

snmpwalk --clientaddr=localhost:162 -c local -v 2c localhost dskPath
snmpwalk --clientaddr=localhost:162 -c local -v 2c localhost dskPercent

Would like to know what values are actually being fetched, we have searched online but couldn’t find sufficient information.

Thanks in Advance,
Kamal

net-snmp v5.8: trapsink to localhost causes snmpd to fail

@bvanassche I encountered the same issue as described in

on my Gentoo system with with the net-analyzer/net-snmp-5.8-r1 package.

It seems to me that the sourceforge ticket was closed by you erroneously without confirming the bug, because you were not able to reproduce the issue with commit 90837dc.

However, I suspect that it is indeed a bug in v5.8 which has disappeared in the mean time on master, possibly during the refactoring of netsnmp_sockaddr_in3 in 8169aca. (Unfortunately, I was not able to verify my conjecture because I failed to configure and build a vanilla net-snmp from the master branch.)

Please reconsider the issue using release v5.8 (463235e) and let me know whether it is indeed a bug or a misconfiguration. Since v5.8 is the current release it would be helpful to have an official confirmation of the bug (with possible workarounds), to prevent others from spending the same time to figure out the problem.

Details

The problem occurred on my Gentoo system with the portage package net-analyzer/net-snmp-5.8-r1. Looking at the gentoo patch set, there seem to be no significant changes to the source code of v5.8 (463235e):

/usr/portage/net-analyzer/net-snmp/files # for patch in net-snmp-5.8-*.patch; do echo $patch; diffstat $patch; done
net-snmp-5.8-do-not-conflate-LDFLAGS-and-LIBS.patch
 net-snmp-config.in |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
net-snmp-5.8-my_bool.patch
 snmptrapd_sql.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net-snmp-5.8-pcap.patch
 config_os_libs2            |   18 ++++++++++--------
 config_project_with_enable |    5 +++++
 2 files changed, 15 insertions(+), 8 deletions(-)
net-snmp-5.8-tinfo.patch
 config_os_libs2 |    1 +
 1 file changed, 1 insertion(+)

The error case

The attached /etc/snmp/snmpd.conf contains an agentAddress and a trapsink declaration:

agentAddress  udp:127.0.0.1:161
# ...
trapsink     localhost public

According to the documentation, I would expect that the default trapsink port is 162. It turns out however, that port 161 is bound twice and the second call fails with EADDRINUSE:

strace

~ # strace /usr/sbin/snmpd -f  -f -Dnetsnmp_sockaddr_in -Dnetsnmp_udpbase |& grep 'bind.*INET'
bind(12, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
bind(11, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)

net-snmpd.log

# cat /var/log/net-snmpd.log 
netsnmp_sockaddr_in: addr 0x7fffac6cca70, inpeername "localhost", default_target ":162"
netsnmp_sockaddr_in: addr 0x7fffac6cca70, inpeername ":162", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 162
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:162 }
netsnmp_sockaddr_in: check user service localhost
netsnmp_sockaddr_in: servname not numeric, check if it really is a destination)
netsnmp_sockaddr_in: check destination localhost
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:162 }
netsnmp_sockaddr_in: addr 0x7fffac6cca80, inpeername "localhost", default_target "[NIL]"
netsnmp_sockaddr_in: check user service localhost
netsnmp_sockaddr_in: servname not numeric, check if it really is a destination)
netsnmp_sockaddr_in: check destination localhost
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
netsnmp_udpbase: open remote UDP: [127.0.0.1]:162->[0.0.0.0]:0
netsnmp_udpbase: binding socket: 12 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
netsnmp_udpbase: socket 12 bound to UDP: [127.0.0.1]:162->[127.0.0.1]:161
Turning on AgentX master support.
netsnmp_sockaddr_in: addr 0x7fffac6ceed0, inpeername "127.0.0.1:161", default_target ":161"
netsnmp_sockaddr_in: addr 0x7fffac6ceed0, inpeername ":161", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: check destination 127.0.0.1
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
netsnmp_udpbase: open local UDP: [127.0.0.1]:161->[0.0.0.0]:0
netsnmp_udpbase: set IP_PKTINFO
netsnmp_udpbase: binding socket: 11 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
netsnmp_udpbase: failed to bind for clientaddr: 98 Address already in use
Error opening specified endpoint "udp:127.0.0.1:161"
Server Exiting with code 1

Workaround

After adding the port number 162 explicitly to the trapsink declaration, the daemon starts up without error:

agentAddress  udp:127.0.0.1:161
# ...
trapsink     localhost:162 public

strace

~ # strace /usr/sbin/snmpd -f  -f -Dnetsnmp_sockaddr_in -Dnetsnmp_udpbase |& grep 'bind.*INET'
bind(11, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
read(15, "grep\0--colour=auto\0bind.*INET\0", 1024) = 30
^C

net-snmpd.log

~ # cat /var/log/net-snmpd.log 
netsnmp_sockaddr_in: addr 0x7ffe33b0d430, inpeername "localhost:162", default_target ":162"
netsnmp_sockaddr_in: addr 0x7ffe33b0d430, inpeername ":162", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 162
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:162 }
netsnmp_sockaddr_in: check user service 162
netsnmp_sockaddr_in: check destination localhost
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:162 }
netsnmp_udpbase: open remote UDP: [127.0.0.1]:162->[0.0.0.0]:0
Turning on AgentX master support.
netsnmp_sockaddr_in: addr 0x7ffe33b0f890, inpeername "127.0.0.1:161", default_target ":161"
netsnmp_sockaddr_in: addr 0x7ffe33b0f890, inpeername ":161", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: check destination 127.0.0.1
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
netsnmp_udpbase: open local UDP: [127.0.0.1]:161->[0.0.0.0]:0
netsnmp_udpbase: set IP_PKTINFO
netsnmp_udpbase: binding socket: 11 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
NET-SNMP version 5.8
Received TERM or STOP signal...  shutting down...

[freeBSD] "pass" Bad File Descriptor

FreeBSD 11.1.
NET-SNMP Version: 5.7.3.

We have some "pass" scripts on snmpd.conf which call a shell script to check some information from ipfw.

The shell script response time is almost "instantaneous".
Calling the specified OID using SNMPGET takes 1 second or more, and eventually timeout ...

Sometimes when the daemon keeps running for a long time, snmpd consumes all CPU and hang.

Using truss "truss -d -D -f -o truss_debug.tmp -p <SNMPD_PID>" I can see a lot of "ERR # 9 'Bad file descriptor' " messages.

I have found this bug https://sourceforge.net/p/net-snmp/bugs/2596/, which is expected to be patched on my net-snmp version.


Partial Truss output log:
"
(...)
31737: 8.760443942 0.000050775 getsockname(8,{ AF_INET 0.0.0.0:161 },0x7fffffffe6b8) = 0 (0x0)
31737: 8.760959163 0.000068585 pipe2(0x7ffffffde9d8,0) = 0 (0x0)
31737: 8.761118820 0.000059085 pipe2(0x7ffffffde9d0,0) = 0 (0x0)
31737: 8.761325342 0.000057131 sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
49714: 8.762116087 0.000000000
31737: 8.762141649 0.000709589 fork() = 49714 (0xc232)
49714: 8.762295510 0.000036108 thr_self(0x804616000) = 0 (0x0)
31737: 8.762325752 0.000043582 sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
31737: 8.762519911 0.000098616 close(9) = 0 (0x0)
49714: 8.762549943 0.000038203 sysarch(AMD64_SET_FSBASE,0x7ffffffc1358) = 0 (0x0)
49714: 8.762716166 0.000080877 sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
31737: 8.762768128 0.000109651 close(12) = 0 (0x0)
49714: 8.762878128 0.000029054 close(0) = 0 (0x0)
31737: 8.762903411 0.000037854 close(10) = 0 (0x0)
49714: 8.763153793 0.000065512 dup(0x9) = 0 (0x0)
49714: 8.763300460 0.000054546 close(10) = 0 (0x0)
49714: 8.763464238 0.000053917 close(1) = 0 (0x0)
49714: 8.763605318 0.000049867 dup(0xc) = 1 (0x1)
49714: 8.763740112 0.000048819 close(11) = 0 (0x0)
49714: 8.763864011 0.000046515 close(2) = 0 (0x0)
49714: 8.763985326 0.000046445 dup(0x1) = 2 (0x2)
49714: 8.764134158 0.000047911 getdtablesize() = 1886130 (0x1cc7b2)
49714: 8.764255961 0.000047073 close(1886129) ERR#9 'Bad file descriptor'
49714: 8.764371200 0.000041276 close(1886128) ERR#9 'Bad file descriptor'
49714: 8.764493283 0.000047422 close(1886127) ERR#9 'Bad file descriptor'
49714: 8.764609709 0.000041276 close(1886126) ERR#9 'Bad file descriptor'
49714: 8.764718243 0.000040369 close(1886125) ERR#9 'Bad file descriptor'
49714: 8.764827125 0.000041276 close(1886124) ERR#9 'Bad file descriptor'
49714: 8.764935869 0.000041346 close(1886123) ERR#9 'Bad file descriptor'
49714: 8.765045729 0.000041276 close(1886122) ERR#9 'Bad file descriptor'
49714: 8.765160549 0.000039949 close(1886121) ERR#9 'Bad file descriptor'
49714: 8.765272435 0.000038343 close(1886120) ERR#9 'Bad file descriptor'
49714: 8.765375940 0.000038343 close(1886119) ERR#9 'Bad file descriptor'
49714: 8.765494321 0.000045397 close(1886118) ERR#9 'Bad file descriptor'
(...)
"

Linux traps with VRF iface are broken unless clientaddr is used

(I had incorrectly opened a "patch" for this bug a while ago (#1399).)

Patches 0831ed (main Linux VRF support) and 3ca90c2 (added use of sendto()
instead of sendmsg()) added basic linux vrf support.

But on latest V5-8-patches, any trapsink, trap2sink, or trapsess with a VRF interface

trapsess -e 0x80001f88806d7e38395026435d00000000 -v3 -l authPriv -u testuser -a SHA -A testsha1234 -x AES -X testaes1234 11.0.0.1%red 
trap2sink 11.0.0.1@red public  
trapsink 11.0.0.1@red public 

does not send a trap out the right interface.

At one point, v1 and v2c traps were working (not sure if I ever got v3 traps working) with
linux VRFs.

Memory leak in snmpusm.c

By performing usm get or set requests using code from the master (most recent commit: ba6f507).

==19739==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 17472 byte(s) in 168 object(s) allocated from:
    #0 0x7f4d061e0518 in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9518)
    #1 0x565487512822 in usm_process_in_msg /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:2431

Indirect leak of 13440 byte(s) in 168 object(s) allocated from:
    #0 0x7f4d061e0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x56548750fd57 in usm_set_usmStateReference_priv_protocol /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:371
    #2 0x56548750fd57 in usm_set_usmStateReference_priv_protocol /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:367

Indirect leak of 13440 byte(s) in 168 object(s) allocated from:
    #0 0x7f4d061e0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x56548750fc07 in usm_set_usmStateReference_auth_protocol /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:354
    #2 0x56548750fc07 in usm_set_usmStateReference_auth_protocol /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:350

Indirect leak of 2856 byte(s) in 168 object(s) allocated from:
    #0 0x7f4d061e0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x56548750fb59 in usm_set_usmStateReference_engine_id /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:345
    #2 0x56548750fb59 in usm_set_usmStateReference_engine_id /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:341

Indirect leak of 2688 byte(s) in 168 object(s) allocated from:
    #0 0x7f4d061e0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x56548750fca9 in usm_set_usmStateReference_auth_key /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:362
    #2 0x56548750fca9 in usm_set_usmStateReference_auth_key /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:359

Indirect leak of 1848 byte(s) in 168 object(s) allocated from:
    #0 0x7f4d061e0330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x56548750fab6 in usm_set_usmStateReference_name /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:337
    #2 0x56548750fab6 in usm_set_usmStateReference_name /home/Code/packages/net-snmp/core/snmplib/snmpusm.c:334

Memory leak in handle_agentx_packet when using a contextName

Our infrastructure code uses net-snmp and I found a memory leak in handle_agentx_packet if contextName is given.

Below is the trace from valgrind

==30360==    at 0x4C29EA3: malloc (vg_replace_malloc.c:309)
==30360==    by 0x653F294: snmp_clone_mem (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x653F3E7: ??? (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x653F90D: snmp_clone_pdu (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x60E3837: handle_agentx_packet (in /usr/lib64/libnetsnmpagent.so.31.0.2)
==30360==    by 0x6567ED0: ??? (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x6568F40: _sess_read (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x65698A8: snmp_sess_read2 (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x65698FA: snmp_read2 (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x656993B: snmp_read (in /usr/lib64/libnetsnmp.so.31.0.2)
==30360==    by 0x60DF30A: agent_check_and_process (in /usr/lib64/libnetsnmpagent.so.31.0.2)

On further debugging, we found that the internalPDU->contextName was assigned to the internalPDU->community resulting in losing the reference to the assigned memory of internalPDU->contextName. This memory is never free'ed when the internalPDU is deallocated.

Proposed fix:
contextNames memory should be freed before assignment to community, so that the memory is not lost.

In agent/mibgroup/agentx/subagent.c

internal_pdu = snmp_clone_pdu(pdu);

SNMP_FREE(internal_pdu->contextName);

internal_pdu->contextName = (char *) internal_pdu->community;
internal_pdu->contextNameLen = internal_pdu->community_len;

system.c: integer and string overflow

net-snmp-5.7.3/snmplib/system.c: long get_uptime(void)
....
long uptim = 0, a, b;
uptim = a * 100 + b; <<< possible integer overflow
....
struct timeval now;
long boottime_csecs, nowtime_csecs;
....
nowtime_csecs = (now.tv_sec * 100) + (now.tv_usec / 10000); <<< possible integer overflow

net-snmp-5.7.3/snmplib/system.c: int mkdirhier(const char *pathname, mode_t mode, int skiplast)
....
strcat(buf, entry); <<< possible string overflow
....
strcat(buf, entry); <<< possible string overflow

send response: Failure in sendto in NET-SNMP version 5.8

i am getting below mention error in snmpd.log and as a manager we are using sonic-wall
snmpd.log

NET-SNMP version 5.8
send response: Failure in sendto
-- iso.3.6.1.2.1.2.2.1.2.23
-- iso.3.6.1.2.1.2.2.1.7.23
-- iso.3.6.1.2.1.2.2.1.8.23
-- iso.3.6.1.2.1.2.2.1.9.23
-- iso.3.6.1.2.1.31.1.1.1.1.23

I am getting this error when we query standard oid data from sonic-wall.

snmpd.conf
agentAddress udp:161,udp6:161
sysName test
syslocation test
sysContact test
sysDescr
sysObjectID 1.3.6.1.4.1.2604.5
rocommunity 'public' 192.168.58.4
CreateUser 'admin' SHA256 "2345678dfghju vbnjkt" AES "1234567fdfghjrtyh"
rouser 'admin'
trapsess -v 3 -Ci -u "admin" -a SHA256 -A "2345678dfghju vbnjkt" -x AES -X "1234567fdfghjrtyh" -l authPriv 192.168.58.4

Build warnings (-Wunused-result) fixes

See patch below to fix some -Wunused-result warnings during build of net-snmp.

It may be wise to return an error in some cases instead of just ignoring the result.

diff --git a/agent/mibgroup/if-mib/data_access/interface_linux.c b/agent/mibgroup/if-mib/data_access/interface_linux.c
index c745132ef..a53d34c94 100644
--- a/agent/mibgroup/if-mib/data_access/interface_linux.c
+++ b/agent/mibgroup/if-mib/data_access/interface_linux.c
@@ -659,8 +659,8 @@ netsnmp_arch_interface_container_load(netsnmp_container* container,
      * to detect the position of individual fields directly,
      * but I suspect this is probably more trouble than it's worth.
      */
-    fgets(line, sizeof(line), devin);
-    fgets(line, sizeof(line), devin);
+    (void)! fgets(line, sizeof(line), devin);
+    (void)! fgets(line, sizeof(line), devin);
 
     if( 0 == scan_expected ) {
         if (strstr(line, "compressed")) {
diff --git a/agent/mibgroup/ip-forward-mib/data_access/route_linux.c b/agent/mibgroup/ip-forward-mib/data_access/route_linux.c
index 7e13084be..04ba7faed 100644
--- a/agent/mibgroup/ip-forward-mib/data_access/route_linux.c
+++ b/agent/mibgroup/ip-forward-mib/data_access/route_linux.c
@@ -69,7 +69,7 @@ _load_ipv4(netsnmp_container* container, u_long *index )
         return -2;
     }
 
-    fgets(line, sizeof(line), in); /* skip header */
+    (void)! fgets(line, sizeof(line), in); /* skip header */
 
     while (fgets(line, sizeof(line), in)) {
         char            rtent_name[32];
diff --git a/agent/mibgroup/ip-mib/data_access/systemstats_linux.c b/agent/mibgroup/ip-mib/data_access/systemstats_linux.c
index f68d12233..2cff5d51d 100644
--- a/agent/mibgroup/ip-mib/data_access/systemstats_linux.c
+++ b/agent/mibgroup/ip-mib/data_access/systemstats_linux.c
@@ -123,7 +123,7 @@ _systemstats_v4(netsnmp_container* container, u_int load_flags)
     /*
      * skip header, but make sure it's the length we expect...
      */
-    fgets(line, sizeof(line), devin);
+    (void)! fgets(line, sizeof(line), devin);
     len = strlen(line);
     if (224 != len) {
         fclose(devin);
diff --git a/agent/mibgroup/mibII/data_access/at_linux.c b/agent/mibgroup/mibII/data_access/at_linux.c
index 79eeef3ce..3293c08cc 100644
--- a/agent/mibgroup/mibII/data_access/at_linux.c
+++ b/agent/mibgroup/mibII/data_access/at_linux.c
@@ -74,7 +74,7 @@ ARP_Scan_Init(void)
     /*
      * Get rid of the header line
      */
-    fgets(line, sizeof(line), in);
+    (void)! fgets(line, sizeof(line), in);
 
     i = 0;
     while (fgets(line, sizeof(line), in)) {
diff --git a/agent/mibgroup/tcp-mib/data_access/tcpConn_linux.c b/agent/mibgroup/tcp-mib/data_access/tcpConn_linux.c
index 42121bbd8..79618085d 100644
--- a/agent/mibgroup/tcp-mib/data_access/tcpConn_linux.c
+++ b/agent/mibgroup/tcp-mib/data_access/tcpConn_linux.c
@@ -133,7 +133,7 @@ _load4(netsnmp_container *container, u_int load_flags)
     }
     
     setvbuf(in, rbuf, _IOFBF, rbufsize);
-    fgets(line, sizeof(line), in); /* skip header */
+    (void)! fgets(line, sizeof(line), in); /* skip header */
 
     /*
      *   sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
@@ -278,7 +278,7 @@ _load6(netsnmp_container *container, u_int load_flags)
     }
 
     setvbuf(in, rbuf, _IOFBF, rbufsize);
-    fgets(line, sizeof(line), in); /* skip header */
+    (void)! fgets(line, sizeof(line), in); /* skip header */
 
     /*
      * Note: PPC (big endian)
diff --git a/agent/mibgroup/util_funcs.c b/agent/mibgroup/util_funcs.c
index e0f122958..cbe70ecd0 100644
--- a/agent/mibgroup/util_funcs.c
+++ b/agent/mibgroup/util_funcs.c
@@ -507,7 +507,7 @@ get_exec_pipes(char *cmd, int *fdIn, int *fdOut, netsnmp_pid_t *pid)
          * close all non-standard open file descriptors 
          */
         netsnmp_close_fds(1);
-        (void) dup(1);          /* stderr */
+        (void)! dup(1);          /* stderr */
 
         for (cnt = 1, cptr1 = cmd, cptr2 = argvs; *cptr1 != 0;
              cptr2++, cptr1++) {
diff --git a/agent/snmpd.c b/agent/snmpd.c
index 138d81136..c1ef5656b 100644
--- a/agent/snmpd.c
+++ b/agent/snmpd.c
@@ -987,7 +987,7 @@ main(int argc, char *argv[])
     
 #ifdef HAVE_CHOWN
     if ( uid != 0 || gid != 0 )
-        chown( persistent_dir, uid, gid );
+        (void)! chown( persistent_dir, uid, gid );
 #endif
 
 #ifdef HAVE_SETGID
diff --git a/snmplib/system.c b/snmplib/system.c
index c14208536..62dcfa508 100644
--- a/snmplib/system.c
+++ b/snmplib/system.c
@@ -228,7 +228,7 @@ _daemon_prep(int stderr_log)
     int fd;
 
     /* Avoid keeping any directory in use. */
-    chdir("/");
+    (void)! chdir("/");
 
     if (stderr_log)
         return;

CPU High Load when Many PPP Interfaces are UP

Well, I've been using linux servers for a long time as a pppoe concentrator, and for some time I want to be able to monitor server resources, however, when I try to use the net-snmp daemon (on Debian I install it via snmpd package), the CPU consumption instantly climbs to the top in one of the CPU colors and is impossible to use. Does anyone know if anything can be done to fix it? Maybe some way to disable the collection of certain interfaces? I read somewhere that this has to do with "interface caching", if that's the same, what, can you disable?

Flooding messages file when keepalived VIP enabled

Centos 7.6
Keepalived : 2.0.7
Snmpd : 5.7.2 (net-snmp-5.7.2-38.el7_6.2.x86_64)

With a virtual ip active (keepalived), snmpd flood the /var/log/mesages

Nov 27 11:13:57 managed snmpd[10012]: ioctl 35123 returned -1
Nov 27 11:13:57 managed snmpd[10012]: no ifindex found for interface
Nov 27 11:14:00 managed snmpd[10012]: ioctl 35123 returned -1
Nov 27 11:14:00 managed snmpd[10012]: no ifindex found for interface

ip link is ok

ip -o link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\ link/ether 52:1d:b1:a8:38:f9 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\ link/ether be:07:2f:d6:3e:cd brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000\ link/ether f2:44:d2:89:05:0e brd ff:ff:ff:ff:ff:ff

but the ifconfig has a problem

ifconfig vip_0_0_0
vip_0_0_0: error fetching interface information: Device not found

The vip with snmpd problem is the 172.21.108.38 in my sample.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:1d:b1:a8:38:f9 brd ff:ff:ff:ff:ff:ff
inet 172.21.108.37/23 scope global eth0
valid_lft forever preferred_lft forever
inet 172.21.108.38/23 scope global secondary vip_0_0_0
valid_lft forever preferred_lft forever
inet6 fe80::501d:b1ff:fea8:38f9/64 scope link
valid_lft forever preferred_lft forever

i join strace file.
strace /usr/sbin/snmpd -f -LSwd -u dasnmp -I -smux -c /etc/snmpd/snmpd.conf -p /var/run/snmpd.pid 127.0.0.1 172.21.108.37:161 &>/root/snmp.trace

snmp.zip
keepalived.zip

Memory leak when using localized keys

Hi,

When performing a localized key change our sanitizer noticed the following memory leak:


=================================================================
==16942==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x7f26cddb3330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x5603766d2860 in usmDHGetUserKeyChange snmp-usm-dh-objects-mib/usmDHUserKeyTable/usmDHUserKeyTable_data_get.c:78
    #2 0x560376746dc3  (/usr/local/bin/snmp+0x26ddc3)

Direct leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x7f26cddb3330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x5603766d3536 in usmDHSetKey snmp-usm-dh-objects-mib/usmDHUserKeyTable/usmDHUserKeyTable_data_set.c:77

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7f26cddb3330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x7f26cdacc328 in CRYPTO_zalloc (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x192328)

Indirect leak of 128 byte(s) in 1 object(s) allocated from:
    #0 0x7f26cddb3330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    #1 0x7f26cdacc328 in CRYPTO_zalloc (/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x192328)

SUMMARY: AddressSanitizer: 408 byte(s) leaked in 4 allocation(s).

This is tested with commit: e8f2c077b81435099af1269eb40d5eb188ed0f28

error on subcontainer 'ia_addr' insert (-1)

Dear All,

Since the interfaces(eth1,eth2) have the same hardware address, the below error message is kept on displaying from the snmpd daemon.

Error Message: error on subcontainer 'ia_addr' insert (-1)

Kindly let me know how to resolve this issue.

Note: The Hardware(Physical) address can't able to be changed and remains the same since it has been driven by the driver.

Replacing Windows SNMP service

Hi,

one question. Having a MIB DLL registering with the Windows SNMP service (using "SnmpExtension... functions") I tried to replace the windows snmp service with the net-snmp one.
For that I compiled net-snmp per build.bat with

USING_WINEXTDLL_MODULE

enabled and added the code below to my own windows service.
But if I do a MIB walk with an MIB browser I see the "get-next-request" with wireshark,
but no reponse.

My code looks like the following.
Any ideas what could go wrong here?

Snmp::Snmp() :
	m_pRawSession(nullptr),
	m_pSession(new netsnmp_session())
{
	const char* pCommunity = "public";
	const char* pName = "SnmpAgent";
	char* pPeerName = "127.0.0.1";
	init_agent(pName);
	init_snmp(pName);
	snmp_sess_init(m_pSession);
	m_pSession->peername = _strdup(pPeerName);
	m_pSession->remote_port = 161;
	m_pSession->version = SNMP_VERSION_2c;
	m_pSession->community = (u_char*)pCommunity;
	m_pSession->community_len = strlen((char*)m_pSession->community);
	init_master_agent();
}

bool Snmp::Start()
{
	if (m_pRawSession == nullptr)
	{
		SOCK_STARTUP;
		m_pRawSession = snmp_open(m_pSession);
		if (m_pRawSession == nullptr)
		{
			snmp_sess_perror("Snmp::Start", m_pRawSession);
			SOCK_CLEANUP;
			return false;
		}
	}
	return true;
}

seg fault in handle_subagent_set_response

We have built a subagent (using NetSNMP 5.8.dev) and we occasionally see our subagent crash with a seg fault in handle_subagent_set_response. By looking at the disassembly of the core file in gdb, I can tell that the error is in subagent.c at (or very near) line 680:

https://github.com/net-snmp/net-snmp/blob/master/agent/mibgroup/agentx/subagent.c#L680

There are a couple reports online of what is probably the same error:

Has there been any progress on resolving this issue? The current master code looks fairly similar to our existing code. Apparently none of the available patches have been "blessed" and committed to the main repository. We would very much like to resolve this issue, but we would prefer not to apply "random" patches we find online....

multiple requests with a single command

Hello:

I was looking around for a support contact page, but could not find one.

I was hoping someone could help determine why when I use snmpget, in a command window, that it sends two requests instead of just the one.

I captured the traffic and that the second request goes out at 0.141 milliseconds, the target then responds 1.462 milliseconds.

I'm sure there is a setting somewhere to increase the wait time, just can not find it.

Using version 5.4.2.1

Thank you

Pauli

agentaddress udp:161 with linux VRF support (iface binding) is broken

At some point after linux VRF support for all interfaces (udp:161) was working.
Now, with agentaddress udp:161@red, we parse this incorrectly and listen on

udp 0 0 0.0.0.161:161 0.0.0.0:*

Regular IP addresses bound to a VRF interface work correctly
agentaddress 12.0.0.10@red

udp 0 0 12.0.0.10:161 0.0.0.0:*

Thanks,
Sam

net-snmp snmpd demon is getting crashed "Core was generated by `snmpd -f -c /cfs/system/snmpd.conf'"

Core was generated by `snmpd -f -c /cfs/system/snmpd.conf'

I am using net-snmp 5.8 as version and crashed observed after 30 min fo snmp query
bt result:-

Program terminated with signal SIGABRT, Aborted.
#0  0xf7abfb47 in raise () from /lib/libc.so.6
(gdb) bt
#0  0xf7abfb47 in raise () from /lib/libc.so.6
#1  0xf7ac0cd9 in abort () from /lib/libc.so.6
#2  0xf7affa6b in ?? () from /lib/libc.so.6
#3  0xf7b0649d in ?? () from /lib/libc.so.6
#4  0xf7b07e09 in ?? () from /lib/libc.so.6
#5  0xf7d1033d in usm_free_usmStateReference () from /lib/libnetsnmp.so.35
#6  0xf7d1208e in usm_generate_out_msg () from /lib/libnetsnmp.so.35
#7  0xf7d1216d in usm_secmod_generate_out_msg () from /lib/libnetsnmp.so.35
#8  0xf7cf07f1 in snmpv3_packet_build () from /lib/libnetsnmp.so.35
#9  0xf7cf0bab in snmp_build () from /lib/libnetsnmp.so.35
#10 0xf7cf0fa3 in netsnmp_build_packet () from /lib/libnetsnmp.so.35
#11 0xf7cf11d9 in _build_initial_pdu_packet () from /lib/libnetsnmp.so.35
#12 0xf7ed32f1 in netsnmp_wrap_up_request () from /lib/libnetsnmpagent.so.35
#13 0xf7ed4791 in netsnmp_handle_request () from /lib/libnetsnmpagent.so.35
#14 0xf7ed48d3 in handle_snmp_packet () from /lib/libnetsnmpagent.so.35
#15 0xf7cf51f2 in ?? () from /lib/libnetsnmp.so.35
#16 0xf7cf58fc in _sess_read () from /lib/libnetsnmp.so.35
#17 0xf7cf593b in snmp_sess_read2 () from /lib/libnetsnmp.so.35
#18 0xf7cf5982 in snmp_read2 () from /lib/libnetsnmp.so.35
#19 0x0804ac1b in ?? ()
#20 0x0804a6ed in ?? ()
#21 0xf7aabe41 in __libc_start_main () from /lib/libc.so.6
#22 0x0804a7d5 in ?? ()

delayed instance not working

Hi~

When i follow this link, it's not working, why? Here is my code:

subagent regist

// the ptr_oid_info is kept in a global object
void SubagentCaller::RegistOidObject(std::shared_ptr<OidInfo> &ptr_oid_info)
{
    OidInfo *info = ptr_oid_info.get();
    if (info == NULL)
    {
        return;
    }

    netsnmp_handler_registration *reg_info;
    reg_info = netsnmp_create_handler_registration(info->Name.c_str(), ObjectHandler, (oid *)info->OidNoArray.get(), info->OidNoLen, HANDLER_CAN_RWRITE);
    netsnmp_register_instance(reg_info);
}

handler

int ObjectHandler(netsnmp_mib_handler *handler,
                  /** pointer to registration struct */
                  netsnmp_handler_registration *reginfo,
                  /** pointer to current transaction */
                  netsnmp_agent_request_info *reqinfo,
                  netsnmp_request_info *requests)
{
    requests->delegated = 1;

    netsnmp_delegated_cache *cache_info = netsnmp_create_delegated_cache(handler, reginfo, reqinfo, requests, NULL);

    LOG(plog::debug) << "enter request...";
    auto id = snmp_alarm_register(2, 0, ForwardRequestCacheInfo::ReturnDelayedResponse, cache_info);
    LOG(plog::debug) << "give regist!";

    return SNMP_ERR_NOERROR;
}

delayed handler

void ForwardRequestCacheInfo::ReturnDelayedResponse(unsigned int client_reg, void *client_arg)
{
    LOG(plog::debug) << "enter ReturnDelayedResponse....";
}

result print:

2020-01-02 11:42:02.771 DEBUG [8996] [ObjectHandler@139] enter request...
2020-01-02 11:42:02.771 DEBUG [8996] [ObjectHandler@141] give regist!

when not use delay, it's ok. but if use it , not print enter ReturnDelayedResponse....

client log:

----------------------- New Test -----------------------
Paessler SNMP Tester 5.2.3 Computername: PC-20170826BROY Interface: (80.0.0.170)
2020/1/2 星期四 11:42:02 (3 ms) : Device: localhost
2020/1/2 星期四 11:42:02 (7 ms) : SNMP V1
2020/1/2 星期四 11:42:02 (8 ms) : Custom OID NET-SNMP-TUTORIAL-MIB::nstAgentSubagentObject.0
2020/1/2 星期四 11:42:08 (6011 ms) : SNMP Datatype: ASN_PRIMITIVE
2020/1/2 星期四 11:42:08 (6011 ms) : -------
2020/1/2 星期四 11:42:08 (6012 ms) : Value: No response (check: firewalls, routing, snmp settings of device, IPs, SNMP version, community, passwords etc) (SNMP error # -2003)
2020/1/2 星期四 11:42:08 (6013 ms) : Done

Allow multiple local server certificates based on DTLS UDP socket

Currently, net-snmp supports only one local cert for all the DTLS UDP connections irrespective of the listening socket. If an agent is listening on two sockets (port number 10161/10162) to accept DTLS connection it is possible to use only one local identity for both the connections.

Problem Description
snmpd.conf has two local cert definition which uses different signing algorithm. 1. to allow SHA-1 signed certificate 2. to allow SHA-256 signed certificate. When running snmpd agent, net-snmp always replaces the NETSNMP_DS_LIB_TLS_LOCAL_CERT with the current config. Hence, when the client tries to connect using two different server certificates on the same agent, one of the SNMP queries will get timed out due to DTLS server identity verification fails.

SNMPD.conf file used in agent side

agentAddress dtlsudp:10161, dtlsudp6:10161, dtlsudp:10162,dtlsudp6:10162
.....
[snmp] localCert SHA-1 Fingerprint for server cert
certSecName 10 SHA-1 Fingerprint for Client cert --cn
[snmp] localCert SHA-256 Fingerprint for Server Cert
certSecName 11 SHA-256 Fingerprint for client cert --cn

SNMPD agent always takes the default local identity as localCert which is configured last from configuration file

USM_NOTINTIMEWINDOW errors frequently seen

On our system (using a code drop from early Oct 2019), under certain conditions (namely, frequent SNMP requests happening, but not seemingly like an overwhelming number), we frequently see the error that is generated by this line of code:

https://github.com/net-snmp/net-snmp/blob/master/snmplib/snmpusm.c#L2618

of the format

boot_uint 0 myBoots 2 time_diff incrementing_value_with_system_uptime => not in time window

When these errors begin to occur, SNMP requests seem to get "flaky". In some cases the SNMP agent stops responding altogether until the requests stop.

Is there something specific that we can look at to track down what might cause this error to occur?

More information in logmatch trap

I am using net-snmp 5.7.3 on Ubuntu and have a few questions regarding logmatch trap

  • How can we get more information in a logmatch trap other than the pattern matched?

For example if we have below

logmatch loginFailure /var/log/auth.log 30 Failed password for .*
monitor -r 10 -o logMatchName -o logMatchFileName -o logMatchCurrentCount -o logMatchRegEx "Log Match" != logMatchCurrentCount

we get the below trap

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3022) 0:00:30.22 SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: Log Match DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING: DISMAN-EVENT-MIB::mteHotContextName.0 = STRING: DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchCurrentCount.1 DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 9 UCD-SNMP-MIB::logMatchName.1 = STRING: loginFailure UCD-SNMP-MIB::logMatchFilename.1 = STRING: /var/log/auth.log UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 9 UCD-SNMP-MIB::logMatchRegEx.1 = STRING: Failed password .*

for the below message in auth.log

Sep 5 19:51:43 sshd[23557]: Failed password for root from xx.xx.xx.xx port 41569 ssh2

I need the username as part of the logmatch trap. Can you please suggest changes required to get this done?

Segfault on usm_free_usmStateReference when compiled with -O2

Issue was reproduced on a 64 bit Big Endian PowerPC machine.
We found it very challenging to reproduce this issue, except on a machine in production that reproduced it reliably.

The segfaults went away when we compiled with -Og, but returned when we went back to compiling with -O2. We added a debug print in usm_free_usmStateReference on line 300 of snmplib/snmpusm.c (before the if (old_ref) check)

snmp_log(LOG_WARNING, "[+] SNMP USM FREE: %i", (uint64_t) old_ref);

Adding the above line cause the issue to stop reproducing. This leads me to believe that the compiler optimizations were somehow bypassing the if(old_ref) check for null references at level -O2.

Below is a stack trace I gathered from GDB

GNU gdb (GDB) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc64-nptl-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/snmpd...done.
[New LWP 17608]

warning: .dynamic section for "/lib64/libnetsnmpmibs.so.35" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/lib64/libnetsnmp.so.35" is not at the expected address (wrong library or version mismatch?)

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/snmpd -f -p /var/run/net-snmp/snmpd.pid -c /etc/snmpd.conf -Le -Dwatc'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00003fff79e4a030 in .raise () from /lib64/libc.so.6
(gdb) bt full
#0  0x00003fff79e4a030 in .raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00003fff79e4bc9c in .abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00003fff79e8f8a0 in ?? () from /lib64/libc.so.6
No symbol table info available.
#3  0x00003fff79e97d84 in ?? () from /lib64/libc.so.6
No symbol table info available.
#4  0x00003fff79e98ddc in ?? () from /lib64/libc.so.6
No symbol table info available.
#5  0x00003fff7a4a3068 in usm_free_usmStateReference (old=0x0) at snmpusm.c:302
        old_ref = 0x0
#6  0x00003fff7a4a5dc8 in usm_generate_out_msg (msgProcModel=<optimized out>, globalData=0x1014d060, globalDataLen=7, maxMsgSize=<optimized out>, secModel=<optimized out>, 
    secEngineID=<optimized out>, secEngineIDLen=<optimized out>, secName=<optimized out>, secNameLen=10, secLevel=3, scopedPdu=0x3ffff9e92a30 "0\202\005\271\004\022\200", scopedPduLen=1469, 
    secStateRef=0x10128510, secParams=0x1014d07a, secParamsLen=0x3ffff9e93098, wholeMsg=0x3ffff9e93088, 
    wholeMsgLen=0x3ffff9e932e0) at snmpusm.c:1168
        encrypted_length = 2604281822446170256
        salt_length = 70368642017376
        salt = ...
        priv_type = <optimized out>
        otstlen = 36
        seq_len = 32
        msgAuthParmLen = 0
        msgPrivParmLen = 0
        msgSecParmLen = 38
        authParamsOffset = 62
        privParamsOffset = 64
        datalen = 1469
        dataOffset = 64
        theTotalLength = 1533
        ptr = 0x1014d060 
        ptr_len = <optimized out>
        remaining = 70368642017376
        offSet = <optimized out>
        boots_uint = 1
        time_uint = 3
        boots_long = 1
        time_long = 3
        theName = 0x3fff7a856000 
        theNameLength = 80
        theEngineID = 0x3ffff9e922e0 
        theEngineIDLength = 7
        theAuthKey = 0x10128510 
        theAuthKeyLength = 0
        theAuthProtocol = 0x0
        theAuthProtocolLength = 0
        thePrivKey = 0x0
        thePrivKeyLength = 0
        thePrivProtocol = 0x0
        thePrivProtocolLength = 0
        theSecLevel = 80
#7  0x00003fff7a4a60a0 in usm_secmod_generate_out_msg (parms=<optimized out>) at snmpusm.c:872
No locals.
#8  0x00003fff7a46e218 in snmpv3_packet_build (session=0x10128920, pdu=0x1013d960, packet=0x1014d060, out_length=0x3ffff9e932e0, pdu_data=<optimized out>, pdu_data_len=<optimized out>)
    at snmp_api.c:2795
        parms = {msgProcModel = 0, globalData = 0x1014d060, globalDataLen = 26, maxMsgSize = 1472, secModel = 3, secEngineID = 0x1013daa0, secEngineIDLen = 18, 
          secName = 0x1013dae0, secNameLen = 10, secLevel = 3, scopedPdu = 0x3ffff9e92a30, scopedPduLen = 1469, secStateRef = 0x10128510, 
          secParams = 0x1014d07a, secParamsLen = 0x3ffff9e93098, wholeMsg = 0x3ffff9e93088, wholeMsgLen = 0x3ffff9e932e0, 
          wholeMsgOffset = 0x3fff7a844870, pdu = 0x1013d960, session = 0x10128920}
        global_data = 0x1014d060 
        spdu_hdr_e = 0x3ffff9e92a34 
        global_data_len = 26
        sec_params_len = 1438
        spdu_buf = ...
        spdu_buf_len = 1468
        spdu_len = <optimized out>
        cp = <optimized out>
        sptr = <optimized out>
#9  0x00003fff7a46e96c in snmpv3_build (pdu=0x1013d960, session=0x10128920, offset=0x3ffff9e93240, pkt_len=0x3ffff9e932e0, pkt=0x3ffff9e932f8) at snmp_api.c:2272
        ret = <optimized out>
#10 _snmp_build (pdu=0x1013d960, session=0x10128920, offset=0x3ffff9e93240, pkt_len=0x3ffff9e932e0, pkt=0x3ffff9e932f8) at snmp_api.c:2853
        h0e = 0x0
        start_offset = 0
        length = 70366500400992
        version = 0
        rc = 0
        cp = <optimized out>
#11 snmp_build (pkt=0x3ffff9e932f8, pkt_len=0x3ffff9e932e0, offset=0x3ffff9e93240, pss=0x10128920, pdu=0x1013d960) at snmp_api.c:3192
No locals.
#12 0x00003fff7a46ecd4 in netsnmp_build_packet (isp=<optimized out>, sp=<optimized out>, pdu=<optimized out>, pktbuf_p=0x3ffff9e932f8, pktbuf_len_p=0x3ffff9e932e8, pkt_p=<optimized out>, 
    len_p=0x3ffff9e932e0) at snmp_api.c:4962
        offset = 0
        result = <optimized out>
#13 0x00003fff7a46ef28 in _build_initial_pdu_packet (slp=<optimized out>, pdu=0x1013d960, bulk=<optimized out>) at snmp_api.c:5122
        session = 0x10128920
        isp = 0x10128890
        transport = <optimized out>
        pktbuf = <optimized out>
        packet = 0x1014d060 
        pktbuf_len = 1472
        length = 1472
        orig_length = <optimized out>
        result = <optimized out>
        orig_count = <optimized out>
        curr_count = <optimized out>
#14 0x00003fff7a7f9d8c in netsnmp_wrap_up_request (asp=0x1013d8e0, status=0) at snmp_agent.c:1987
        var_ptr = <optimized out>
        i = 1
#15 0x00003fff7a7fc5ac in netsnmp_handle_request (asp=0x1013d8e0, status=<optimized out>) at snmp_agent.c:3644
No locals.
#16 0x00003fff7a7fc86c in handle_snmp_packet (op=<optimized out>, session=<optimized out>, reqid=<optimized out>, pdu=<optimized out>, magic=<optimized out>) at snmp_agent.c:2298
No locals.
Backtrace stopped: frame did not save the PC

Core was generated by `snmpd -f -c /cfs/system/snmpd.conf' Program terminated with signal SIGSEGV, Segmentation fault

Core was generated by `snmpd -f -c /cfs/system/snmpd.conf'

I am using net-snmp 5.8 as version and crashed observed after 2 hours of snmp query. Please find test script attached.
testscript.txt

bt result:-

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Core was generated by `snmpd -f -c /cfs/system/snmpd.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xf7e6da55 in inetCidrRouteTable_container_load () from /lib/libnetsnmpmibs.so.35
(gdb) bt
#0  0xf7e6da55 in inetCidrRouteTable_container_load () from /lib/libnetsnmpmibs.so.35
#1  0xf7e6cbc2 in ?? () from /lib/libnetsnmpmibs.so.35
#2  0xf7f3094f in ?? () from /lib/libnetsnmpagent.so.35
#3  0xf7f312a2 in netsnmp_cache_helper_handler () from /lib/libnetsnmpagent.so.35
#4  0xf7f3b7e2 in netsnmp_call_handler () from /lib/libnetsnmpagent.so.35
#5  0xf7f31710 in netsnmp_instance_helper_handler () from /lib/libnetsnmpagent.so.35
#6  0xf7f3b7e2 in netsnmp_call_handler () from /lib/libnetsnmpagent.so.35
#7  0xf7f337f6 in netsnmp_serialize_helper_handler () from /lib/libnetsnmpagent.so.35
#8  0xf7f3b7e2 in netsnmp_call_handler () from /lib/libnetsnmpagent.so.35
#9  0xf7f3b8c7 in netsnmp_call_handlers () from /lib/libnetsnmpagent.so.35
#10 0xf7f43f81 in handle_var_requests () from /lib/libnetsnmpagent.so.35
#11 0xf7f4421f in handle_getnext_loop () from /lib/libnetsnmpagent.so.35
#12 0xf7f446b3 in handle_pdu () from /lib/libnetsnmpagent.so.35
#13 0xf7f447f5 in netsnmp_handle_request () from /lib/libnetsnmpagent.so.35
#14 0xf7f4495b in handle_snmp_packet () from /lib/libnetsnmpagent.so.35
#15 0xf7d65283 in ?? () from /lib/libnetsnmp.so.35
#16 0xf7d65994 in _sess_read () from /lib/libnetsnmp.so.35
#17 0xf7d659d3 in snmp_sess_read2 () from /lib/libnetsnmp.so.35
#18 0xf7d65a1a in snmp_read2 () from /lib/libnetsnmp.so.35
#19 0x0804ac1b in ?? ()
#20 0x0804a6ed in ?? ()
#21 0xf7b1be41 in __libc_start_main () from /lib/libc.so.6
#22 0x0804a7d5 in ?? ()

snmpv3 add and delete user causes fail of operation some times.

My Version : net-snmp-5.4.4

Description

SNMP user add/delete is completing within few seconds most of the time. In some cases this operation is taking a long time in NET SNMP stack.

In order to reproduce we followed these steps:

We have a curl scipts which will add the snmpv3 users add and remove continuously to stress our product.. however we noticed after some time the user addition or removal is not happening the soap response of it as failed.

While debugging we found one of the possible error 🥇 👍

read_config_store open failure on /var/net-snmp/snmpd.conf
&
/etc/snmp/snmpd.conf: Too many open files

These error looks like some file descriptor leak.
When i searched the above error logs in google, I found with below possible fix (Patch) but
nothing has resolved my problem.

https://bugzilla.redhat.com/show_bug.cgi?id=561875
https://stackoverflow.com/questions/880557/socket-accept-too-many-open-files

Kindly, suggest me something or any patch is available for snmpv3 user or removal.

Allow snmptrap to read USM user from persistent snmpd.conf?

It would be great if snmptrap could have an option to take USM credentials from a user configured in the persistent snmpd.conf file, similar to how trapsess does for snmpd. That way only the user, and not the passphrases or keys would need to be included on the command line.

I have a AgentX sub-agent that needs to send V3 traps/informs, and currently I'm parsing the persistent snmpd.conf file for the users and localized keys and then using them to send the traps to avoid storing and using passwords on the command line, which seems like something snmptrap could so with -u and another option to enable the behavior.

AES256 length constant missing (net-snmp 5.8)

Hello,

oid usmAES256PrivProtocol[9] is defined in transform_oids.h (using --enable-blumenthal-aes flag).
However, a constant for its OID length (9) is missing.

Just like there's #define USM_PRIV_PROTO_AES_LEN 10 for oid usmAESPrivProtocol[10], I'd expect to see something like #define USM_PRIV_PROTO_AES256_LEN 9 for oid usmAES256PrivProtocol[9] .

What am I missing?

Thanks.

Update error: /usr/sbin/snmptrapd: symbol lookup error: /usr/sbin/snmptrapd: undefined symbol: netsnmp_mysql_init

I'm getting fail during update that looks a lot like 195641:

appliance@zabbix:~$ sudo dpkg --configure snmpd
Setting up snmpd (5.7.2~dfsg-8.1ubuntu3.3) ...
update-rc.d: warning:  stop runlevel arguments (1) do not match snmpd Default-Stop values (0 1 6)
 * Starting network management services:                                                                  /usr/sbin/snmptrapd: symbol lookup error: /usr/sbin/snmptrapd: undefined symbol: netsnmp_mysql_init
invoke-rc.d: initscript snmpd, action "start" failed.
dpkg: error processing package snmpd (--configure):
 subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
 snmpd
$ uname -a
Linux zabbix 3.19.0-80-generic #88~14.04.1-Ubuntu SMP Fri Jan 13 14:54:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I've successfully updated net-snmp

appliance@zabbix:~$ snmpget --version
NET-SNMP version: 5.8

But sudo apt upgrade fails on

Setting up snmpd (5.7.2~dfsg-8.1ubuntu3.3) ...
update-rc.d: warning:  stop runlevel arguments (1) do not match snmpd Default-Stop values (0 1 6)
 * Starting network management services:                                                                  /usr/sbin/snmptrapd: symbol lookup error: /usr/sbin/snmptrapd: undefined symbol: netsnmp_mysql_init
invoke-rc.d: initscript snmpd, action "start" failed.
dpkg: error processing package snmpd (--configure):
 subprocess installed post-installation script returned error exit status 127
dpkg: dependency problems prevent configuration of snmptt:
 snmptt depends on snmpd; however:
  Package snmpd is not configured yet.

dpkg: error processing package snmptt (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 snmpd
 snmptt
E: Sub-process /usr/bin/dpkg returned an error code (1)

Any help much appreciated.

libnetsnmptrapd doesn't use standard LDFLAGS

I was trying to track down why the Debian CI was complaining about one net-snmp library not using
the hardening flags (e.g. Job 363292 )

This library is built under apps, not snmplib like the others. The snmlib linker lines in Makefile.in use $(LDFLAGS) while apps uses $(LIB_LD_LIBS). The problem is, LIB_LD_LIBS is not defined anywhere so and specified LDFLAGS are not used.

I cannot see why libnetsnmptrapd would need different linker flags to the other libraries, so the simplest fix is to change the relevant apps/Makefile.in to use LDFLAGS instead of (or maybe in addition to) LIB_LD_LIBS.

The other blhc error is around sedscript. I was just going to add CPPGLAGS to the toplevel Makefile to keep blhc happy. It's probably not going to do anything other than that.

[snmpd.conf] sending SIGHUP to snmpd not reload trpa2sink from configuration (snmpd.conf))

Hello,
I have a question regarding reloding snmpd.conf in net-snmp version 5.7.3.
I tried send SIGHUP to snmpd in order to reload snmpd.conf. Inside snmpd.conf I have for example line:
trap2sink tcp:ip1862 public.
In order to send trap
first step:
I run snmptrapd on machine where trap will be sent by snmpd.
second step
I run snmpd with snmpd.conf file.
And I had success - snmptrapd logs new trap succesfully

So now I restarted snmptrapd and it coused that no more traps are sending to snmptrapd.
In that case I tried reload configuration sending SIGHUP to snmpd. It reload configuration but not register trap2sink in snmptrapd (lines whith trap2sink in snmpd.conf was ignored ).
I checked that register_app_config_handler("trap2sink",
snmpd_parse_config_trap2sink,
snmpd_free_trapsinks,
"host [community] [port]");
is called only in init_agent_read_config.

So in my opinion restarting snmpd is the only way to reregister sending traps after restrating snmptrapd.

Do you know any other solution than restart of snmpd to sending trpas to snmptrapd after snmptrapd restart?

Does in version 5.8 seqence of strating snmptrapd and snmpd is also important?

Maciek
If I first run snmpd and second snmptrapd can I how some force sending traps to snmptrapd?

snmptrapd blocks while executing traphandle commands

From the man page for snmptrapd.conf:

The daemon blocks while executing the traphandle commands. (This should be fixed in the future with an appropriate signal catch and wait() combination).

I couldn't find an existing issue that tracks this, so I decided to create one.

Also a question:
I can see that if my snmptrapd.conf file has multiple traphandle directives, each calling different external programs, performance suffers because of the synchronous (blocking) execution.
But what if I have a single traphandle directive, calling a single external program?

win32.dsw - Build: 8 succeeded, 60 failed, 0 up-to-date, 0 skipped

Hi,

I tried to do a batch build of the shipped win32.dsw.

========== Build: 8 succeeded, 60 failed, 0 up-to-date, 0 skipped ==========

As you can see there is something terrible wrong.

------ Build started: Project: libsnmp, Configuration: Template Win32 ------
  asn1.c
..\..\snmplib\asn1.c(164): fatal error C1083: Cannot open include file: 'net-snmp/net-snmp-config.h': No such file or directory
  callback.c
..\..\snmplib\callback.c(19): fatal error C1083: Cannot open include file: 'net-snmp/net-snmp-config.h': No such file or directory
  check_varbind.c
..\..\snmplib\check_varbind.c(1): fatal error C1083: Cannot open include file: 'net-snmp/net-snmp-config.h': No such file or directory
  closedir.c

...

------ Build started: Project: libsnmp, Configuration: Release Win32 ------
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1357,5): warning MSB8012: TargetPath(D:\Company\Sources\_3rdParty\net-snmp\win32\libsnmp\.\../lib/release\libsnmp.lib) does not match the Library's OutputFile property value (D:\Company\Sources\_3rdParty\net-snmp\win32\lib\release\netsnmp.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1359,5): warning MSB8012: TargetName(libsnmp) does not match the Library's OutputFile property value (netsnmp). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
  libsnmp.vcxproj -> D:\Company\Sources\_3rdParty\net-snmp\win32\libsnmp\.\../lib/release\libsnmp.lib

...

------ Build started: Project: encode_keychange, Configuration: Release Win32 ------
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1189,5): warning MSB8012: TargetPath(D:\Company\Sources\_3rdParty\net-snmp\win32\encode_keychange\.\Release\encode_keychange.exe) does not match the Linker's OutputFile property value (D:\Company\Sources\_3rdParty\net-snmp\win32\bin\release\encode_keychange.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
netsnmp.lib(snmp_logging.obj) : error LNK2019: unresolved external symbol _vasprintf referenced in function _snmp_log
netsnmp.lib(parse.obj) : error LNK2019: unresolved external symbol _asprintf referenced in function _read_all_mibs
netsnmp.lib(snmpIPv4BaseDomain.obj) : error LNK2001: unresolved external symbol _asprintf
../bin/release/encode_keychange.exe : fatal error LNK1120: 2 unresolved externals

...

------ Build started: Project: snmpd, Configuration: Release Win32 ------
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(1189,5): warning MSB8012: TargetPath(D:\Company\Sources\_3rdParty\net-snmp\win32\snmpd\.\Release\snmpd.exe) does not match the Linker's OutputFile property value (D:\Company\Sources\_3rdParty\net-snmp\win32\bin\release\snmpd.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
netsnmp.lib(snmp_logging.obj) : error LNK2019: unresolved external symbol _vasprintf referenced in function _snmp_log
netsnmp.lib(snmpCallbackDomain.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmpmibs.lib(pass.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmpmibs.lib(pass_persist.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmpmibs.lib(extensible.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmpmibs.lib(util_funcs.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmp.lib(parse.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmp.lib(snmpIPv4BaseDomain.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmpmibs.lib(dlmod.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmpmibs.lib(proc.obj) : error LNK2001: unresolved external symbol _asprintf
netsnmpmibs.lib(at.obj) : error LNK2001: unresolved external symbol _var_atEntry
netsnmpmibs.lib(ip.obj) : error LNK2001: unresolved external symbol _var_atEntry
netsnmpmibs.lib(snmpNotifyTable.obj) : error LNK2019: unresolved external symbol _init_snmpNotifyTable_data referenced in function _init_snmpNotifyTable
netsnmpmibs.lib(snmpNotifyTable.obj) : error LNK2019: unresolved external symbol _shutdown_snmpNotifyTable_data referenced in function _shutdown_snmpNotifyTable
netsnmpmibs.lib(snmpNotifyTable.obj) : error LNK2019: unresolved external symbol _snmpNotifyTable_add referenced in function _parse_snmpNotifyTable
netsnmpmibs.lib(snmpNotifyTable.obj) : error LNK2019: unresolved external symbol _snmpNotifyTable_extract referenced in function _write_snmpNotifyRowStatus
netsnmpmibs.lib(snmpNotifyTable.obj) : error LNK2019: unresolved external symbol _snmpNotifyTable_dispose referenced in function _write_snmpNotifyRowStatus
netsnmpmibs.lib(snmpNotifyTable.obj) : error LNK2019: unresolved external symbol _find_row_notifyTable referenced in function _var_snmpNotifyTable
netsnmpmibs.lib(snmpNotifyFilterProfileTable.obj) : error LNK2019: unresolved external symbol _init_snmpNotifyFilterProfileTable_data referenced in function _init_snmpNotifyFilterProfileTable
netsnmpmibs.lib(snmpNotifyFilterProfileTable.obj) : error LNK2019: unresolved external symbol _shutdown_snmpNotifyFilterProfileTable_data referenced in function _shutdown_snmpNotifyFilterProfileTable
netsnmpmibs.lib(snmpNotifyFilterProfileTable.obj) : error LNK2019: unresolved external symbol _snmpNotifyFilterProfileTable_add referenced in function _write_snmpNotifyFilterProfileRowStatus
netsnmpmibs.lib(snmpNotifyFilterProfileTable.obj) : error LNK2019: unresolved external symbol _snmpNotifyFilterProfileTable_free referenced in function _write_snmpNotifyFilterProfileRowStatus
netsnmpmibs.lib(snmpNotifyFilterProfileTable.obj) : error LNK2019: unresolved external symbol _snmpNotifyFilterProfileTable_extract referenced in function _write_snmpNotifyFilterProfileRowStatus
netsnmpmibs.lib(snmpNotifyFilterProfileTable.obj) : error LNK2019: unresolved external symbol _snmpNotifyFilterProfileTable_oldapi_find referenced in function _var_snmpNotifyFilterProfileTable
netsnmpmibs.lib(snmpTargetAddrEntry.obj) : error LNK2019: unresolved external symbol _init_snmpTargetAddrEntry_data referenced in function _init_snmpTargetAddrEntry
netsnmpmibs.lib(snmpTargetAddrEntry.obj) : error LNK2019: unresolved external symbol _shutdown_snmpTargetAddrEntry_data referenced in function _shutdown_snmpTargetAddrEntry
netsnmpmibs.lib(snmpTargetAddrEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetAddrTable_create referenced in function _snmpTargetAddr_createNewRow
netsnmpmibs.lib(snmpTargetAddrEntry.obj) : error LNK2019: unresolved external symbol _search_snmpTargetAddrTable referenced in function _var_snmpTargetAddrEntry
netsnmpmibs.lib(snmpTargetAddrEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetAddrTable_add referenced in function _snmpTargetAddr_createNewRow
netsnmpmibs.lib(snmpTargetAddrEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetAddrTable_remove referenced in function _write_snmpTargetAddrRowStatus
netsnmpmibs.lib(snmpTargetAddrEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetAddrTable_dispose referenced in function _snmpTargetAddr_createNewRow
netsnmpmibs.lib(snmpTargetParamsEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetParamTable_add referenced in function _snmpTargetParams_createNewRow
netsnmpmibs.lib(snmpTargetParamsEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetParamTable_remove referenced in function _write_snmpTargetParamsRowStatus
netsnmpmibs.lib(snmpTargetParamsEntry.obj) : error LNK2019: unresolved external symbol _search_snmpTargetParamsTable referenced in function _var_snmpTargetParamsEntry
netsnmpmibs.lib(snmpTargetParamsEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetParamTable_create referenced in function _snmpTargetParams_createNewRow
netsnmpmibs.lib(snmpTargetParamsEntry.obj) : error LNK2019: unresolved external symbol _snmpTargetParamTable_dispose referenced in function _snmpd_parse_config_targetParams
netsnmpmibs.lib(snmpTargetParamsEntry.obj) : error LNK2019: unresolved external symbol _init_snmpTargetParamsEntry_data referenced in function _init_snmpTargetParamsEntry
netsnmpmibs.lib(snmpTargetParamsEntry.obj) : error LNK2019: unresolved external symbol _shutdown_snmpTargetParamsEntry_data referenced in function _shutdown_snmpTargetParamsEntry
../bin/release/snmpd.exe : fatal error LNK1120: 29 unresolved externals

Several DTLS and TLS regression tests fail

The output of "make test" against openSUSE Tumbleweed with libressl 3.0.2:

[ ... ]
Test Summary Report
-------------------
DTLS-UDP user certificate tests                                       (Wstat: 256 Tests: 45 Failed: 1)
  Failed test:  44
  Non-zero exit status: 1
DTLS-UDP server certificate tests                                     (Wstat: 256 Tests: 12 Failed: 1)
  Failed test:  10
  Non-zero exit status: 1
DTLS-UDP server SAN tests                                             (Wstat: 256 Tests: 12 Failed: 1)
  Failed test:  10
  Non-zero exit status: 1
DTLS-UDP trap tests                                                   (Wstat: 256 Tests: 9 Failed: 1)
  Failed test:  8
  Non-zero exit status: 1
DTLS-UDP CRL Handling                                                 (Wstat: 256 Tests: 8 Failed: 1)
  Failed test:  7
  Non-zero exit status: 1
TLS-TCP over IPV6                                                     (Wstat: 256 Tests: 4 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
Files=163, Tests=20627, 265 wallclock secs ( 1.29 usr  0.07 sys + 67.91 cusr  9.50 csys = 78.77 CPU)
Result: FAIL

We failed these 6 tests:
  DTLS-UDP user certificate tests ( /home/bart/software/net-snmp/testing/fulltests/tls/T101DtlsUser_simple )
  DTLS-UDP server certificate tests ( /home/bart/software/net-snmp/testing/fulltests/tls/T111DtlsServer_simple )
  DTLS-UDP server SAN tests ( /home/bart/software/net-snmp/testing/fulltests/tls/T113DtlsSan_simple )
  DTLS-UDP trap tests ( /home/bart/software/net-snmp/testing/fulltests/tls/T121DtlsTrap_simple )
  DTLS-UDP CRL Handling ( /home/bart/software/net-snmp/testing/fulltests/tls/T141DtlsCrl_simple )
  TLS-TCP over IPV6 ( /home/bart/software/net-snmp/testing/fulltests/tls/T200TlsIpv6_simple )
+ return 1

Memory leak in HOST-RESOURCES-MIB::hrSWRunTable

There is a memory leak happening for HOST-RESOURCES-MIB::hrSWRunTable. It causes a significant amount of memory leaking each day. It has been discussed before and suggested patches provided in the past. I believe the solution is still relevant.

https://sourceforge.net/p/net-snmp/bugs/2717/
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219072

Would this patch be something that could get accepted https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182307&action=diff

RPM Packages are not installable because of circular Dependencies

I built the RPM Packages with the provided .spec file.
But on installation attempt I get a Dependency Error for both Packages:

# rpm -vUh net-snmp-5.8-1.x86_64.rpm
error: Error de dependencias:
	perl(NetSNMP::agent) se necesita para net-snmp-2:5.8-1.x86_64
	perl(NetSNMP::ASN) se necesita para net-snmp-2:5.8-1.x86_64
	perl(NetSNMP::OID) se necesita para net-snmp-2:5.8-1.x86_64
	perl(SNMP) se necesita para net-snmp-2:5.8-1.x86_64

I thought I could solve that issue with the net-snmp-perlmods Package which provides:

# rpm -q --provides -p net-snmp-perlmods-5.8-1.x86_64.rpm|grep -i perl
net-snmp-perl  
perl(SNMP)  
perl(NetSNMP::OID)  
perl(NetSNMP::ASN)  
perl(NetSNMP::AnyData::Format::SNMP)  
perl(NetSNMP::AnyData::Storage::SNMP)  
perl(NetSNMP::agent)  
perl(NetSNMP::manager)  
perl(NetSNMP::TrapReceiver)  
perl(NetSNMP::default_store)  
perl(NetSNMP::agent::default_store)  
net-snmp-perlmods = 2:5.8-1
net-snmp-perlmods(x86-64) = 2:5.8-1

But also its Installation Attempt results in Error:

# rpm -vUh net-snmp-perlmods-5.8-1.x86_64.rpm
error: Error de dependencias:
	net-snmp = 2:5.8 se necesita para net-snmp-perlmods-2:5.8-1.x86_64

because of the Requirement:

# rpm -q --requires -p net-snmp-perlmods-5.8-1.x86_64.rpm
net-snmp = 2:5.8

compile fails with net-snmp-5.8 and openssl-1.1.1d

snmp_openssl.c: In function 'DH_get0_pqg':
snmp_openssl.c:31:15: error: dereferencing pointer to incomplete type 'DH' {aka 'const struct dh_st'}
31 | *p = dh->p;
| ^~
snmp_openssl.c: In function 'DH_set0_pqg':
snmp_openssl.c:57:11: error: dereferencing pointer to incomplete type 'DH' {aka 'struct dh_st'}
57 | if ((dh->p == NULL && p == NULL)
| ^~
make[1]: *** [Makefile:100: snmp_openssl.lo] Error 1

snmptrapd on Alpine Linux has different outputOption

When I test on Ubuntu, snmptrapd displays the varbind datatype.
Example:
IF-MIB::ifPhysAddress.1 = STRING: 0:a:14:0:0:0
i.e. The default outputOption is "S", which agrees with the docs (http://net-snmp.sourceforge.net/docs/man/snmpcmd.html)

But when I test on Alpine, with the same snmptrapd.conf file, there is no datatype information.
It seems to behave as though outputOption is "Q", no matter what I specify in the snmptrapd.conf file.

NET-SNMP version 5.8

Need Multiple cert support in net-snmp-5.7.3

Hi Team,

We would like to know NetSNMP-5.7.3 and older versions having support for multiple cert authentication

Consider the scenario: The existing certs are going to expire soon, we want to replace new certs. To do smooth transition we want keep both certificates, since transition is going to be phase by phase.

We found out that NetSNMP having issue to compare more than one fingerprint from snmpd.conf.
For example: Our snmpd.conf looks like

[snmp] localCert certA_CPE
certSecName 100 certA_Manager --cn
rwuser -s tsm "user1" auth .1

[snmp] localCert certB_CPE
certSecName 200 certB_Manager --cn
rwuser -s tsm "user2" auth .1

If we query from our Tool,
snmpwalk -T our_identity=certA_Manager -T their_identity=certA_CPE dtlsudp6:[IP]:10161 OID

Tool side Logs:
query is failing with the below reasons
The fingerprint from the remote side's certificate didn't match the expected
got certB_CPE FP , expected certA_CPE FP
DTLSUDP: failed to verify ssl certificate (of the server)
tsm: needed to free transport data
The fingerprint from the remote side's certificate didn't match the expected
got certB_CPE FP, expected certA_CPE FP
DTLSUDP: failed to verify ssl certificate (of the server)
tsm: needed to free transport data
The fingerprint from the remote side's certificate didn't match the expected
got certB_CPE FP, expected certA_CPE FP
DTLSUDP: failed to verify ssl certificate (of the server)
tsm: needed to free transport data
The fingerprint from the remote side's certificate didn't match the expected
got certB_CPE FP, expected certA_CPE FP
DTLSUDP: failed to verify ssl certificate (of the server)
tsm: needed to free transport data
The fingerprint from the remote side's certificate didn't match the expected
got certB_CPE FP, expected certA_CPE FP
DTLSUDP: failed to verify ssl certificate (of the server)
tsm: needed to free transport data
The fingerprint from the remote side's certificate didn't match the expected
got certB_CPE FP, expected certA_CPE FP
DTLSUDP: failed to verify ssl certificate (of the server)
failed rfc5343 contextEngineID probing
snmpwalk: Timeout (Success)

Device side logs:
dtlsudp: starting a new connection
cert:find:params: looking for identity(1) in DEFAULT(0x0), hint 0
cert:find:params: looking for identity(1) in MULTIPLE(0x200), hint 1093544
cert:find:params: looking for identity(1) in FINGERPRINT(0x2), hint 1093544
cert:find:params: hint = certB_CPE FP
cert:find:params: looking for identity(1) in FILE(0x1), hint 1093544
cert:find:params: hint = certB_CPE FP
cert:find:found: using cert certB_CPE FP / 60ff1ea7c4ee7a1af226f75c3c8acc6a02c1450b for identity(1) (uses=identity+remote_peer (3))
cert:find:found: using cert certB_CPE FP / 60ff1ea7c4ee7a1af226f75c3c8acc6a02c1450b for identity(1) (uses=identity+remote_peer (3))
dtlsudp:cookie: generating cookie...
dtlsudp: have 48 bytes to send
dtlsudp: received 206 raw bytes on way to dtls
dtlsudp:cookie: verify cookie: 1
dtlsudp: have 1681 bytes to send
dtlsudp: received 2218 raw bytes on way to dtls
cert:find:params: looking for remote_peer(2) in FINGERPRINT(0x2), hint 1825528
cert:find:params: hint = 178105272cfb1cf73626e520ffea193b94606fc0
cert:find:found: using cert certA_CPE FP / 178105272cfb1cf73626e520ffea193b94606fc0 for remote_peer(2) (uses=remote_peer (2))
cert:find:params: looking for remote_peer(2) in FINGERPRINT(0x2), hint 1629840
cert:find:params: hint = 178105272cfb1cf73626e520ffea193b94606fc0
cert:find:found: using cert certA_CPE FP/ 178105272cfb1cf73626e520ffea193b94606fc0 for remote_peer(2) (uses=remote_peer (2))
dtlsudp: have 1792 bytes to send

However there is success in query with 2nd certificate.
snmpwalk -T our_identity=certB_Manager -T their_identity=certB_CPE dtlsudp6:[IP]:10161 OID
Success:

Problem here is, always last entry of fingerprint in the snmpd.conf is being sent from the agent to server and comparison at the querying end fails due to fingerprint mismatch .

snmptrapd output to traphandler does not contain datatype info.

I am using a traphandle directive to send the output of snmptrapd to an external Python program.
The Python script creates a JSON object and publishes on MQTT, and another microservice eventually writes this to InfluxDB.
It works well up to a point.

The Python script needs to know what datatype is used for each varbind value.
For example, in the trap data that my script reads from stdin, some strings are enclosed in quotes, but some are not. So it is impossible to know if a particular value is a string, an integer, or a counter.

What is really strange is that the snmptrapd output to stdout or stderr DOES include the datatype information. E.g. IF-MIB::ifPhysAddress.1 = STRING: 0:a:14:0:0:0. But this same varbind appears to the traphandler like this: IF-MIB::ifPhysAddress.1 0:a:14:0:0:0.

I have experimented with every possible combination of command-line arguments (-L, -O, -t), snmptrapd.conf file directives ([snmp] logOption, outputOption, doNotLogTraps), and snmp.conf file directives (oidOutputFormat).
The fundamental problem seems to be that the output to stdout/stderr and the output to a traphandler seem to follow different rules.

Can anyone tell me how to get datatype information to a traphandler?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.