Re: libkvm usage on FreeBSD

On 4/12/24 7:29 AM, Mark Johnston wrote: Do you mean that on FreeBSD we should always perform an unprivileged kvm_openfile() call, no matter whether --without-kmem-usage is specified? Yes, that's what I'm proposing. If someone disagrees, please share your opinion now. Thanks, Bart.

Re: libkvm usage on FreeBSD

On 4/12/24 06:44, Mark Johnston wrote: I would like to introduce the patch below, which gets compiled when --without-kmem-usage is specified. In this case, snmpd will still use libkvm, but won't open /dev/(k)mem. In my testing so far, this works perfectly. Does anyone have any thoughts on

Re: Getting listening port number while processing request

On 4/3/24 02:35, Teus Benschop wrote: A snmpd was set to listen on 10 ports through multiple entries like “agentaddress tcp:” in the snmpd.conf file. It was verified through snmpget that the snmpd listens on all 10 ports. Function “netsnmp_callback_open” in file

Re: Unable to compile net-snmp due to netlink API change

On 4/2/24 13:40, Craig Small wrote: On Wed, 3 Apr 2024 at 02:19, Bart Van Assche wrote: Can you please check the configure script logs to see why libnl-3 was not detected? libnl-3 was detected: configure:27875: $PKG_CONFIG --exists --print-errors "libnl-3.0" configure:278

Re: Unable to compile net-snmp due to netlink API change

On 4/2/24 01:49, Craig Small via Net-snmp-coders wrote: Hello All,   I was attempting to compile the git head of net-snmp. One big change is that uses netlink sockets instead of reading /proc/net/* The issue is the API is different to the library I can see. mibgroup/mibII/tcpTable.c:631:12:

Re: Getting listening port number while processing request

On 3/27/24 00:15, Teus Benschop wrote: On Wed, 27 Mar 2024 at 00:58, Bart Van Assche wrote: Please explain why you want to obtain that information and also how you plan to use it. Which APIs to modify will depend on the answer to that question. Hello Bert, Thank you for asking

Re: Getting listening port number while processing request

On 3/25/24 11:26, Teus Benschop wrote: 2. What are the ideas to expose this agent_tcp_port_number via the API? (Possibly I could add a function in the public API, that gets this variable and exposes it as a call.) Ideas? Please explain why you want to obtain that information and also how you

Re: Updating the LM-SENSORS MIB (Issue #752)

On 3/26/24 02:10, Craig Small via Net-snmp-coders wrote: This email is about working out how the LM-SENSORS MIB should be updated. If it was just a matter of updating the SNMP agent, I'd just create a pull request but the MIB is (might be?) different. The issue is that Gauge32 can only

Re: Missing root disk in MIB - Bisected to commit e3fc76e0ae ("CHANGES: snmpd: Make UCD-SNMP::dskTable dynamic if includeAllDisks is set.")

On 12/17/23 09:51, Christophe Leroy wrote: While upgrading from NETsnmp 5.7.3 to 5.9.3 I encounter a problem which is that root(/) filesystem is missing from UCD-SNMP-MIB disk table: Is https://github.com/net-snmp/net-snmp/pull/764 perhaps intended as a fix for this issue? Thanks, Bart.

Re: wolfSSL support in net-snmp

On 7/28/22 20:48, Bart Van Assche wrote: On 7/27/22 09:27, Hayden Roche wrote: A while back, we (wolfSSL) added support for wolfSSL to net-snmp 5.9.1 for a customer. You can find the patch here: https://github.com/wolfSSL/osp/tree/master/net-snmp Is this something you'd be interested

Re: wolfSSL support in net-snmp

On 7/27/22 09:27, Hayden Roche wrote: A while back, we (wolfSSL) added support for wolfSSL to net-snmp 5.9.1 for a customer. You can find the patch here: https://github.com/wolfSSL/osp/tree/master/net-snmp Is this something you'd be interested in having upstream? Support for wolfSSL seems a

Re: Net-SNMP 5.9.2 published

On 7/5/22 11:01, Wes Hardaker wrote: However, the 5.9 branch and the main branch have a *lot* of conflicts to resolve. The process of always merging patches to main frequently to avoid this has fallen away, and the branches are now fairly divergent which is going to be a problem to solve first

Re: Net-SNMP 5.9.2 published

On 6/30/22 19:23, Wes Hardaker via Net-snmp-coders wrote: I'm thinking we should look toward a main-branch release next (5.10). Opinions welcome. +1 for releasing the next version from the master branch. That would make Net-SNMP easier to maintain since it would reduce the number of branches

Re: publishing 5.9.3 immediately

On 7/5/22 08:28, Wes Hardaker via Net-snmp-coders wrote: So this issues: https://github.com/net-snmp/net-snmp/issues/432 Likely warrants an immediate 5.9.3 with only the change to libcurrent in Makefile.top. I'll try to get 5.9.3.rc1 out the door today to address this. How about also

Re: net-snmp and openssl v3

(+Wes) On 3/21/22 23:08, Craig Small wrote: I received a bug report about issues linking net-snmp with openssl v3. Generally its because there are functions referenced that were deprecated in 3.0 or even sometimes 1.1.0 ! I started looking around and found that net-snmp already has some, if

Re: [REQUEST FOR VOTES] snmpd: Drop support for pass_persist on uClinux

On 2020-08-18 10:28, Magnus Fromreide wrote: > I think the child code in the vfork case should be exactly > > execv(argv[0], argv); > _exit(1); > > as that seems to be about what POSIX allows. > >(From POSIX.1) The vfork() function has the same effect as fork(2), >

Re: [REQUEST FOR VOTES] snmpd: Drop support for pass_persist on uClinux

On 2020-08-16 15:58, Wes Hardaker wrote: > Magnus Fromreide writes: > >> That is a more lenient option than just dropping it so I think 'happy with >> dropping it' covers this variant. On the other hand I usually am far from >> the most conservative one in discussions like this one. > > I

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

On 2020-08-15 07:14, Magnus Fromreide wrote: > This allows vfork to not block the parent until the child has called _exit > or exec*, it does not allow the child to block the parent until completion. > > Please note that in our case this is arch-specific code for uClinux where > the fork() system

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

On 2020-08-14 17:05, Magnus Fromreide wrote: > The vfork child only blocks the parent until it have performed an successful > exec so that part looks ok [ ... ] Hi Magnus, Are you sure of this? From the Linux vfork() man page (https://man7.org/linux/man-pages/man2/vfork.2.html): The

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

On 2020-08-08 16:16, Magnus Fromreide wrote: > That file is a mess. > > Have anyone heard from Alexander Prömel regarding those temporary hard coded > pathnames that should be fixed soon? I think 14 years cover any reasonable > definition of the word 'soon'. > > Why are both the file descriptor

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

On 2020-08-13 18:16, Magnus Fromreide wrote: > Now I have finally gotten around to look more thoroughly into this and found > that your patch is basically good. > > For the agent/snmpd.c part I would like to change my vote to +1. Thanks! > For the pass_persist part you are keeping the fclose of

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

On 2020-08-10 10:51, Wes Hardaker wrote: > Bart Van Assche writes: > >> That's a great question. This fix only affects pass-persist on Unix >> platforms and Cygwin but neither affects the MSVC build nor any of the >> MinGW builds since the affected code was already disabl

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

On 2020-08-10 08:37, Wes Hardaker wrote: > Bart Van Assche writes: > >> However, I don't think rewriting that file so close to the v5.9 release >> is appropriate. Hence this patch that makes the smallest possible >> change. > > To be clear, this affects *only*

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

On 2020-08-08 16:16, Magnus Fromreide wrote: > I am putting in a 0 vote here because I think a larger rewrite is needed. Hi Magnus, I agree that agent/mibgroup/ucd-snmp/pass_persist.c should be rewritten. However, I don't think rewriting that file so close to the v5.9 release is appropriate.

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

>From https://pubs.opengroup.org/onlinepubs/9699919799/functions/fclose.html: "The fclose() function shall perform the equivalent of a close() on the file descriptor that is associated with the stream pointed to by stream." See also https://github.com/net-snmp/net-snmp/issues/157 . Fixes:

Re: Release timeline

On 2020-06-29 07:11, Wes Hardaker via Net-snmp-coders wrote: > Hugh McMaster writes: > >> net-snmp v5.8.1.pre2 was released a little over four months ago. >> >> Following a lot of excellent work by Bart and others since then, what >> is the proposed timeline for the next pre-release or final

Re: Net-SNMP 5.8 core dump

On 2020-05-26 10:49, David Moriconi (dmoricon) via Net-snmp-coders wrote: > The Net-SNMP daemon crashed with the following error (full backtrace can > be found below): > > Error in `/usr/local/netsnmp/netsnmp_base/sbin/snmpd': malloc(): > smallbin double linked list corrupted: 0x56546e6a9840

Re: tmpfs ignores

On 2020-05-26 04:46, Craig Small wrote: > I'm following up Debian bug report 685877 The main issue is tmpfs is > part of the HRFS_ignores array and so all tmpfs filesystems are > ignored and not displayed. > > This was added by Niels Baggesen back in 2004 with commit >

Re: net-snmp-5.8.1.pre2 released

On 2020-02-26 04:04, Wes Hardaker wrote: > Bart Van Assche writes: >> One change seems to be missing from this list, namely commit >> 9a2753282c6a ("new autoconf"). That commit regenerated the configure >> script with autoconf v2.69. Has it been considered to a

Re: net-snmp-5.8.1.pre2 released

On 2020-02-20 14:58, Wes Hardaker via Net-snmp-coders wrote: > > After far far too long of a delay, I've just pushed net-snmp-5.8.1.pre2 > to the download site: > > https://www.net-snmp.org/download.html > > Please give it a whirl, and report issues and fixes to our github site > at: > >

Re: FW: net-snmpd timeout on HPUX due to diverging interface data information

On 2020-02-21 03:53, Menase, Laurent (TS Engineering Resolution Team) wrote: > Is there a way to have this fix evaluated and included? What is the process? Hi Laurent, Please either resend this patch as a plain text attachment or submit a pull request to github. Thanks, Bart.

Re: Net-snmp 5.7.3

On 2020-01-30 21:17, Philippe DENIS via Net-snmp-coders wrote: > Hello, > > When building my sub agent in the same way than the sub-agent example, I got > some errors during the compilation; > u_char, u_long, u_short error unknown types. > > Have you experienced this issue ? > The Linux version

Re: NET-SNMP Installation Question_

On 2020-01-14 10:28, Peck, Ian A wrote: For the NET-SNMP installation is there any prerequisite SW that needs to be installed? For instance do I need visual studio installed before I try to install and use

Re: NET-SNMP-5.8

On 2019-12-30 02:39, Seyfullah BECERİKLİ wrote: > We have some issues installing net-snmp-5.8 version. Do you have any > specific installation guide for it? Hi Seyfullah, How about installing v5.8.1.pre1 instead of v5.8? A large number of bugs has been fixed in v5.8.1.pre1. That version is

Re: Linux: Initial interface list for IF-MIB

On 2019-10-23 14:03, Sam Tannous wrote: > (Posting this here to get a wider audience for my stuck patch review.) > > I have a patch in review (https://github.com/net-snmp/net-snmp/pull/24) > where I'm trying to prune a large number of interfaces (~2000 or more). Did the conversation in that pull

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On 8/26/19 3:12 PM, Bill Fenner wrote: It turns out a typo in the .travis.yml did not export the environment variables to the build script.  Looks like MODE=minimalist and MODE=read-only are both broken as-is: https://travis-ci.org/fenner/net-snmp/builds/577056671 Hi Bill, It seems like the

Re: commit e56699f5e2ef ("Add the ability to set the source address with "-s" for trapsess")

On 8/27/19 6:45 AM, Bill Fenner wrote: diff --cc man/snmpd.conf.5.def index eaa904f4b0,eaa904f4b0..43ca58f3ce --- a/man/snmpd.conf.5.def +++ b/man/snmpd.conf.5.def @@@ -851,9 -851,9 +851,9 @@@ can configure \fIsnmpd\fR to take a mor defines the default community string to be used when sending

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On 8/26/19 3:12 PM, Bill Fenner wrote: It turns out a typo in the .travis.yml did not export the environment variables to the build script.  Looks like MODE=minimalist and MODE=read-only are both broken as-is: https://travis-ci.org/fenner/net-snmp/builds/577056671 Hi Bill, If you submit the

Re: commit e56699f5e2ef ("Add the ability to set the source address with "-s" for trapsess")

On 8/26/19 9:08 AM, Bill Fenner wrote: Here's my proposed documentation: [ ... ] Hi Bill, Does this mean that you have a patch ready for man/snmpd.conf.5.def? If so, how about posting that patch for review? Thanks, Bart. ___ Net-snmp-coders

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On 8/26/19 12:59 PM, Bill Fenner wrote: > Just as a personal preference, I like to use "awk" instead of grep|... - > "awk '/NSF_WW/ {print $1}' $tmpf" gives the same result and doesn't care > about the presence or absence of the semicolon - but, I don't know about > Windows: if grep and sed are

commit e56699f5e2ef ("Add the ability to set the source address with "-s" for trapsess")

Hi Bill, Commit e56699f5e2ef added the ability to set the source address with "-s" for trapsess, which is great. Do you remember in which man page that option has been documented? Thanks, Bart. ___ Net-snmp-coders mailing list

Re: [net-snmp:code] 2 new commits to Code

On 7/10/19 9:49 AM, Bill Fenner wrote: On Mon, Jul 8, 2019 at 9:53 AM Bart Van Assche <bvanass...@acm.org> wrote: Hi

Re: [net-snmp:code] 2 new commits to Code

NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space By Bart Van Assche on 07/08/2019 04:15 View Changes Sent from sourceforge.net because you indicated

Re: [net-snmp:patches] #1388 patch for bug 2923: snmpv3 bulkget errors result in double free core dump

On 5/14/19 4:01 PM, Bill Fenner wrote: > Perhaps getbulk no longer dumps core, but I can not get it to return > anything but GENERR any more, and, it seems to leak memory. > > Any "large enough" request seems to fail in this way, e.g., > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime

Re: [net-snmp:patches] #1388 patch for bug 2923: snmpv3 bulkget errors result in double free core dump

On 5/14/19 4:01 PM, Bill Fenner wrote: > Perhaps getbulk no longer dumps core, but I can not get it to return > anything but GENERR any more, and, it seems to leak memory. > > Any "large enough" request seems to fail in this way, e.g., > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

On 5/13/19 12:10 PM, Vijay, Anjali wrote: Thanks for the help. Meanwhile, I had changed the buffer size back to 1472 and it seems to be working fine like the previous version, net-snmp 5.7.3. Do you think this can cause any serious impact? Hi Anjali, I think that approach is risky. It's easy

Re: [net-snmp:code] 4 new commits to Code

On 5/7/19 9:42 AM, Bill Fenner wrote: > I was hoping you might have an idea of a more graceful solution that > allows keeping const'ness.  If not, I can check in my change. Hi Bill, Please have a look at commit 068b4686739c ("libsnmp: Rework the MDblock() implementation"). Thanks, Bart.

Re: [net-snmp:code] 4 new commits to Code

test supports cross-compilation. In other words, --with-endianness > > > > no longer has to be specified during cross-compilation. > > > > > > By Bart Van Assche on 04/28/2019 20:40 > > > > View Changes > > > > > > > Hi Bart, >

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

On 4/25/19 5:56 PM, Bart Van Assche wrote: On 4/25/19 8:00 AM, Vijay, Anjali wrote: I recently started working with net-snmp-5.8. I had a query over a change that was made

Re: To understand the increase in size of buffer in agentx_parse() in net-snmp-5.8

On 4/25/19 8:00 AM, Vijay, Anjali wrote: I recently started working with net-snmp-5.8. I had a query over a change that was made to agentx_parse() in agent/mibgroup/agentx/protocol.c. I noticed that the

Re: [PATCH 0/6] Add support for interface binding

On 1/23/19 9:43 AM, Bill Fenner wrote: The pattern I was trying to follow from the existing code appeared to be basically if (cp == delimiter of optional section) {     *cp = '\0'; /* terminate previous section at delimiter */     this = cp + 1; /* handle this section */     cp = ... /*

Re: [PATCH 0/6] Add support for interface binding

On 1/22/19 12:40 PM, Bill Fenner wrote: On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche <mailto:bvanass...@acm.org>> wrote: On 11/6/18 8:03 AM, Bill Fenner wrote: > Given your proposed code structure, I imagine that we could add network > namespaces to

Re: [RFC] Add one line of information in snmpd.conf man page

On 1/11/19 1:20 AM, Masanari Iida wrote: Hello In snmpd.conf man page, in "monitor" option, I would like to see following information. Original: NAME is an administrative name for this expression, and is Original: used for indexing the mteTriggerTable (and related tables). Add: NAME

Re: A discussion about moving to GitHub from SF (again)

On 1/2/19 2:28 PM, Wes Hardaker via Net-snmp-coders wrote: Previously [1] we agreed to moved at least the code base to GitHub, with work on moving the wiki and other things as well. Shortly after that decision was made, GitHub was bought out by MS and the consensus changed to "hold and wait

Re: [PATCH 0/6] Add support for interface binding

On 11/6/18 12:31 PM, Bill Fenner wrote: Playing with this in V5-8-patches, I see it broke my fix for using clientaddr to specify the source address for traps: netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1", default_target ":0" netsnmp_sockaddr_in: addr 0xffd5e824, inpeername

Re: [PATCH 0/6] Add support for interface binding

On 11/6/18 8:03 AM, Bill Fenner wrote: My main question is, what's the advantage of storing the IPv4/IPv6 address as a string and a port number, instead of as a sockaddr_*? I.e., why use netsnmp_ep_str? Parsing endpoint addresses happens in two phases: first parsing the endpoint strings and

Re: [PATCH 0/6] Add support for interface binding

for doing this. --Sam Tannous On Sun, Oct 28, 2018 at 5:19 PM Bart Van Assche <mailto:bvanass...@acm.org>> wrote: Hello, As you may have noticed multiple people asked to add SO_BINDTODEVICE support to Net-SNMP. This patch series adds such support by allowing to specify the

Re: clientAddr ipv6

): commit 9b637efe809c490fdcaf30d1af20b4cbaef76e3e Author: Bart Van Assche Date: Sat Oct 27 20:34:21 2018 -0700 libsnmp/transports: Fix netsnmp_udp6_transport() Only create a transport object if parsing the client address succeeded instead of creating a transport object when parsing

Re: clientAddr ipv6

On Mon, 2018-10-29 at 09:52 +0530, Pushpa Thimmaiah wrote: > Hi All, > I am using option 'clientAddr' with IPv6 address and noticed that it is not > working. > so I applied patch > https://sourceforge.net/p/net-snmp/mailman/message/33064273/ on 5.7.3 but It > seems not working. > Kindly let me

Re: net-SNMP on windows getting decryption error

On 10/23/18 6:00 AM, Mark Christiansen wrote: Does anybody have ideas of what could be going wrong here? I built net-SNMP 5.8 for my Windows 10 machine. I set up my snmpd.conf file as shown below where I added the same users as I have on my Linux machine called aurelius. I get the following

[PATCH 2/6] libsnmp/transports: Introduce netsnmp_sockaddr_in3() and netsnmp_sockaddr_in6_3()

Introduce functions for converting Net-SNMP endpoint definitions into struct netsnmp_ep. Calls to these functions will be added in a later patch. --- include/net-snmp/library/snmpIPBaseDomain.h | 18 +++ include/net-snmp/library/snmpIPv4BaseDomain.h | 5 +++

[PATCH 3/6] libsnmp/transports: Change multiple sockaddr_in* arguments into netsnmp_ep

Make this change for all internal transport functions that will need the network interface information. This patch does not change any functionality. --- include/net-snmp/library/snmpDTLSUDPDomain.h | 4 +- include/net-snmp/library/snmpTCPDomain.h | 4 +-

[PATCH 5/6] libsnmp/transports: Add support for interface binding

--- include/net-snmp/library/snmpIPBaseDomain.h | 2 + snmplib/transports/snmpIPBaseDomain.c | 41 +++-- snmplib/transports/snmpIPv4BaseDomain.c | 2 + snmplib/transports/snmpIPv6BaseDomain.c | 2 + snmplib/transports/snmpTCPDomain.c | 7

[PATCH 6/6] testing/fulltests/unit-tests: Add netsnmp_parse_ep_str() unit test

--- testing/fulltests/support/clib_build | 1 + .../T022netsnmp_parse_ep_str_clib.c | 55 +++ 2 files changed, 56 insertions(+) create mode 100644 testing/fulltests/unit-tests/T022netsnmp_parse_ep_str_clib.c diff --git a/testing/fulltests/support/clib_build

[PATCH 0/6] Add support for interface binding

es) should these patches be applied? Master only or v5.8 and master? See also: * Add SO_BINDTODEVICE support (https://sourceforge.net/p/net-snmp/patches/1296/). * Add Linux VRF support (https://sourceforge.net/p/net-snmp/patches/1376/). Thanks, Bart. Bart Van Assche (6): libsnmp/transports:

[PATCH 4/6] configure: Add a test for SO_BINDTODEVICE

--- configure | 34 +++ configure.d/config_os_misc4 | 15 include/net-snmp/net-snmp-config.h.in | 3 +++ 3 files changed, 52 insertions(+) diff --git a/configure b/configure index 282631f4266e..fe05c50374f0 100755 ---

[PATCH 1/6] libsnmp/transports: Introduce netsnmp_parse_ep_str()

The only functional change in this patch is that it is now allowed to surround IPv4 addresses and hostnames with square brackets in transport endpoint definitions. --- include/net-snmp/library/snmpIPBaseDomain.h | 16 ++ include/net-snmp/library/snmpIPv4BaseDomain.h | 2 +

Re: Issue 10852 in oss-fuzz: net-snmp: Build failure

On 10/11/18 4:44 AM, Bill Fenner wrote: This is because the prototype is only protected with #ifndef NETSNMP_FEATURE_REMOVE_SWRUN_COUNT_PROCESSES_BY_REGEX and doesn't have the "#ifdef HAVE_PCRE_H" added to it, so if you compile without HAVE_PCRE_H, the definition of netsnmp_regex_ptr is

Re: Memory Leak in snmplib/keytools.c

On 10/10/18 10:53 AM, Roedersheimer, Drew A. wrote: I searched for usage of EVP_MD_CTX_free()/EVP_MD_CTX_new() and found a similar memory leak in the generate_Ku() function within snmplib/keytools.c. Also this patch has been applied on the master and v5.8 branches. Thanks for the patch,

Re: Memory Leak in snmplib/scapi.c

On 10/9/18 4:28 PM, Roedersheimer, Drew A. wrote: After applying the patch, Valgrind shows no memory leaks. Thanks for the patch! A slightly modified patch has been applied on the master and v5.8 branches. Comments or questions are welcome. My company is planning to supply this patch to

Re: Issue 10852 in oss-fuzz: net-snmp: Build failure

On 10/8/18 3:00 AM, ClusterFuzz-External via monorail wrote: Status: New Owner: CC: ma...@lysator.liu.se, bvanass...@acm.org, harda...@users.sourceforge.net, fen...@gmail.com, rst...@freesnmp.com Labels: Proj-net-snmp Type: Build-Failure New

Re: Junk in snmpwalk output

On Fri, 2018-10-05 at 00:56 +0200, Gisle Vanem via Net-snmp-coders wrote: > With this command: >snmpwalk.exe -M mibs -m ALL -v1 -c public 10.0.0.21 > > I've getting lines with junk in the output: >IPV6-MIB::ipv6NetToMediaValid.1.''.12 = INTEGER: true(1) >

Re: Bug Fix Process

On 10/3/18 4:10 PM, Roedersheimer, Drew A. wrote: I have identified a memory leak (and the corresponding fix) within the net-snmp library code. Should I just submit a bug report on Sourceforge and include the patch, or is there some other method that is preferable? If it's a small patch you

Re: snmpwalk test.net-snmp.org

On 9/30/18 1:26 PM, Mark Christiansen wrote: Lee, thanks for the sanity check. When I run the same command as you I get: $ /c/usr/bin/snmpwalk -v 2c -c demopublic test.net-snmp.org system Timeout: No Response from test.net-snmp.org I must

Re: RUNFULLTESTS results

On 9/25/18 6:42 AM, Mark Christiansen wrote: Is the MinGW build the best way to get net-SNMP up with OpenSSL on Windows? Or should I be doing it with Microsoft Visual Studio C++? MinGW build support was added before Microsoft Visual Studio became available as a free download. I think that

Re: RUNFULLTESTS results

On 9/24/18 7:15 PM, Mark Christiansen wrote: I think I got things figured out. Now I get the following error pop-up when I try to run RUNFULLTESTS:   "The code execution cannot proceed because libcrypto.dll was not found. Reinstalling the program may fix this problem. Note that there is no

Re: RUNFULLTESTS results

On 9/23/18 8:15 AM, Mark Christiansen wrote: What do these test results tell me is wrong about my build and system configuration? I assume they should all pass. All regression tests pass on Linux. Most of the regression tests but not all of them work correctly on other platforms. Porting

Re: building net-SNMP for Windows 10 in minGW32

On 9/21/18 8:34 PM, Mark Christiansen wrote: I switched to the same commit and I still get errors trying to apply the patch: $ patch -p1 < detect_socklen_t.patch patching file configure Hunk #1 FAILED at 26555. 1 out of 1 hunk FAILED -- saving rejects to file configure.rej patching file

Re: building net-SNMP for Windows 10 in minGW32

On 9/21/18 5:43 AM, Mark Christiansen wrote: Thanks. I tried to apply the patch and get the following:  $ git apply detect_socklen_t.patch                 ce warning: configure has type 100644, expected 100755 error: patch failed: configure:26555 error: configure: patch does not apply error:

Re: building net-SNMP for Windows 10 in minGW32

On 9/20/18 6:50 PM, Mark Christiansen wrote: On Thu, Sep 20, 2018 at 7:45 AM Bart Van Assche <mailto:bvanass...@acm.org>> wrote: On 9/20/18 6:08 AM, Mark Christiansen wrote: > In file included from snmp_client.c:94:0: > ../include/net-snmp/types.h:68:15: error: co

Re: running net snmp 5.7.3 on arm aarch64, is it ok?

On 9/18/18 11:53 PM, 宋金鑫 wrote: I am running our stack on new platform: arm aarch64, I get some strange crashes. like: #0  0xf6f91fd0 in strcmp () from /repo/HD_R/rootfs/brcm/fs.install/lib/libc.so.6 #1  0xf7373bac in internal_register_config_handler ()    from

Re: building net-SNMP for Windows 10 in minGW32

On 9/20/18 6:08 AM, Mark Christiansen wrote: In file included from snmp_client.c:94:0: ../include/net-snmp/types.h:68:15: error: conflicting types for 'socklen_t'  typedef u_int socklen_t;                ^ This is weird. There is a check for socklen_t in

Re: Test code review request

On 09/13/18 10:55, Bill Fenner wrote: I wrote some tests for traps and clientaddr, since there were a bunch of changes between 5.7 and 5.8 in this area.  I did a couple of unusual things: 1. I factored a ton of the test code out into a support file, S180trapaddrinfra, since the bulk of the

Re: Adding c files to build agent

On 08/21/18 07:52, Simon Chamlian wrote: > It is not that easy in my case because I am cross compiling the agent > for an embedded target system. Also, the whole package is being compiled > from within Yocto (bitbake). > > So I ran ./configure --with-mib-modules " file1 file2" > > I noticed this

Re: Building net-snmp MIB support as loadable module

On 08/21/18 03:52, Tomasz Kłoczko wrote: > Looks like snmpd agent supports extending agent functionalities by > loading on run-time DSO module with additional MIBs support. > Have question: is it possible to build net-snmp code to support to add > exact supported by net-snmp MIBs not as compiled

Re: Adding c files to build agent

On 08/21/18 06:01, Simon Chamlian wrote: > Any pointers on how I can use AgentX ? Please keep the list in Cc: when replying. More information about AgentX is available at http://net-snmp.sourceforge.net/wiki/index.php/TUT:Writing_a_Subagent. Since it has been a while since that page has been

Re: Adding c files to build agent

On 08/20/18 13:26, Simon Chamlian wrote: > I am trying to adapt the agent to our requirements. In order to do so, I > need to add some code (c files) to the agent to handle our own MIB. > > The agent is running on an embedded system (Linux-systemd) using Yocto > to build it. > > Where (in which

Re: IPv6 and MSVC-2017

On 08/14/18 08:56, Gisle Vanem wrote: > Bart Van Assche wrote: >> As one can see on >> https://ci.appveyor.com/project/BVanAssche87257/net-snmp >> the build of the Net-SNMP master branch >> passes for MSVC-2017, > > Really? From: >    > https://ci.appvey

Re: IPv6 and MSVC-2017

On 08/13/18 05:37, Gisle Vanem via Net-snmp-coders wrote: It's been > 3 years since I've compiled using MinGW. Now I'm sticking more to clang-cl and MSVC and notice the support for MSVC wrt. to IPv6 is in a real (excuse my French) shitty state. E.g. the '{ }' syntax is not allowed on MSVC:  

Re: Simple Application Visual Studio 2015

yan > > -----Original Message- > From: Bart Van Assche [mailto:bvanass...@acm.org] > Sent: Tuesday, July 24, 2018 11:39 PM > To: Ryan Sharpe ; net-snmp-coders@lists.sourceforge.net > Subject: Re: Simple Application Visual Studio 2015 > > How did you build Net-SNMP?

Re: Simple Application Visual Studio 2015

On 07/24/18 11:48, Ryan Sharpe wrote: > I am new to this and am trying to build and run the Net-SNMP Simple > Application tutorial in Visual Studio 14.0 with Net-SNMP 5.8 > > For my main, I am using the default Simple Application code provided on > the Net-SNMP webpage > > I added the Include,

Re: Behavior of snmp_clone_pdu

On 07/05/18 09:39, Ramki wrote: It is on Linux and I have already tried valgrind. It is not reporting any leaks or reachable memory during exit. Hello Ramki, Please do not reply at the top of an e-mail the previous reply was at the bottom. See also

Re: Behavior of snmp_clone_pdu

On 07/05/18 01:21, Ramki wrote: > We are implementing a SNMP agent using the NET SNMP library (C). > As part of the agent we need to handle the trap burst scenario (1250 > traps per second for 75 seconds). We have added a memory based queue > that reads SNMP from the netsnmp_session callback

Re: Net-SNMP 5.8.rc4 available for testing

On 07/02/18 06:46, Robert Story wrote: > On Fri, 29 Jun 2018 13:38:27 -0700 Bart wrote: > BVA> Can you explain why you have ignored all nine patches that I > BVA> posted one week ago? Had you noticed that one of these patches > BVA> is a build fix? See also > BVA>

Re: Net-SNMP 5.8.rc4 available for testing

On 06/28/18 16:06, Robert Story wrote: Net-SNMP 5.8.rc4 is now available for testing at https://sourceforge.net/projects/net-snmp/files/net-snmp/5.8-release-candidates/ Below is a summary of the change in 5.8.rc4. Please see the CHANGES file for a more detailed list of specific

[PATCH 5/9] snmplib/transports: Unbreak the MSVC build

Adding an integer to a void pointer works fine with gcc but not with MSVC. Hence convert the expressions that add an integer to a void pointer into a construct that is standard C. --- snmplib/transports/snmpIPXDomain.c | 16 ++-- snmplib/transports/snmpIPv4BaseDomain.c | 12

[PATCH 9/9] SNMP-TARGET-MIB: Add SNMPv3 USM trap testcases

From: Anders Wallin Added 6 test case for sending traps from snmpd. The test cases includes traps or informs, statically configured trapsess in snmpd and dynamically configured traps using snmpset. Signed-off-by: Anders Wallin [bvanassche: Fixed shellcheck warnings / introduced settmib() and

[PATCH 8/9] SNMP-TARGET-MIB: Send dynamic traps even if no trap sessions have been defined

The counters _v1_sessions and _v2_sessions in the source file agent/agent_trap.c keep track of how many trap sessions have been created. These counters are not updated if a row is added to snmpTargetAddrTable. The result is that all snmpTargetAddrTable rows are ignored if no trap sessions have

[PATCH 6/9] SNMP-NOTIFICATION-MIB: Add missing trailing newlines to debug statements

--- agent/mibgroup/notification/snmpNotifyTable_data.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/agent/mibgroup/notification/snmpNotifyTable_data.c b/agent/mibgroup/notification/snmpNotifyTable_data.c index 9a2b42f98734..ee768143d169 100644 ---

[PATCH 3/9] python/netsnmp/client_intf.c: Fix compiler warnings

The only functional change in this patch is that a "" argument is changed into NULL. According to the Python documentation NULL is a valid argument. From the Python C API documentation: The format may be NULL, indicating that no arguments are provided. See also

  1   2   3   4   5   6   >