net-snmp / net-snmp Goto Github PK
View Code? Open in Web Editor NEWA SNMP application library, tools and daemon
License: Other
A SNMP application library, tools and daemon
License: Other
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.
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.
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;
}
snmplib/snmp_debug.c has a missing semicolon:
https://github.com/net-snmp/net-snmp/blob/master/snmplib/snmp_debug.c#L699
We trivially fixed this locally, but should be updated in the repository.
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.
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
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.
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
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.
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
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;
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?
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
No error messages at UCD-SNMP-MIB::prErrMessage and UCD-SNMP-MIB::dskErrorMsg
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
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.
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:
The tests were produced on gentoo linux amd64 with current HEAD
net-snmp-v5.8-780-g06c09a117 (06c09a1)
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.
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.
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.
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.
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....
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.
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.
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
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
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 .
Hi~
Greate work!
Is the 5.8 version support win64? if not is there a plan to do so?
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
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
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
I am using net-snmp 5.7.3 on Ubuntu and have a few questions regarding logmatch trap
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?
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'
(...)
"
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;
The build process creates two files which aren't in the .gitignore file.
Please add the following to the .gitignore file:
netsnmp.pc
netsnmp-agent.pc
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
@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.
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 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
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...
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?
snmpd.conf proc with name containing spaces ignores values for Max and Min
e.q.
proc "Plex Media Serv" 1 1
triggers an snmp trap with too many "Plex Media Serv" processes. Processes which don't contain a whitespace are not affected
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.
Recently, patch 64f4ead (libsnmp: Only include <inttypes.h> when necessary)
effectively remove inttypes.h for and added it back for most files except for
if-mib/data_access/interface_linux.c
This had the effect of turning what were 64 bit counters (SCNuMAX is no longer defined)
into 32 bit counters.
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
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
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
(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.
Net-SNMP Net-SNMPd could allow a remote attacker to execute arbitrary code on the system, related to the SNMP write access configuration ability of SNMP-EXTEND-MIB to configure MIB extensions. By sending a specially-crafted request, an attacker could exploit this vulnerability to execute arbitrary code on the system.
See;
https://exchange.xforce.ibmcloud.com/vulnerabilities/171098
https://packetstormsecurity.com/files/155192
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
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.
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?
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 ?? ()
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 ?? ()
Hello,
The memory mib is not calculating the exact free memory due to missing slab value. There was a patch proposed here: https://sourceforge.net/p/net-snmp/patches/1338/
Not sure why the patch wasn't merged with master.
Any idea?
Thanks,
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
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
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?
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?
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
Is there some other snmp suported project that do the service for net manager. I have used snmp for a pirod time and i find it great for me. but the project in github is so cold. i want to know what the reason is.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.