Re: Fix patch for SF bug 2833
Bart Van Assche : > I think that variable.magic is only needed if the old MIB registration API is > used (register_mib() etc.). That API was deprecated more than ten years ago. > I think that we should tell users to move away from that API rather than > helping them with fixing the shortcomings of that API. 2833 should probably be maeked WONTFIX abd closed with that exolamation, then. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)
Bart Van Assche : > On 03/22/18 15:56, Keith Mendoza wrote: > >Looking into using clang on Windows might be worth the effort to get > >net-snmp code caught up to C99. Google Chrome now uses clang to > >compile in Windows: > >http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html > > We do not only need a compiler on Windows but also the Windows API header > files, e.g. for building the winExtDLL module. Microsoft owns the copyright > on the Windows API header files. Does clang for Windows include Windows > header files? I think MinGW comes with a clean-room rewrite of the Windows > header files to avoid copyright issues. See also > http://mingw.org/history. This article https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/ suggests the problem may have been solved, or nearly so. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Unstable tests
On 03/22/18 12:22, Eric S. Raymond wrote: Bart Van Assche : Hello Eric, These are the only two tests that sometimes fail on my test setup. Whether or not these tests pass depends on your DNS server. If I e.g. add "nameserver 8.8.8.8" as the first entry in /etc/resolv.conf then these tests pass on my setup. I think the reason is that the domain names used by that test resolve into 127.0.0.x and because some DNS servers filter these results. Bart. You guys have been at this too long. You're failing to document your assumptions. From 6cd949342a65ff2260253bca234bfa08f8e3b5c2 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Thu, 22 Mar 2018 15:20:21 -0400 Subject: [PATCH] INSTALL: explain workaround for comsec test failures. --- INSTALL | 11 +++ 1 file changed, 11 insertions(+) diff --git a/INSTALL b/INSTALL index aad9099..9bcd65a 100644 --- a/INSTALL +++ b/INSTALL @@ -6,6 +6,7 @@ TABLE OF CONTENTS * Net-SNMP Specific Information Long (but you should read these) Instructions Installing the Perl/SNMP Module + Tests * Compilers and Options Compiling For Multiple Architectures Installation Names @@ -155,6 +156,16 @@ Net-SNMP libraries and demon applications. make test make install (as root) +Tests += + +The ordinary self-test sequence can be invoked with "make test". There +are more comprehensive options. + +Spurious failures on the "comsec" tests can be due to misconfigured +DNS upstream of you. A workaround is to point your DNS server at a +non-broken one. Adding "nameserver 8.8.8.8" as the first entry in +/etc/resolv.conf will do. Thanks for the patch but some people do not read the documentation unfortunately. It would make me happier if we could modify the test such that its outcome does not depend on whether or not an intermediate DNS server filters out invalid answers. Bart. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fix patch for SF bug 2833
On 03/22/18 10:37, Eric S. Raymond wrote: Bart Van Assche : This patch changes a data structure in a public header file and hence breaks the ABI. This is something we could do for Net-SNMP 5.8 since there has not yet been any 5.8 release but it's something we can't do for older Net-SNMP versions. I withdraw the suggestion. Procedurally, do you have an official queue of patches deferred to the next major release, or a repository branch for them? Putting the patch there would be a reasonable way to close 2833. Is changing the size of variable.magic the best solution for bug #2833? I think that variable.magic is only needed if the old MIB registration API is used (register_mib() etc.). That API was deprecated more than ten years ago. I think that we should tell users to move away from that API rather than helping them with fixing the shortcomings of that API. From include/net-snmp/net-snmp-config.h.in: /* * NETSNMP_MARK_BEGIN_LEGACY_DEFINITIONS */ /* * existing definitions prior to Net-SNMP 5.4 * * do not add anything new here * */ #ifndef NETSNMP_NO_LEGACY_DEFINITIONS [ ... ] #endif An example of how to use the new API is available at http://net-snmp.sourceforge.net/wiki/index.php/TUT:mib2c_scalar. Bart. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)
On 03/22/18 15:56, Keith Mendoza wrote: Looking into using clang on Windows might be worth the effort to get net-snmp code caught up to C99. Google Chrome now uses clang to compile in Windows: http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html We do not only need a compiler on Windows but also the Windows API header files, e.g. for building the winExtDLL module. Microsoft owns the copyright on the Windows API header files. Does clang for Windows include Windows header files? I think MinGW comes with a clean-room rewrite of the Windows header files to avoid copyright issues. See also http://mingw.org/history. Bart. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Fwd: RE: C99 (was: Re: Fix patch for SF bug 2833)
Looking into using clang on Windows might be worth the effort to get net-snmp code caught up to C99. Google Chrome now uses clang to compile in Windows: http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html Thanks, Keith -Original Message- Subject: RE: C99 (was: Re: Fix patch for SF bug 2833) Date: Thu, 22 Mar 2018 18:27:47 + (UTC) From: Steve Friedl To: e...@thyrsus.com, 'Bill Fenner' CC: 'Net-SNMP Coders' net-snmp is expected to build on Windows, which gpsd does not; it's not clear how much this impacts compiler choice. -Original Message- From: Eric S. Raymond [mailto:e...@thyrsus.com] Sent: Thursday, March 22, 2018 10:32 AM To: Bill Fenner Cc: Net-SNMP Coders Subject: C99 (was: Re: Fix patch for SF bug 2833) Bill Fenner : > On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond wrote: > > > On the other hand, I question whether the extra overhead is a real > > issue in 2018. > > > I have the same question, but know that I have no useful opinion here > - my "embedded system" ships with 4 gigs minimum, but the project has > more use cases than mine. Bart's objection about changing the public ABI is a showstopper and I wihdraw the suggestion. On the other hand... >For example, the project did decide to back off from introducing c99 constructs. *This* is an issue about which I know something important that does not seem to have percolated into general knowledge yet. I lead the GPSD project, a daemon for handling GPSes and other geolocation sources. It's deployed *everywhere* - smartphones, driverless cars, marine navigation systems, main battle tanks, drones and UAVs, first-responder comm gear, you name it. If GPSD makes an assumption that breaks any Unix build chain or portability anywhere, I get a complaint right quick. I've fielded dozens of these. Maybe the weirdest one was due to actual signed chars on a 360 mainframe. There came a point at which I got tired of seeing legacy ifdefs from ancient big iron in my codebase. Thought about my options, decided to move to assuming C99 and SuSv2. I shipped a point release on this premise expecting at least some minor pushback from some odd legacy environment. I heard not a peep, and never have since. And this was in 2009. If that's not enough, since 2015 I have led the NTPsec project. Based on GPSD experience we made the same decision to assume a C99/SuSv2 base. With no problems whatsoever except that on old versions of MacOS one of the time primitives is broken. That's how I learned that the standards people won. Our traditional twitchiness about tossing out any portability shim back to the year zero is obsolete. And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the host API than snmpd does, so the test has been more stringent. GPSD has to get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even further into system clock handling. I can say with confidence that assuming C99 is *very* safe in 2018. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Patch for build instructions
Bill Fenner : > On Thu, Mar 22, 2018 at 3:26 PM, Eric S. Raymond wrote: > > > Or possibly it might have but your build system messed me over. I don't > > trust > > autoconf as far as I can throw it. > > > > I understand someone's done a conversion to cmake. Does that make you > happier or vomityer? Very slightly happier - at least cmake's implementation isn't nasty crocks and kludges all the way down like autoconf's is. Alas, cmake shares one of autoconf's fundamental design flaws: It's two-phase system that works by generating Makefiles. This makes good diagnostics basically impossible - any point of failure in the make execution is too decoupled from the originating recipe. Two-phase systems have other flaws too. They make it much harder, maybe impossible, to parallelize a build in a way that's provably correct with respect to dependencies. (I think this could be done in theory but all two-phase systems I know of seem incapable of getting it right in practice.) I greatly prefer one-phase systems like scons or waf that directly interpret the recipe. They easily avoid both of the practical problems I just mentioned - in particular, if you know what you're doing you can get provably correct parallelism from a toposort of the dependency graph. I think waf is currently the best of breed - it's what we've been using on NTPsec and I find its speed and parallelization performance is unmatched - but I acknowledge one serious problem with it; the documentation is terrible. Very comprehensive if you can think like the designer but for anyone else it might as well be written in Sanskrit mixed with tensor calculus. Makes the learning curve a bit rough. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Patch for build instructions
On Thu, Mar 22, 2018 at 3:26 PM, Eric S. Raymond wrote: > Or possibly it might have but your build system messed me over. I don't > trust > autoconf as far as I can throw it. > I understand someone's done a conversion to cmake. Does that make you happier or vomityer? Bill -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Patch for build instructions
Bill Fenner : > Not to mention that "install libperl-dev" means nothing on Solaris, or > FreeBSD, or MacOS, or other supported systems. OK, but are you going to let the better be the enemy of the good, or merge that patch and improve on it based on your experience? I'm not throwing these doc patches at you with a belief that they're in themselves final answers. Rather, they're to point out exactly where the defect is and hopefully stimulate a response. (I'd be much more careful about what I sent as a code patch.) -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Patch for build instructions
Bart Van Assche : > On 03/21/18 19:47, Eric S. Raymond wrote: > >>From 2ffbdd9e8f15eb3e3dc985ab3aa0a12d798e4b78 Mon Sep 17 00:00:00 2001 > >From: "Eric S. Raymond" > >Date: Wed, 21 Mar 2018 20:24:40 -0400 > >Subject: [PATCH] INSTALL: Fix for build instructions. > > > >Mention a prerequisite that will trip people up under Ubuntu. > >--- > > INSTALL | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > >diff --git a/INSTALL b/INSTALL > >index 24f8d6c..aad9099 100644 > >--- a/INSTALL > >+++ b/INSTALL > >@@ -27,7 +27,8 @@ QUICK INSTRUCTIONS > > (due to prompting done by the configure script, this is very rarely > >necessary.) > >- 3) make > >+ 3) Run make. If the build fails with a complaint that it can't resolve > >+ -lperl, install libperl-dev and try again. > >4) Run the next command as root: > >5) make install > > This should be elaborated further: another alternative is to pass > --disable-embedded-perl to the configure script. I actually tried that before installing libperl-dev. It didn't seem to work. Or possibly it might have but your build system messed me over. I don't trust autoconf as far as I can throw it. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Unstable tests
Bart Van Assche : > Hello Eric, > > These are the only two tests that sometimes fail on my test setup. Whether > or not these tests pass depends on your DNS server. If I e.g. add > "nameserver 8.8.8.8" as the first entry in /etc/resolv.conf then these tests > pass on my setup. I think the reason is that the domain names used by that > test resolve into 127.0.0.x and because some DNS servers filter these > results. > > Bart. You guys have been at this too long. You're failing to document your assumptions. >From 6cd949342a65ff2260253bca234bfa08f8e3b5c2 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Thu, 22 Mar 2018 15:20:21 -0400 Subject: [PATCH] INSTALL: explain workaround for comsec test failures. --- INSTALL | 11 +++ 1 file changed, 11 insertions(+) diff --git a/INSTALL b/INSTALL index aad9099..9bcd65a 100644 --- a/INSTALL +++ b/INSTALL @@ -6,6 +6,7 @@ TABLE OF CONTENTS * Net-SNMP Specific Information Long (but you should read these) Instructions Installing the Perl/SNMP Module + Tests * Compilers and Options Compiling For Multiple Architectures Installation Names @@ -155,6 +156,16 @@ Net-SNMP libraries and demon applications. make test make install (as root) +Tests += + +The ordinary self-test sequence can be invoked with "make test". There +are more comprehensive options. + +Spurious failures on the "comsec" tests can be due to misconfigured +DNS upstream of you. A workaround is to point your DNS server at a +non-broken one. Adding "nameserver 8.8.8.8" as the first entry in +/etc/resolv.conf will do. Compilers and Options = -- 2.7.4 -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
RE: C99 (was: Re: Fix patch for SF bug 2833)
net-snmp is expected to build on Windows, which gpsd does not; it's not clear how much this impacts compiler choice. -Original Message- From: Eric S. Raymond [mailto:e...@thyrsus.com] Sent: Thursday, March 22, 2018 10:32 AM To: Bill Fenner Cc: Net-SNMP Coders Subject: C99 (was: Re: Fix patch for SF bug 2833) Bill Fenner : > On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond wrote: > > > On the other hand, I question whether the extra overhead is a real > > issue in 2018. > > > I have the same question, but know that I have no useful opinion here > - my "embedded system" ships with 4 gigs minimum, but the project has > more use cases than mine. Bart's objection about changing the public ABI is a showstopper and I wihdraw the suggestion. On the other hand... >For example, the project did decide to back off from introducing c99 constructs. *This* is an issue about which I know something important that does not seem to have percolated into general knowledge yet. I lead the GPSD project, a daemon for handling GPSes and other geolocation sources. It's deployed *everywhere* - smartphones, driverless cars, marine navigation systems, main battle tanks, drones and UAVs, first-responder comm gear, you name it. If GPSD makes an assumption that breaks any Unix build chain or portability anywhere, I get a complaint right quick. I've fielded dozens of these. Maybe the weirdest one was due to actual signed chars on a 360 mainframe. There came a point at which I got tired of seeing legacy ifdefs from ancient big iron in my codebase. Thought about my options, decided to move to assuming C99 and SuSv2. I shipped a point release on this premise expecting at least some minor pushback from some odd legacy environment. I heard not a peep, and never have since. And this was in 2009. If that's not enough, since 2015 I have led the NTPsec project. Based on GPSD experience we made the same decision to assume a C99/SuSv2 base. With no problems whatsoever except that on old versions of MacOS one of the time primitives is broken. That's how I learned that the standards people won. Our traditional twitchiness about tossing out any portability shim back to the year zero is obsolete. And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the host API than snmpd does, so the test has been more stringent. GPSD has to get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even further into system clock handling. I can say with confidence that assuming C99 is *very* safe in 2018. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Unstable tests
Bill Fenner : > So before, you meant you failed test 31 of the "com2sec directive" suite? I'm not even sure that's what I saw. My apologies, I'm new to this code and the test output is somwhat confusing. > Try "cd testing; SNMP_VERBOSE=2 ./RUNFULLTESTS -v -r T070com2sec" to get > more detail about why it failed. > > Test 30 and 31 could fail if your DNS resolver performs "helpful" NXDOMAIN > remapping - e.g., does > > ping no.such.address. > return > ping: unknown host no.such.address. > or does it return something like > PING no.such.address (92.242.140.21) 56(84) bytes of data. The latter. I guess that's the problem. > There's an assumption in the test suite that the DNS server is not insane, > but of course most home ISPs provide insane DNS servers by default. Most > providers give you the option to use a sane one, or of course you could > change your /etc/resolv.conf to point to a sane public DNS provider. I have a Verizon FIOS business account. The rot has spread to more than "home" service. This problem should be documented where people running the tests will see it. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fix patch for SF bug 2833
Bart Van Assche : > This patch changes a data structure in a public header file and hence breaks > the ABI. This is something we could do for Net-SNMP 5.8 since there has not > yet been any 5.8 release but it's something we can't do for older Net-SNMP > versions. I withdraw the suggestion. Procedurally, do you have an official queue of patches deferred to the next major release, or a repository branch for them? Putting the patch there would be a reasonable way to close 2833. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
C99 (was: Re: Fix patch for SF bug 2833)
Bill Fenner : > On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond wrote: > > > On the other hand, I question whether the extra overhead is a real > > issue in 2018. > > > I have the same question, but know that I have no useful opinion here - my > "embedded system" ships with 4 gigs minimum, but the project has more use > cases than mine. Bart's objection about changing the public ABI is a showstopper and I wihdraw the suggestion. On the other hand... >For example, the project did decide to back off from introducing c99 >constructs. *This* is an issue about which I know something important that does not seem to have percolated into general knowledge yet. I lead the GPSD project, a daemon for handling GPSes and other geolocation sources. It's deployed *everywhere* - smartphones, driverless cars, marine navigation systems, main battle tanks, drones and UAVs, first-responder comm gear, you name it. If GPSD makes an assumption that breaks any Unix build chain or portability anywhere, I get a complaint right quick. I've fielded dozens of these. Maybe the weirdest one was due to actual signed chars on a 360 mainframe. There came a point at which I got tired of seeing legacy ifdefs from ancient big iron in my codebase. Thought about my options, decided to move to assuming C99 and SuSv2. I shipped a point release on this premise expecting at least some minor pushback from some odd legacy environment. I heard not a peep, and never have since. And this was in 2009. If that's not enough, since 2015 I have led the NTPsec project. Based on GPSD experience we made the same decision to assume a C99/SuSv2 base. With no problems whatsoever except that on old versions of MacOS one of the time primitives is broken. That's how I learned that the standards people won. Our traditional twitchiness about tossing out any portability shim back to the year zero is obsolete. And bear in mind that GPSD/NTPsec probably exercises a wider swathe of the host API than snmpd does, so the test has been more stringent. GPSD has to get deep into odd corners of the tty driver and kernel PPS; NTPsec gets even further into system clock handling. I can say with confidence that assuming C99 is *very* safe in 2018. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Unstable tests
On 03/21/18 20:41, Eric S. Raymond wrote: Ian and I note that the test suite seems a bit compromised. Hello Eric, When running compile tests and the test suite I think it is a good idea to enable as many Net-SNMP features as possible. You may want to have a look at the attached shell scripts - these are the scripts I use myself to rebuild Net-SNMP and to run the regression tests. The net-snmp-run-perl-tests script needs more work - I have not yet had the time to figure out all the environment variable settings to make it pick up its dependencies from the build directory instead of requiring "make install" to be run first. Bart. #!/usr/bin/env bash if [ -e .git ]; then cat .git/HEAD | sed 's:.*/::' elif [ -e .svn ]; then svn info . | sed -n 's=^URL: .*/\([^/]*\)$=\1=p' else echo branch-name-not-known fi #!/usr/bin/env bash # Necessary software packages for building Net-SNMP: # autoconf automake libtool m4 # glibc glibc-devel libssh2 libssh2-devel openssl openssl-devel rpm-devel # perl-ExtUtils-MakeMaker perl-ExtUtils-Embed perl-Test-Harness # python python-devel python-setuptools scriptdir="$(dirname "$0")" branch_name="$("$scriptdir/branch-name")" is_5_4_or_above="false" is_5_5_or_above="false" is_5_6_or_above="false" is_5_7_or_above="false" is_5_8_or_above="false" if [ "${branch_name#master}" != "${branch_name}" ]; then is_5_8_or_above="true" is_5_7_or_above="true" is_5_6_or_above="true" is_5_5_or_above="true" is_5_4_or_above="true" elif [ "${branch_name#V5-7-}" != "${branch_name}" ]; then is_5_7_or_above="true" is_5_6_or_above="true" is_5_5_or_above="true" is_5_4_or_above="true" elif [ "${branch_name#V5-6-}" != "${branch_name}" ]; then is_5_6_or_above="true" is_5_5_or_above="true" is_5_4_or_above="true" elif [ "${branch_name#V5-5-}" != "${branch_name}" ]; then is_5_5_or_above="true" is_5_4_or_above="true" elif [ "${branch_name#V5-4-}" != "${branch_name}" ] || [ "${branch_name%-5.4.2.1}" != "${branch_name}" ] then is_5_4_or_above="true" fi have_rtnetlink=true #srcdir=${1:-.}; shift if ! echo "$*" | grep -Eq 'with-openssl=(no|internal)'; then opensslver="$( case "${OSTYPE}" in linux*) for p in openssl-devel libopenssl-devel libressl-devel; do rpm -q --qf '%{version}\n' $p 2>/dev/null; done; dpkg-query --show -f '${Version}\n' libssl-dev 2>/dev/null; pacman -Q openssl 2>&1 | sed -n 's/^openssl[[:blank:]]*//p';; *) echo 1.0;; esac)" fi if grep -q 'CentOS release 4' /etc/issue 2>/dev/null; then opensslver="" have_rtnetlink=false fi opensshver="$({ rpm -q openssh-devel; rpm -q libssh2-devel; rpm -q libssh-devel; } 2>/dev/null | sed -n 's/^.*ssh[0-9]*-devel-\([0-9a-z.]*\)-.*$/\1/p' | head -n1)" srcdir=. cflags="-g -O0 -pipe ${CFLAGS}" #cflags="-DNETSNMP_USE_ASSERT ${CFLAGS}" if true; then # Disable inlining to make debugging easier cflags="$cflags -fno-strict-aliasing -fno-inline -fno-inline-functions -fno-inline-functions-called-once -fno-early-inlining -Wno-inline" if gcc -fno-inline-small-functions -xc -c - /dev/null 2>&1; then cflags="$cflags -fno-inline-small-functions" fi fi # See also the top-level Net-SNMP Makefile.in. export NOAUTODEPS=y options=() options+=(--enable-developer) options+=(--enable-ipv6) options+=("--with-cflags=$cflags") options+=(--with-defaults) transports=() [ "$opensshver" != "" ] && $is_5_5_or_above && transports+=(SSH) # Mib names can be found as follows: # (cd agent/mibgroup && # git grep -lE 'void[[:blank:]]*init_.*\(void\)|config_require\(' | # sed -n 's/\.h$//p') mibs=() mibs+=(examples/data_set) mibs+=(examples/delayed_instance) mibs+=(examples/example) mibs+=(examples/notification) mibs+=(examples/scalar_int) mibs+=(examples/ucdDemoPublic) mibs+=(examples/watched) mibs+=(mibII) mibs+=(smux) case "$(uname)" in Linux*) $is_5_8_or_above && options+=(--enable-blumenthal-aes) options+=(--enable-new-features) options+=("--prefix=/usr/local/net-snmp-${branch_name}") $is_5_7_or_above && mibs+=(deliver/deliverByNotify) mibs+=(disman/event) mibs+=(disman/expression) mibs+=(disman/mteEventNotificationTable) mibs+=(disman/mteEventTable) mibs+=(disman/mteObjectsTable) mibs+=(disman/mteTriggerBooleanTable) mibs+=(disman/mteTriggerDeltaTable) mibs+=(disman/mteTriggerExistenceTable) mibs+=(disman/mteTriggerTable) mibs+=(disman/mteTriggerThresholdTable) mibs+=(disman/nslookup-mib) mibs+=(disman/ping-mib) mibs+=(disman/schedule) mibs+=(disman/traceroute-mib) $is_5_5_or_above && $have_rtnetlink && mibs+=(etherlike-mib) mibs+=(examples/netSnmpHostsTable) mibs+=(hardware/cpu) $is_5_5_or_above && mibs+=(hardware/fsys) mibs+=(hardware/memory) $is_5_5_or_above && mibs+=(hardware/sensors) mibs+=(host) mibs+=(ip-forward-mib) mibs+=(ip-mib/ine
Re: Patch for build instructions
On Thu, Mar 22, 2018 at 9:37 AM, Bart Van Assche wrote: > On 03/21/18 19:47, Eric S. Raymond wrote: > >> - 3) make >>> >> + 3) Run make. If the build fails with a complaint that it can't resolve >> + -lperl, install libperl-dev and try again. >> > This should be elaborated further: another alternative is to pass > --disable-embedded-perl to the configure script. Not to mention that "install libperl-dev" means nothing on Solaris, or FreeBSD, or MacOS, or other supported systems. The best solution here would be to make configure recognize that it doesn't have the prerequisites available. Bill -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: var_vacm_access() question
On Wed, Mar 21, 2018 at 5:50 PM, Keith Mendoza wrote: Hi, > I'm one of the volunteer developers with ICEI (please see email with > subject "ICEI asks what help you need" for details). I was attempting > to compile net-snmp code with -std=c99 compiler option, and the > compiler failed with "error: overflow in implicit constant conversion > [-Werror=overflow] on the following lines in > net-snmp-code/agent/mibII/vacm_vars.c: 382, 397, and 593. These 3 > locations have *cp++ = 255; > > So, my question is where can I get more information on > var_vacm_access(). It appears to me it has something to do with > determining group access control for a MIB group. Specifically, what > is the rational for incrementing, then basically setting the location > pointed by "cp" to 255 given the if logic above each of the 3 > locations where *cp++ = 255 is set. > Keith, The blocks in question look like oid*op; char *cp; ... cp = contextPrefix; for (i = 0; i <= len && op < name + *length; i++) { if (*op > 255) { *cp++ = 255; ++op; } else *cp++ = (char) *op++; } The underlying type of oid is int or long, so it becomes obvious that this code is copying values from op to cp while truncating values that won’t fit into a char. It’s probably not unreasonable to change the relevant types to u_char. Bill -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fix patch for SF bug 2833
On 03/21/18 19:43, Eric S. Raymond wrote: From 54e79ba66327bdb54f97f457d76531f657ec546d Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Wed, 21 Mar 2018 22:22:29 -0400 Subject: [PATCH] include/net-snmp/agent/{snmp_vars.h,var_struct.h}: address SF bug 2833. Are you familiar with "git send-email"? Using that command may be more convenient that copy/pasting patches into an e-mail. diff --git a/include/net-snmp/agent/snmp_vars.h b/include/net-snmp/agent/snmp_vars.h index bd27eeb..b2f2f8f 100644 --- a/include/net-snmp/agent/snmp_vars.h +++ b/include/net-snmp/agent/snmp_vars.h @@ -101,7 +101,7 @@ PERFORMANCE OF THIS SOFTWARE. #define INST 0x /* used to fill out the instance field of the variables table */ struct variable { -u_char magic; /* passed to function as a hint */ +u_short magic; /* passed to function as a hint */ chartype; /* type of variable */ /* * See important comment in snmp_vars.c relating to acl This patch changes a data structure in a public header file and hence breaks the ABI. This is something we could do for Net-SNMP 5.8 since there has not yet been any 5.8 release but it's something we can't do for older Net-SNMP versions. Bart. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Patch for build instructions
On 03/21/18 19:47, Eric S. Raymond wrote: From 2ffbdd9e8f15eb3e3dc985ab3aa0a12d798e4b78 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Wed, 21 Mar 2018 20:24:40 -0400 Subject: [PATCH] INSTALL: Fix for build instructions. Mention a prerequisite that will trip people up under Ubuntu. --- INSTALL | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/INSTALL b/INSTALL index 24f8d6c..aad9099 100644 --- a/INSTALL +++ b/INSTALL @@ -27,7 +27,8 @@ QUICK INSTRUCTIONS (due to prompting done by the configure script, this is very rarely necessary.) - 3) make + 3) Run make. If the build fails with a complaint that it can't resolve + -lperl, install libperl-dev and try again. 4) Run the next command as root: 5) make install This should be elaborated further: another alternative is to pass --disable-embedded-perl to the configure script. Bart. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Unstable tests
On 03/22/18 05:33, Eric S. Raymond wrote: Now I'm getting a different result, which is a little disturbing in itself: com2sec directive (Wstat: 256 Tests: 31 Failed: 1) Failed test: 30 Non-zero exit status: 1 Files=76, Tests=327, 109 wallclock secs ( 0.28 usr 0.07 sys + 13.58 cusr 4.74 csys = 18.67 CPU) Result: FAIL We failed these 1 tests: com2sec directive ( /home/esr/software/net-snmp-code/testing/fulltests/default/T070com2sec_simple ) Hello Eric, These are the only two tests that sometimes fail on my test setup. Whether or not these tests pass depends on your DNS server. If I e.g. add "nameserver 8.8.8.8" as the first entry in /etc/resolv.conf then these tests pass on my setup. I think the reason is that the domain names used by that test resolve into 127.0.0.x and because some DNS servers filter these results. Bart. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fix patch for SF bug 2833
On Thu, Mar 22, 2018 at 9:16 AM, Eric S. Raymond wrote: > On the other hand, I question whether the extra overhead is a real > issue in 2018. I have the same question, but know that I have no useful opinion here - my "embedded system" ships with 4 gigs minimum, but the project has more use cases than mine. For example, the project did decide to back off from introducing c99 constructs. Bill -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Unstable tests
On Thu, Mar 22, 2018 at 8:33 AM, Eric S. Raymond wrote: > Bill Fenner : > > By "test 31" do you mean "snmpv1 traps are sent by snmpd API"? > > Now I'm getting a different result, which is a little disturbing in itself: > > com2sec directive > (Wstat: 256 Tests: 31 Failed: 1) > Failed test: 30 > Non-zero exit status: 1 > Files=76, Tests=327, 109 wallclock secs ( 0.28 usr 0.07 sys + 13.58 cusr > 4.74 csys = 18.67 CPU) > Result: FAIL > So before, you meant you failed test 31 of the "com2sec directive" suite? Try "cd testing; SNMP_VERBOSE=2 ./RUNFULLTESTS -v -r T070com2sec" to get more detail about why it failed. Test 30 and 31 could fail if your DNS resolver performs "helpful" NXDOMAIN remapping - e.g., does > ping no.such.address. return ping: unknown host no.such.address. or does it return something like PING no.such.address (92.242.140.21) 56(84) bytes of data. There's an assumption in the test suite that the DNS server is not insane, but of course most home ISPs provide insane DNS servers by default. Most providers give you the option to use a sane one, or of course you could change your /etc/resolv.conf to point to a sane public DNS provider. Bill -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fix patch for SF bug 2833
Bill Fenner : > I don't think the patch is the issue. There are two questions to be > addressed first: > > 1. For the embedded environment, is it acceptable to use an extra several > bytes for this (or is there a way to rearrange the struct so that padding > reduces the extra cost)? A couple of instances I looked at could be repacked to avoid the 1 char of slop using techniques I described in http://www.catb.org/esr/structure-packing/ On the other hand, I question whether the extra overhead is a real issue in 2018. I have old-school reflexes about this myself, but even embedded systems are shipping with a lot more RAM than they used to. Unless variable instances are being spawned by the tens of thousands it's hard to imagine this being a real problem. And how likely is that on a resource-constrained system? I actually did think about repacking the struct (see: old-school reflexes) but decided not to in order to avoid compromising the readability by separating the two elements that seem to be in all variants. Also to make the patch itself easy to understand. > 2. Is it reasonable to have more than 255 variables in a single > registration, or should the reporter just split up his registration into > multiple groups, each with less than 255 variables? That I have no opinion on. My domain knowledge of SNMP and its usage is very limited. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Unstable tests
Bill Fenner : > The configure script test can fail if you've regenerated it using autoconf > but not using 2.68. Running 2.69. I never ran autoconf explicitly, just configure as per instructions. > By "test 31" do you mean "snmpv1 traps are sent by snmpd API"? Now I'm getting a different result, which is a little disturbing in itself: com2sec directive (Wstat: 256 Tests: 31 Failed: 1) Failed test: 30 Non-zero exit status: 1 Files=76, Tests=327, 109 wallclock secs ( 0.28 usr 0.07 sys + 13.58 cusr 4.74 csys = 18.67 CPU) Result: FAIL We failed these 1 tests: com2sec directive ( /home/esr/software/net-snmp-code/testing/fulltests/default/T070com2sec_simple ) > What branch did you use to run your tests? master -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: Fix patch for SF bug 2833
I don't think the patch is the issue. There are two questions to be addressed first: 1. For the embedded environment, is it acceptable to use an extra several bytes for this (or is there a way to rearrange the struct so that padding reduces the extra cost)? 2. Is it reasonable to have more than 255 variables in a single registration, or should the reporter just split up his registration into multiple groups, each with less than 255 variables? Bill On Wed, Mar 21, 2018 at 10:43 PM, Eric S. Raymond wrote: > From 54e79ba66327bdb54f97f457d76531f657ec546d Mon Sep 17 00:00:00 2001 > From: "Eric S. Raymond" > Date: Wed, 21 Mar 2018 22:22:29 -0400 > Subject: [PATCH] include/net-snmp/agent/{snmp_vars.h,var_struct.h}: > address SF > bug 2833. > > Tests pass, > --- > include/net-snmp/agent/snmp_vars.h | 2 +- > include/net-snmp/agent/var_struct.h | 12 ++-- > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/include/net-snmp/agent/snmp_vars.h > b/include/net-snmp/agent/snmp_vars.h > index bd27eeb..b2f2f8f 100644 > --- a/include/net-snmp/agent/snmp_vars.h > +++ b/include/net-snmp/agent/snmp_vars.h > @@ -101,7 +101,7 @@ PERFORMANCE OF THIS SOFTWARE. > #define INST 0x /* used to fill out the instance field of > the variables table */ > > struct variable { > -u_char magic; /* passed to function as a hint */ > +u_short magic; /* passed to function as a hint */ > chartype; /* type of variable */ > /* > * See important comment in snmp_vars.c relating to acl > diff --git a/include/net-snmp/agent/var_struct.h > b/include/net-snmp/agent/var_struct.h > index 15b5770..10bf4ae 100644 > --- a/include/net-snmp/agent/var_struct.h > +++ b/include/net-snmp/agent/var_struct.h > @@ -52,7 +52,7 @@ typedef struct netsnmp_subtree_s { > * application. The first 5 elements of the structure must remain > constant. > */ > struct variable1 { > -u_char magic; /* passed to function as a hint */ > +u_short magic; /* passed to function as a hint */ > u_char type; /* type of variable */ > u_short acl;/* access control list for variable */ > FindVarMethod *findVar;/* function that finds variable */ > @@ -61,7 +61,7 @@ struct variable1 { > }; > > struct variable2 { > -u_char magic; /* passed to function as a hint */ > +u_short magic; /* passed to function as a hint */ > u_char type; /* type of variable */ > u_short acl;/* access control list for variable */ > FindVarMethod *findVar;/* function that finds variable */ > @@ -79,7 +79,7 @@ struct variable3 { > }; > > struct variable4 { > -u_char magic; /* passed to function as a hint */ > +u_short magic; /* passed to function as a hint */ > u_char type; /* type of variable */ > u_short acl;/* access control list for variable */ > FindVarMethod *findVar;/* function that finds variable */ > @@ -88,7 +88,7 @@ struct variable4 { > }; > > struct variable7 { > -u_char magic; /* passed to function as a hint */ > +u_short magic; /* passed to function as a hint */ > u_char type; /* type of variable */ > u_short acl;/* access control list for variable */ > FindVarMethod *findVar;/* function that finds variable */ > @@ -97,7 +97,7 @@ struct variable7 { > }; > > struct variable8 { > -u_char magic; /* passed to function as a hint */ > +u_short magic; /* passed to function as a hint */ > u_char type; /* type of variable */ > u_short acl;/* access control list for variable */ > FindVarMethod *findVar;/* function that finds variable */ > @@ -106,7 +106,7 @@ struct variable8 { > }; > > struct variable13 { > -u_char magic; /* passed to function as a hint */ > +u_short magic; /* passed to function as a hint */ > u_char type; /* type of variable */ > u_short acl;/* access control list for variable */ > FindVarMethod *findVar;/* function that finds variable */ > -- > 2.7.4 > > > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > As war and government prove, insanity is the most contagious of > diseases. -- Edward Abbey > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Net-snmp-coders mailing list > Net-snmp-coders@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders >
Re: Unstable tests
I have an unofficial Travis build setup; in it the only tests that fail are because the Travis environment seems to not have even localhost IPv6 available: https://travis-ci.org/fenner/net-snmp The configure script test can fail if you've regenerated it using autoconf but not using 2.68. By "test 31" do you mean "snmpv1 traps are sent by snmpd API"? What branch did you use to run your tests? Bill On Wed, Mar 21, 2018 at 11:41 PM, Eric S. Raymond wrote: > Ian and I note that the test suite seems a bit compromised. > > On current Ubuntu, Intel x86_64, stock build, two tests - 1 and 31 > fail out of the box. > > We see those same failures on ARM (a RasPi 3). > > But Ian's laptop gives a diffeent and larger list of errors. > > Are there known pastform dependencies in the tests? Is it known that > 1 and 31 can fail on a stock build? > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > All forms of government are pernicious, including good government. > -- Edward Abbey > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Net-snmp-coders mailing list > Net-snmp-coders@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders