Re: 5.8 testing status

[Bill Fenner]

On Thu, Apr 26, 2018 at 10:00 PM, Bill Fenner  wrote:

> On Thu, Apr 26, 2018 at 10:02 AM, Bart Van Assche 
> wrote:
>
>> On 04/26/18 04:57, Bill Fenner wrote:
>>
>>> A new feature went into 5.8 that conflicts a little with using an agentx
>>> subagent.  I mentioned this here:
>>> https://sourceforge.net/p/net-snmp/mailman/message/36270409/
>>> You can replicate it by configuring a normal snmpd as an agentx master,
>>> and then running:
>>>
>>>
>>> $ sudo snmpd -C -f -Le -x /var/run/agentx/master -X
>>> *unknown snmp version 193*
>>> NET-SNMP version 5.8.pre2 AgentX subagent connected
>>> NET-SNMP version 5.8.pre2
>>>
>>> The "unknown snmp version" message may just be noise, but may cause
>>> traps from AgentX subagents to not be delivered depending on the net-snmp
>>> library configuration (in my configuration it's fine. I haven't actually
>>> tried a standard configuration).
>>>
>>> (The context is that the library now tries to suppress converting traps
>>> from v1 to v2 or vice versa if there is no trap sink of the right type,
>>> but, it does not know how to treat agentx sessions so doesn't count them -
>>> so if there's only an agentx session open it may not send *any* traps since
>>> it "knows" there are no v1 or v2 trap sessions open)
>>>
>>
>> Hello Bill,
>>
>> Which commit are you referring to? Three regression tests that passed in
>> the past and that send a trap over an AgentX session fail on some test
>> setups.
>>
>
> The commit in question is f770e0f7493204f184c468a7c4dba31f0cd6fc5d .  I
> think it'll cause traps sent from a subagent to fail if you have
> snmpNotifyTable included, meaning that traps get sent via callback, and
> will work otherwise.
>

It's plausible that a workaround as simple as

*--- a/agent/mibgroup/agentx/subagent.c*

*+++ b/agent/mibgroup/agentx/subagent.c*

@@ -901,8 +901,11 @@ subagent_open_master_session(void)

  */

 main_session->securityModel = SNMP_DEFAULT_SECMODEL;



+/*

+ * We lie about being SNMPv3, because ...

+ */

 if (add_trap_session(main_session, AGENTX_MSG_NOTIFY, 1,

- AGENTX_VERSION_1)) {

+ SNMP_VERSION_3)) {

 DEBUGMSGTL(("agentx/subagent", " trap session registered OK\n"));

 } else {

 DEBUGMSGTL(("agentx/subagent",

would work.  (I picked V3 because you can't disable it, unlike v2c.)  I
also didn't feel like writing the rest of the comment :-)

  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: 5.8 testing status

[Bill Fenner]

On Thu, Apr 26, 2018 at 10:02 AM, Bart Van Assche 
wrote:

> On 04/26/18 04:57, Bill Fenner wrote:
>
>> A new feature went into 5.8 that conflicts a little with using an agentx
>> subagent.  I mentioned this here:
>> https://sourceforge.net/p/net-snmp/mailman/message/36270409/
>> You can replicate it by configuring a normal snmpd as an agentx master,
>> and then running:
>>
>>
>> $ sudo snmpd -C -f -Le -x /var/run/agentx/master -X
>> *unknown snmp version 193*
>> NET-SNMP version 5.8.pre2 AgentX subagent connected
>> NET-SNMP version 5.8.pre2
>>
>> The "unknown snmp version" message may just be noise, but may cause traps
>> from AgentX subagents to not be delivered depending on the net-snmp library
>> configuration (in my configuration it's fine. I haven't actually tried a
>> standard configuration).
>>
>> (The context is that the library now tries to suppress converting traps
>> from v1 to v2 or vice versa if there is no trap sink of the right type,
>> but, it does not know how to treat agentx sessions so doesn't count them -
>> so if there's only an agentx session open it may not send *any* traps since
>> it "knows" there are no v1 or v2 trap sessions open)
>>
>
> Hello Bill,
>
> Which commit are you referring to? Three regression tests that passed in
> the past and that send a trap over an AgentX session fail on some test
> setups.
>

The commit in question is f770e0f7493204f184c468a7c4dba31f0cd6fc5d .  I
think it'll cause traps sent from a subagent to fail if you have
snmpNotifyTable included, meaning that traps get sent via callback, and
will work otherwise.

  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: DISMAN PING MIB test case question

[Bill Fenner]

I do not think the DISMAN PING module builds anywhere but Linux.  I am not
a fan of the existing implementation since it is synchronous.

(I have a from-scratch asynchronous rewrite sitting around languishing that
I haven't tested anywhere but Linux; raw sockets are pretty notoriously
incompatible across OSes.  It needs a bit of cleanup and support for
sending/receiving IPv6 packets...)

  Bill


On Thu, Apr 26, 2018 at 2:01 PM, Keith Mendoza  wrote:

> I have a question about what permissions DISMAN PING MIB test case
> expects. I'm running on a macOS 12.3.4 with --enable-blumenthal-aes
> --with-openssl= --with-defaults. When I
> run make test as my normal user I get "skipped: Not permitted to create raw
> sockets". However, when I run make test using "sudo make test" I instead
> get "skipped: USING_DISMAN_PING_MIB_MODULE is not defined". Should I be
> running "make test" as root?
>
> --
> Thanks,
> Keith (pantherse)
>
> 
> --
> 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: DISMAN PING MIB test case question

[Bart Van Assche]

On 04/26/18 11:01, Keith Mendoza wrote:

I have a question about what permissions DISMAN PING MIB test case
expects. I'm running on a macOS 12.3.4 with --enable-blumenthal-aes
--with-openssl= --with-defaults.
When I run make test as my normal user I get "skipped: Not permitted
to create raw sockets". However, when I run make test using "sudo
make test" I instead get "skipped: USING_DISMAN_PING_MIB_MODULE is
not defined". Should I be running "make test" as root?

 Hello Keith,

Have you tried to add --with-mib-modules=disman/ping-mib to the Net-SNMP 
configure script argument list?


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

DISMAN PING MIB test case question

[Keith Mendoza]

I have a question about what permissions DISMAN PING MIB test case expects. I'm 
running on a macOS 12.3.4 with --enable-blumenthal-aes --with-openssl= --with-defaults. When I run make test as my normal 
user I get "skipped: Not permitted to create raw sockets". However, when I run 
make test using "sudo make test" I instead get "skipped: 
USING_DISMAN_PING_MIB_MODULE is not defined". Should I be running "make test" 
as root?

-- 
Thanks,
Keith (pantherse)

--
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: 5.8 testing status

[Bart Van Assche]

On 04/26/18 04:57, Bill Fenner wrote:
A new feature went into 5.8 that conflicts a little with using an agentx 
subagent.  I mentioned this here:

https://sourceforge.net/p/net-snmp/mailman/message/36270409/
You can replicate it by configuring a normal snmpd as an agentx master, 
and then running:



$ sudo snmpd -C -f -Le -x /var/run/agentx/master -X
*unknown snmp version 193*
NET-SNMP version 5.8.pre2 AgentX subagent connected
NET-SNMP version 5.8.pre2

The "unknown snmp version" message may just be noise, but may cause 
traps from AgentX subagents to not be delivered depending on the 
net-snmp library configuration (in my configuration it's fine. I haven't 
actually tried a standard configuration).


(The context is that the library now tries to suppress converting traps 
from v1 to v2 or vice versa if there is no trap sink of the right type, 
but, it does not know how to treat agentx sessions so doesn't count them 
- so if there's only an agentx session open it may not send *any* traps 
since it "knows" there are no v1 or v2 trap sessions open)


Hello Bill,

Which commit are you referring to? Three regression tests that passed in 
the past and that send a trap over an AgentX session fail on some test 
setups.


Thanks,

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: 5.8 testing status

[Bill Fenner]

On Wed, Apr 25, 2018 at 5:14 PM, Keith Mendoza  wrote:

> Just want to see where everyone is regarding 5.8 release. Other than
> what's listed in the 5.8pre2 announcement are there any other features that
> will go into 5.8?
>
> Other that the bugs I filed last week from running the test suite against
> master branch, are there any bugs that are part of 5.8?
>

A new feature went into 5.8 that conflicts a little with using an agentx
subagent.  I mentioned this here:
https://sourceforge.net/p/net-snmp/mailman/message/36270409/
You can replicate it by configuring a normal snmpd as an agentx master, and
then running:


$ sudo snmpd -C -f -Le -x /var/run/agentx/master -X
*unknown snmp version 193*
NET-SNMP version 5.8.pre2 AgentX subagent connected
NET-SNMP version 5.8.pre2

The "unknown snmp version" message may just be noise, but may cause traps
from AgentX subagents to not be delivered depending on the net-snmp library
configuration (in my configuration it's fine. I haven't actually tried a
standard configuration).

(The context is that the library now tries to suppress converting traps
from v1 to v2 or vice versa if there is no trap sink of the right type,
but, it does not know how to treat agentx sessions so doesn't count them -
so if there's only an agentx session open it may not send *any* traps since
it "knows" there are no v1 or v2 trap sessions open)

Do we need to do a 5.8pre3? If so, when is that expected?
>

I think Robert is proposing pre3 tomorrow, and rc1 5/4.

  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 RFC] Add Travis and Appveyor CI support

[Bill Fenner]

Hi Bart,

Also check out my travis config - configuring with different sets of
configure args - minimalist is important to me, so it's nice to have
regression testing against, and we had a couple of interesting bugs
reported agaist --disable-set-support and --enable-read-only, so I added
them.  Obviously your method with the script is better than mine with the
horrorshow long line in the travis config.

https://raw.githubusercontent.com/fenner/net-snmp/master-travis/.travis.yml

I got it working with "sudo:false" but obviously v6 doesn't work, I'm happy
to see us use the "sudo:true" infrastructure to get v6.

  Bill


On Wed, Apr 25, 2018 at 11:06 AM, Bart Van Assche 
wrote:

> Hello,
>
> One of the advantages of github over SourceForge is that integration with
> continuous integration (CI) services like Travis and Appveyor is easy.
> Adding such support however requires to add proper configuration files and
> the necessary scripts in the source tree. Hence this patch. As one can see
> for Linux all regression tests are run, for OS/X some regression tests are
> run and for MSVC and Cygwin no regression tests are run. All four builds
> pass with this patch. As usual, feedback is welcome.
>
> Bart.
>
>
> ---
>  .appveyor.yml  |  10 +
>  .travis.yml|  35 
>  ci/build.bat   |  30 +++
>  ci/build.sh|  17 ++
>  ci/net-snmp-configure  | 211 +
>  ci/net-snmp-run-perl-tests |   9 +
>  ci/net-snmp-run-python-tests   |  16 ++
>  ci/net-snmp-run-tests  |  37 
>  .../fulltests/default/T200snmpv2cwalkall_simple|   2 +
>  testing/fulltests/support/simple_eval_tools.sh |  21 +-
>  10 files changed, 381 insertions(+), 7 deletions(-)
>  create mode 100644 .appveyor.yml
>  create mode 100644 .travis.yml
>  create mode 100644 ci/build.bat
>  create mode 100755 ci/build.sh
>  create mode 100755 ci/net-snmp-configure
>  create mode 100755 ci/net-snmp-run-perl-tests
>  create mode 100755 ci/net-snmp-run-python-tests
>  create mode 100755 ci/net-snmp-run-tests
>
> diff --git a/.appveyor.yml b/.appveyor.yml
> new file mode 100644
> index ..137c52052d34
> --- /dev/null
> +++ b/.appveyor.yml
> @@ -0,0 +1,10 @@
> +image:
> +  - Visual Studio 2017
> +environment:
> +  matrix:
> +- BUILD: MSVC
> +# - BUILD: MinGW
> +- BUILD: Cygwin
> +clone_depth: 5
> +build_script:
> +  - 'call "ci\build.bat"'
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index ..7262aa19aab0
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,35 @@
> +language: c
> +
> +os:
> +  - linux
> +  - osx
> +
> +dist: trusty
> +
> +sudo: required
> +
> +addons:
> +  apt:
> +packages:
> +  - dpkg
> +  - gcc
> +  - libatm-dev
> +  - libperl-dev
> +  - libsensors4-dev
> +  - libssh-dev
> +  - libssl-dev
> +  - make
> +  - perl-modules
> +  - pkg-config
> +  - python-dev
> +  - python-setuptools
> +
> +# Add an IPv6 config - see the corresponding Travis issue
> +# https://github.com/travis-ci/travis-ci/issues/8361
> +before_script:
> +  - if [ "${TRAVIS_OS_NAME}" == "linux" ]; then
> +  sudo sh -c 'echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6;
> printf "\n::1 localhost ipv6-localhost ipv6-loopback\n" >>/etc/hosts; cat
> /etc/hosts';
> +fi
> +  - 'if [ "${TRAVIS_OS_NAME}" == "osx" ]; then brew upgrade openssl
> >/dev/null 2>&1; fi'
> +
> +script: ci/build.sh
> diff --git a/ci/build.bat b/ci/build.bat
> new file mode 100644
> index ..cea6a89a4886
> --- /dev/null
> +++ b/ci/build.bat
> @@ -0,0 +1,30 @@
> +echo "Build type %BUILD%"
> +@echo on
> +goto %BUILD%
> +echo "Error: unknown build type %BUILD%"
> +goto eof
> +
> +:MSVC
> +REM see also https://www.appveyor.com/docs/lang/cpp/
> +REM if exist "C:\Program Files (x86)\Microsoft Visual Studio\2017" (
> +REM   set "d=C:\Program Files (x86)\Microsoft Visual Studio\2017"
> +REM ) else if exist "C:\Program Files\Microsoft Visual Studio\2017" (
> +REM   set "d=C:\Program Files\Microsoft Visual Studio\2017"
> +REM )
> +REM cmd /c ""%d%"\Community\VC\Auxiliary\Build\vcvarsall.bat x86"
> +REM install:
> +call "C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\vcvarsall.bat"
> +cd win32
> +perl Configure --config=release --with-sdk --with-ipv6 --with-winextdll
> --linktype=dynamic
> +nmake
> +goto eof
> +
> +:MinGW
> +C:\msys64\usr\bin\bash --login -c 'set -x; cd "${APPVEYOR_BUILD_FOLDER}";
> ci/build.sh'
> +goto eof
> +
> +:Cygwin
> +c:\cygwin\bin\bash --login -c 'set -x; cd "${APPVEYOR_BUILD_FOLDER}";
> ci/build.sh'
> +goto eof
> +
> +:eof
> diff --git a/ci/build.sh b/ci/build.sh
> new file mode 100755
> index ..3e306d82bf17
> --- /dev/null
> +++ b/ci/build.sh
> @@ -0,0 +1,17 @@
> +#!/bin/bash
>