net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

New release of net-snmp

[Hugh M. <hug...@ou...>]

Hi all,

There has been a lot of good work since the previous release of
net-snmp 13 months ago.

Is there an estimate or release target for a new version?

--
Hugh McMaster

Re: Regarding snmpv3 inform packet

[Pushpa T. <pus...@gm...>]

Hi Bill Fenner,

Thanks a lot. I am very grateful to the portal for keeping us more
knowledgeable and interest on snmp alive.

Regards,
Pushpa.T

On Tue, Aug 27, 2019 at 7:20 PM Bill Fenner <fe...@gm...> wrote:

> On Fri, Aug 23, 2019 at 12:19 PM Pushpa Thimmaiah <
> pus...@gm...> wrote:
>
>> Hi All,
>>
>> I would like to understand messages exchanged between manager and agent
>> during snmpv3-inform.
>> Following is my understanding
>> Msg1. Agent to manager : Request for engineID
>> Msg2. Manager to Agent : Response with engineID
>> Msg3. Agent to Manager :  Send snmpv3 trap to manager
>> Msg4. Manager to Agent :  Send ACK to agent on authenticating and
>> receiving snmpv3 trap
>>
>> *Query:*
>> Varbinds in Message #3 and #4  are same. Varbinds of
>> Message#3(informRequest) is trap, but why manager sends same varbinds back
>> to Agent in Message#4 (get-response)
>>
>
> See section 4.2.7 of RFC3416:
> https://tools.ietf.org/html/rfc3416#section-4.2.7
>
>    Upon receipt of an InformRequest-PDU, the receiving SNMP entity
>    determines the size of a message encapsulating a Response-PDU with
>    the same values in its request-id, error-status, error-index and
>    variable-bindings fields as the received InformRequest-PDU.
>
>
> Presumably the intent of including the varbinds in the response is to
> allow the originator of the inform to ensure that the complete message was
> received, if it cares to do that much validation.
>
>   Bill
>
>

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

[Bill F. <fe...@us...>]

On Tue, Aug 27, 2019 at 11:11 PM Bart Van Assche <bva...@ac...> wrote:

> 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
>
> It seems like the recent changes are sufficient to make the minimalist
> build pass?
>
> Hi Bart,

Yes, I addressed the problems in minimalist with
https://github.com/net-snmp/net-snmp/commit/37e498fdcde98ee93875a750dbcd5a8a9ba336b1
and the problems in read-only with
https://github.com/net-snmp/net-snmp/commit/904aefa5a241473f2075e60147a307b2250a4853
.  Travis should be back to keeping us on our toes.

  Bill

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

[Bart V. A. <bva...@ac...>]

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 recent changes are sufficient to make the minimalist 
build pass?

Bart.

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

[Bart V. A. <bva...@ac...>]

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 traps.
>    Note that this directive must be used prior to any community-based
>    trap destination directives that need to use it.
> --.IP "trapsink [-profile p] [-name n] [-tag t] HOST [COMMUNITY [PORT]]"
> --.IP "trap2sink [-profile p] [-name n] [-tag t] HOST [COMMUNITY [PORT]]"
> --.IP "informsink [-profile p] [-name n] [-tag t] HOST [COMMUNITY [PORT]]"
> ++.IP "trapsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]"
> ++.IP "trap2sink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]"
> ++.IP "informsink [-profile p] [-name n] [-tag t] [-s src] HOST [COMMUNITY [PORT]]"
>    define the address of a notification receiver that should be sent
>    SNMPv1 TRAPs, SNMPv2c TRAP2s, or SNMPv2 INFORM notifications respectively.
>    See the section
> @@@ -880,6 -880,6 +880,16 @@@ be used for SNMP-NOTIFICATION-MIB tabl
>    which notification filter profile entry will be used for filtering
>    outgoing notifications. (See \fInotificationFilter\fR)
>    .IP
> ++The optional src parameter specifies the source address that will
> ++be used when sending the trap packet to this sink.
> ++It is specified as a <transport-address>, using the same
> ++<transport-specifier> as the destination HOST.
> ++See the section
> ++.B LISTENING ADDRESSES
> ++in the
> ++.I snmpd(8)
> ++manual page for more information about the format.
> ++.IP
>    If several sink directives are specified, multiple
>    copies of each notification (in the appropriate formats)
>    will be generated.
> @@@ -888,7 -888,7 +898,7 @@@
>    It is \fBnot\fR normally appropriate to list two (or all three)
>    sink directives with the same destination.
>    .RE
> --.IP "trapsess [-profile p] [-name n] [-tag t] [SNMPCMD_ARGS] HOST"
> ++.IP "trapsess [-profile p] [-name n] [-tag t] [-s src] [SNMPCMD_ARGS] HOST"
>    provides a more generic mechanism for defining notification destinations.
>    .I "SNMPCMD_ARGS"
>    should be the command-line options required for an equivalent

This looks good to me.

Thanks,

Bart.

Re: Regarding snmpv3 inform packet

[Bill F. <fe...@gm...>]

On Fri, Aug 23, 2019 at 12:19 PM Pushpa Thimmaiah <
pus...@gm...> wrote:

> Hi All,
>
> I would like to understand messages exchanged between manager and agent
> during snmpv3-inform.
> Following is my understanding
> Msg1. Agent to manager : Request for engineID
> Msg2. Manager to Agent : Response with engineID
> Msg3. Agent to Manager :  Send snmpv3 trap to manager
> Msg4. Manager to Agent :  Send ACK to agent on authenticating and
> receiving snmpv3 trap
>
> *Query:*
> Varbinds in Message #3 and #4  are same. Varbinds of
> Message#3(informRequest) is trap, but why manager sends same varbinds back
> to Agent in Message#4 (get-response)
>

See section 4.2.7 of RFC3416:
https://tools.ietf.org/html/rfc3416#section-4.2.7

   Upon receipt of an InformRequest-PDU, the receiving SNMP entity
   determines the size of a message encapsulating a Response-PDU with
   the same values in its request-id, error-status, error-index and
   variable-bindings fields as the received InformRequest-PDU.


Presumably the intent of including the varbinds in the response is to allow
the originator of the inform to ensure that the complete message was
received, if it cares to do that much validation.

  Bill

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

[Bill F. <fe...@gm...>]

On Mon, Aug 26, 2019 at 9:51 PM Bart Van Assche <bva...@ac...> wrote:

> 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?
>
> Sure, I thought the formatted version might be easier to read.

  Bill

Re: MAC Address As Index

[Krishna C. <cha...@gm...>]

On Mon, Aug 26, 2019 at 9:22 PM Bill Fenner <fe...@gm...> wrote:
>
> On Tue, Aug 20, 2019 at 8:45 AM Krishna Chaitanya <cha...@gm...> wrote:
>>
>> Hi,
>>
>> When using MAC Address as an index ( I am using MacAddress type from
>> SNMPv2-TC.) the output is incorrect because the length of the string
>> is prefixed as mac address is defined as OCTET STR there is an extra
>> byte and the last byte of mac address is interpreted as next OID.
>>
>> snmpwalk:
>>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
>> snmpwalk -OX
>>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
>>
>> In the above examples last but one OID 2 is hist_2. Is there a way to
>> disable prefixing of length?
>
>
> The prefixing of length is done by the agent.  Are you asking about a MIB module that you implemented?  Try changing your object definition from ASN_OCTET_STR to ASN_PRIV_IMPLIED_OCTET_STR.
Yes, I am using my own MIB and changing to ASN_PRIV_IMPLIED_OCTET_STR
in the subagent worked.
Thanks, Bill.

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

[Bart V. A. <bva...@ac...>]

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 patches that are in our repository but not yet in the 
official repository I can have a look at why the minimalist build fails.

Bart.

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

[Bart V. A. <bva...@ac...>]

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.

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

[Bill F. <fe...@us...>]

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

  Bill

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

[Bill F. <fe...@us...>]

On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner <fe...@us...>
wrote:

> On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
> no...@co...> wrote:
>
>> Branch: V5-8-patches
>>
>> treewide: Terminate netsnmp_feature_*() uses with a semicolon
>>
>> This patch has been generated by the following shell command:
>>
>> git grep -l netsnmp_feature_ |
>> while read f; do sed -i 's/^netsnmp_feature.*[^;]$/&;/' "$f"; done
>>
>> By Bart Van Assche on 08/14/2019 02:58
>>
>
> Hi Bart,
>
> Thank you very much for all the cleanups you've been working on recently.
> I really appreciate it.
>
> Have you tried using features with this change?  I am getting errors like:
>
> [net-snmp] In file included from
> *../include/net-snmp/net-snmp-features.h:11:0*,
>
> [net-snmp]                  from *snmp_client.c:48*:
>
> [net-snmp] *../include/net-snmp/agent/features.h:4:39:* *error: *ISO C99
> requires whitespace after the macro name [*-Werror*]
>
> [net-snmp]  #define NETSNMP_FEATURE_HAS_BABY_STEPS*;* 1
>
> [net-snmp]                                        *^*
>
> which appear likely to be due to the feature calculation infrastructure
> not understanding these semicolons.  The semicolon seems to be making it
> into the .ft file for *some* macros but not others:
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_*BABY_STEPS*;
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_*BABY_STEPS*_CHILD_OF_MIB_HELPERS;
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_*BABY_STEPS*
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_NETSNMP_*BABY_STEPS*_HANDLER_INIT_CHILD_OF_NETSNMP_UNUSED;
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_NETSNMP_
> *BABY_STEPS*_HANDLER_INIT 1
>
> I'm happy to dig into this, but wanted to see if you had seen it already.
> (Not asking for a revert; let's move this forward together)
>
> It occurs to me that another thing that would be useful to dig into: why
did the Travis minimalist build not have similar problems? I'll start
exploring this too.

  Bill

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

[Bill F. <fe...@us...>]

On Mon, Aug 26, 2019 at 4:51 PM Bart Van Assche <bva...@ac...> wrote:

> 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 available, is awk?
>
> Hi Bill,
>
> The number of platforms supported by Net-SNMP is large. Each of these
> platforms comes with its own version of grep, sed and awk. Cygwin, MinGW
> and MinGW64 include GNU versions of grep, sed and awk so these platforms
> are not my biggest worry. I'm more worried about *BSD, Solaris and AIX.
> So my preference here is to be conservative and keep the changes as
> small as possible.
>

awk was available a surprisingly long time ago ("The AWK Programming
Language" was published in 1988), but you're right that less churn is
probably safer.

  Bill

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

[Bart V. A. <bva...@ac...>]

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 available, is awk?

Hi Bill,

The number of platforms supported by Net-SNMP is large. Each of these
platforms comes with its own version of grep, sed and awk. Cygwin, MinGW
and MinGW64 include GNU versions of grep, sed and awk so these platforms
are not my biggest worry. I'm more worried about *BSD, Solaris and AIX.
So my preference here is to be conservative and keep the changes as
small as possible.

Thanks,

Bart.

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

[Bill F. <fe...@us...>]

On Mon, Aug 26, 2019 at 12:34 PM Bill Fenner <fe...@us...>
wrote:

> On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner <fe...@us...>
> wrote:
>
>> On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
>> no...@co...> wrote:
>>
>>> Branch: V5-8-patches
>>>
>>> treewide: Terminate netsnmp_feature_*() uses with a semicolon
>>>
>>> This patch has been generated by the following shell command:
>>>
>>> git grep -l netsnmp_feature_ |
>>> while read f; do sed -i 's/^netsnmp_feature.*[^;]$/&;/' "$f"; done
>>>
>>> By Bart Van Assche on 08/14/2019 02:58
>>>
>>
>> Hi Bart,
>>
>> Thank you very much for all the cleanups you've been working on
>> recently.  I really appreciate it.
>>
>> Have you tried using features with this change?  I am getting errors like:
>>
>> [net-snmp] In file included from
>> *../include/net-snmp/net-snmp-features.h:11:0*,
>>
>> [net-snmp]                  from *snmp_client.c:48*:
>>
>> [net-snmp] *../include/net-snmp/agent/features.h:4:39:* *error: *ISO C99
>> requires whitespace after the macro name [*-Werror*]
>>
>> [net-snmp]  #define NETSNMP_FEATURE_HAS_BABY_STEPS*;* 1
>>
>> [net-snmp]                                        *^*
>>
>> which appear likely to be due to the feature calculation infrastructure
>> not understanding these semicolons.  The semicolon seems to be making it
>> into the .ft file for *some* macros but not others:
>>
>> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_
>> *BABY_STEPS*; 1
>>
>> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_*BABY_STEPS*_CHILD_OF_MIB_HELPERS;
>> 1
>>
>> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_
>> *BABY_STEPS* 1
>>
>> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_NETSNMP_
>> *BABY_STEPS*_HANDLER_INIT_CHILD_OF_NETSNMP_UNUSED; 1
>>
>> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_NETSNMP_
>> *BABY_STEPS*_HANDLER_INIT 1
>>
>> I'm happy to dig into this, but wanted to see if you had seen it
>> already.  (Not asking for a revert; let's move this forward together)
>>
>> Looks like these diffs in local/minimalist/feature-check fix it:
>
> -for i in `grep NSF_RR $tmpf | sed 's/ NSF_RR//'` ; do
>
> +for i in `grep NSF_RR $tmpf | sed 's/ NSF_RR;//'` ; do
>
> -for i in `grep NSF_PP $tmpf | sed 's/ NSF_PP//'` ; do
>
> +for i in `grep NSF_PP $tmpf | sed 's/ NSF_PP;//'` ; do
>
> -for i in `grep NSF_CO $tmpf | sed 's/ NSF_CO//'` ; do
>
> +for i in `grep NSF_CO $tmpf | sed 's/ NSF_CO;//'` ; do
>
> -for i in `grep NSF_WW $tmpf | sed 's/ NSF_WW//'` ; do
>
> +for i in `grep NSF_WW $tmpf | sed 's/ NSF_WW;//'` ; do
>
> I'll do some more testing and check it in.
>

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 available, is awk?

Thanks,
  Bill

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

[Bill F. <fe...@us...>]

On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner <fe...@us...>
wrote:

> On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
> no...@co...> wrote:
>
>> Branch: V5-8-patches
>>
>> treewide: Terminate netsnmp_feature_*() uses with a semicolon
>>
>> This patch has been generated by the following shell command:
>>
>> git grep -l netsnmp_feature_ |
>> while read f; do sed -i 's/^netsnmp_feature.*[^;]$/&;/' "$f"; done
>>
>> By Bart Van Assche on 08/14/2019 02:58
>>
>
> Hi Bart,
>
> Thank you very much for all the cleanups you've been working on recently.
> I really appreciate it.
>
> Have you tried using features with this change?  I am getting errors like:
>
> [net-snmp] In file included from
> *../include/net-snmp/net-snmp-features.h:11:0*,
>
> [net-snmp]                  from *snmp_client.c:48*:
>
> [net-snmp] *../include/net-snmp/agent/features.h:4:39:* *error: *ISO C99
> requires whitespace after the macro name [*-Werror*]
>
> [net-snmp]  #define NETSNMP_FEATURE_HAS_BABY_STEPS*;* 1
>
> [net-snmp]                                        *^*
>
> which appear likely to be due to the feature calculation infrastructure
> not understanding these semicolons.  The semicolon seems to be making it
> into the .ft file for *some* macros but not others:
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_*BABY_STEPS*;
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_*BABY_STEPS*_CHILD_OF_MIB_HELPERS;
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_*BABY_STEPS*
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_NETSNMP_*BABY_STEPS*_HANDLER_INIT_CHILD_OF_NETSNMP_UNUSED;
> 1
>
> ./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_NETSNMP_
> *BABY_STEPS*_HANDLER_INIT 1
>
> I'm happy to dig into this, but wanted to see if you had seen it already.
> (Not asking for a revert; let's move this forward together)
>
> Looks like these diffs in local/minimalist/feature-check fix it:

-for i in `grep NSF_RR $tmpf | sed 's/ NSF_RR//'` ; do

+for i in `grep NSF_RR $tmpf | sed 's/ NSF_RR;//'` ; do

-for i in `grep NSF_PP $tmpf | sed 's/ NSF_PP//'` ; do

+for i in `grep NSF_PP $tmpf | sed 's/ NSF_PP;//'` ; do

-for i in `grep NSF_CO $tmpf | sed 's/ NSF_CO//'` ; do

+for i in `grep NSF_CO $tmpf | sed 's/ NSF_CO;//'` ; do

-for i in `grep NSF_WW $tmpf | sed 's/ NSF_WW//'` ; do

+for i in `grep NSF_WW $tmpf | sed 's/ NSF_WW;//'` ; do

I'll do some more testing and check it in.

  Bill

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

[Bill F. <fe...@gm...>]

Here's my proposed documentation:

       trapsink  [-profile  p]  [-name  n]  [-tag  t] [-s src] HOST
[COMMUNITY

       [PORT]]


       trap2sink [-profile p] [-name n] [-tag  t]  [-s  src]  HOST
[COMMUNITY

       [PORT]]


       informsink  [-profile  p]  [-name  n] [-tag t] [-s src] HOST
[COMMUNITY

       [PORT]]

              define the address of a notification  receiver  that  should
be

              sent  SNMPv1  TRAPs,  SNMPv2c TRAP2s, or SNMPv2 INFORM
notifica-

              tions respectively.  See the section *LISTENING ADDRESSES *in
the

              snmpd(8)  manual  page  for more information about the format
of

              listening addresses.  If COMMUNITY is not  specified,  the
most

              recent trapcommunity string will be used.


              If the transport address does not include an explicit port
spec-

              ification, then PORT will be used.  If this  is  not
specified,

              the well known SNMP trap port (162) will be used.


              Note:  This  mechanism  is  being  deprecated, and the
listening

                     port should be specified via the transport
specification

                     HOST instead.


              The  optional  name and tag parameters specifies the name or
tag

              that will be used for SNMP-NOTIFICATION-MIB table  entries.
The

              profile  specifies  which notification filter profile entry
will

              be used for filtering outgoing notifications. (See
notification-

              Filter)


              The  optional  src  parameter  specifies the source address
that

              will be used when sending the trap packet to this sink.   It
is

              specified  as  a <transport-address>, using the same
<transport-

              specifier> as the destination HOST.  See the  section
*LISTENING*

              *ADDRESSES *in the snmpd(8) manual page for more information
about

              the format.


              If several sink directives are  specified,  multiple  copies
of

              each  notification  (in  the appropriate formats) will be
gener-

              ated.


              Note:  It is *not *normally appropriate to list two (or all
three)

                     sink directives with the same destination.


       trapsess [-profile p] [-name n] [-tag t] [-s src] [SNMPCMD_ARGS] HOST

              provides a more generic mechanism for defining notification
des-

              tinations.  SNMPCMD_ARGS  should  be  the  command-line
options
...

- Added [ -s src ] to all of trapsink, trap2sink, informsink, and trapsess

- Added the paragraph about the src parameter.  I duplicated the reference
to the LISTENING ADDRESS from snmpd(8), which also appears a few paragraphs
above, but I think it's worth doing since if you search for "src" you may
gloss over the above reference.

What do you think?

Thanks,
  Bill


On Mon, Aug 26, 2019 at 11:57 AM Bill Fenner <fe...@gm...> wrote:

> Hi Bart,
>
> I'm afraid I deferred to the documentation for
> df26f8f2d51409827a3ce131c1b9de67d01ee6e5 which added "-s" for trapsink.
> (i.e., nowhere.)  I acknowledge that was lazy, and I will write
> documentation for both commits in snmpd.conf.5.def.
>
>   Bill
>
>
> On Fri, Jul 26, 2019 at 9:28 PM Bart Van Assche <bva...@ac...>
> wrote:
>
>> 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.
>>
>

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

[Bill F. <fe...@gm...>]

Hi Bart,

I'm afraid I deferred to the documentation for
df26f8f2d51409827a3ce131c1b9de67d01ee6e5 which added "-s" for trapsink.
(i.e., nowhere.)  I acknowledge that was lazy, and I will write
documentation for both commits in snmpd.conf.5.def.

  Bill


On Fri, Jul 26, 2019 at 9:28 PM Bart Van Assche <bva...@ac...> wrote:

> 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.
>

Re: MAC Address As Index

[Bill F. <fe...@gm...>]

On Tue, Aug 20, 2019 at 8:45 AM Krishna Chaitanya <cha...@gm...>
wrote:

> Hi,
>
> When using MAC Address as an index ( I am using MacAddress type from
> SNMPv2-TC.) the output is incorrect because the length of the string
> is prefixed as mac address is defined as OCTET STR there is an extra
> byte and the last byte of mac address is interpreted as next OID.
>
> snmpwalk:
>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
> snmpwalk -OX
>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
>
> In the above examples last but one OID 2 is hist_2. Is there a way to
> disable prefixing of length?
>

The prefixing of length is done by the agent.  Are you asking about a MIB
module that you implemented?  Try changing your object definition
from ASN_OCTET_STR to ASN_PRIV_IMPLIED_OCTET_STR.

  Bill

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

[Bill F. <fe...@us...>]

On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
no...@co...> wrote:

> Branch: V5-8-patches
>
> treewide: Terminate netsnmp_feature_*() uses with a semicolon
>
> This patch has been generated by the following shell command:
>
> git grep -l netsnmp_feature_ |
> while read f; do sed -i 's/^netsnmp_feature.*[^;]$/&;/' "$f"; done
>
> By Bart Van Assche on 08/14/2019 02:58
>

Hi Bart,

Thank you very much for all the cleanups you've been working on recently.
I really appreciate it.

Have you tried using features with this change?  I am getting errors like:

[net-snmp] In file included from
*../include/net-snmp/net-snmp-features.h:11:0*,

[net-snmp]                  from *snmp_client.c:48*:

[net-snmp] *../include/net-snmp/agent/features.h:4:39:* *error: *ISO C99
requires whitespace after the macro name [*-Werror*]

[net-snmp]  #define NETSNMP_FEATURE_HAS_BABY_STEPS*;* 1

[net-snmp]                                        *^*

which appear likely to be due to the feature calculation infrastructure not
understanding these semicolons.  The semicolon seems to be making it into
the .ft file for *some* macros but not others:

./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_*BABY_STEPS*;
1

./agent/helpers/baby_steps.ft:#define
NETSNMP_FEATURE_*BABY_STEPS*_CHILD_OF_MIB_HELPERS;
1

./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_*BABY_STEPS* 1

./agent/helpers/baby_steps.ft:#define
NETSNMP_FEATURE_NETSNMP_*BABY_STEPS*_HANDLER_INIT_CHILD_OF_NETSNMP_UNUSED;
1

./agent/helpers/baby_steps.ft:#define NETSNMP_FEATURE_PROVIDE_NETSNMP_
*BABY_STEPS*_HANDLER_INIT 1

I'm happy to dig into this, but wanted to see if you had seen it already.
(Not asking for a revert; let's move this forward together)

Thanks,
  Bill

Net-snmp version that supports HMAC-SHA-224 and greater

[Adolf M. (amisquit) <ami...@ci...>]

Hi,

Currently we employ net-snmp-5.7.2. Bit of googling revealed that the SHA implemented by the agent is HMAC-SHA-96.

What version of snmp supports greater HMAC-SHA-256 and greater?

Further, a new user is added with the following step:
createUser testUser SHA "test123" AES

Is there a possibility to configure HMAC-SHA-224/256/384/512 (for the agent) as default and not confine to a given user?


Thanks,
Adolf

Regarding snmpv3 inform packet

[Pushpa T. <pus...@gm...>]

Hi All,

I would like to understand messages exchanged between manager and agent
during snmpv3-inform.
Following is my understanding
Msg1. Agent to manager : Request for engineID
Msg2. Manager to Agent : Response with engineID
Msg3. Agent to Manager :  Send snmpv3 trap to manager
Msg4. Manager to Agent :  Send ACK to agent on authenticating and receiving
snmpv3 trap

*Query:*
Varbinds in Message #3 and #4  are same. Varbinds of
Message#3(informRequest) is trap, but why manager sends same varbinds back
to Agent in Message#4 (get-response)

I used following example
~$ *snmptrap -Ci -v 3 -n "" -a MD5 -A testinginform -l authNoPriv -u testpu
172.168.4.190  69 .1.3.6.1.4.1.8072.2.3.1 .1.3.6.1.4.1.8072.2.1.1 i 22*
read_config_store open failure on /var/lib/snmp/snmpapp.conf
read_config_store open failure on /var/lib/snmp/snmpapp.conf
read_config_store open failure on /var/lib/snmp/snmpapp.conf
~$

Thank you,
Pushpa Thimmaiah

Re: MAC Address As Index

[Niels B. <nb...@us...>]

On Tue, Aug 20, 2019 at 06:14:34PM +0530, Krishna Chaitanya wrote:
> Hi,
> 
> When using MAC Address as an index ( I am using MacAddress type from
> SNMPv2-TC.) the output is incorrect because the length of the string
> is prefixed as mac address is defined as OCTET STR there is an extra
> byte and the last byte of mac address is interpreted as next OID.
> 
> snmpwalk:
>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
> snmpwalk -OX
>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
> 
> In the above examples last but one OID 2 is hist_2. Is there a way to
> disable prefixing of length?

See RFC 2578, clause 7.7. You define your MAC address as an OCTET STRING
(SIZE(6)), then there is no need to prefix the length.

/Niels

-- 
Niels Baggesen - @home - Århus - Denmark - nb...@us...
The purpose of computing is insight, not numbers   ---   R W Hamming

Re: MAC Address As Index

[Krishna C. <cha...@gm...>]

On Tue, Aug 20, 2019 at 6:14 PM Krishna Chaitanya
<cha...@gm...> wrote:
>
> Hi,
>
> When using MAC Address as an index ( I am using MacAddress type from
> SNMPv2-TC.) the output is incorrect because the length of the string
> is prefixed as mac address is defined as OCTET STR there is an extra
> byte and the last byte of mac address is interpreted as next OID.
>
> snmpwalk:
>    HistValue."wlp8s0f0".'....B.'.hist_2.2.19
> snmpwalk -OX
>   HistValue["wlp8s0f0"][STRING: 06:00:90:e6:42:99][hist_2][2].19
>
> In the above examples last but one OID 2 is hist_2. Is there a way to
> disable prefixing of length?
>
Forgot to mention that the same question was asked way back in 2003
 and is still unanswered :-).

https://sourceforge.net/p/net-snmp/mailman/message/14894160/

Re: Re: snmpwalk snmpbulkwalk problems/bug??

[Jose R. F. A. <jr...@gm...>]

Jose Roberto Fernandez Anahia <jrfndes@...> writes:

> I observed that my funcion My_Get_Table(struct variable *vp, oid
> *name, size_t *length, int exact, size_t *var_len, WriteMethod
> **write_method)
> is called much more than 5 (five) 5 times!!!

The upper code doesn't know how many entries you have, so it has to call
you until it gets a "nothing more" answer.  And it also has no notion of
whether or not new data was added to a table since the last time the mib
module was queried, so even if it only counted 4 rows in the walk of the
first column, it will continue to ask for more data in all the rest of
the columns too (it never assumes the data hasn't changed between calls).
-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@…

Hi Wes,

My doubt is exactly in the behaviour you described.
When the upper code call my get My_Get_Table(struct variable *vp, oid *name, size_t *length,  int exact, size_t *var_len, WriteMethod **write_method)
 I return NULL when I have no more date to answer the query. But the upper code still asking me to send more results as I exemplified in my first post,
including other columns too. If I informed “nothing more”, why the upper code continue to asking for? 
Where I need to answer “Nothing more” I suppose to returning NULL the function that handler the queries related to my MIB, right?

If my query refers to the column x and I have only 4 rows, why it still calling me for more rows of the same column after I already answered with a NULL, and why to
ask for other columns too (but not all others in the table) ?

Perhaps you already answered, just to confirm to you that I send “nothing more”  as you explained to me above.

Best regards,