Re: snmpd failed to start when agentx is enabled

[Bill Fenner]

Hi Pushpa,

You are not enabling UNIX domain support, so net-snmp can't open the UNIX
domain socket for agentx. You can either use the TCP socket by configuring
with something like

agentXSocket tcp:127.0.0.1:705

and then configuring clients similarly, e.g., "snmptrap -X tcp:705"

Or adding the UNIX domain transport, e.g., add "Unix" to your
"--with-transports" configure argument.

  Bill


On Thu, Sep 26, 2024 at 9:20 AM Pushpa Thimmaiah 
wrote:

> Hi All,
>
> I am getting following error while starting snmpd in net-snmp-5.9. I have
> enabled  agentx and compiled the source. Kindly guide me to resolve the
> same.
> I have created directory /var/agentx
> ---
>
> agentx/master: initializing...
> trace: netsnmp_tdomain_transport_tspec(): snmp_transport.c, 655:
> tdomain: tdomain_transport_spec("agentx", "/var/agentx/master", 1,
> "[NIL]", "[NIL]", "[NIL]")
> trace: netsnmp_tdomain_transport_tspec(): snmp_transport.c, 736:
> tdomain: Address starts with '/', so assume "unix" domain
> trace: find_tdomain(): snmp_transport.c, 610:
> tdomain: Found no domain from specifier "unix"
> No support for any checked transport domain
> Error: Couldn't open a master agentx socket to listen on
> (/var/agentx/master):
> ---
>
>
> Thanks,
> Pushpa.T
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: AES192 and SHA256 support

[Bill Fenner]

Hi Michael,

I'm sorry, my system only creates users by adding "usmUser" entries to the
configuration file directly, so I don't know anything about how snmpusm
should work.

  Bill


On Wed, Jun 5, 2024 at 1:09 PM north digitalphenomena.com <
no...@digitalphenomena.com> wrote:

>
> Bill,
>
> I have compiled net-snmp (5.9.3) with the "--enable-blumenthal-aes"
> configure
> option, yet when I run any of the commands for creating a user with
> AES-192 or
> AES-256 give me a "Decryption error" (see below). OpenSSL does have the
> 192/256 set of variants for AES showing up in the list with "openssl list
> -cipher-algorithms" --
> Is there something else that needs to be turned on the in net-snmp to make
> this extension operable? (Or OpenSSL (version 3.0.8), for that matter).
>
> Thanks,
>
> Michael North
>
> + awk 'BEGIN {FS=":"} {print $2}'
> + passwd='admin_test_password#9812'
> + '[' '!' -z 'admin_test_password#9812' ]
> + '[' '!' -z authPriv ]
> + '[' '!' -z SHA ]
> + adminAuth=' -l authPriv -a SHA -A admin_test_password#9812'
> + '[' '!' -z AES-256 ]
> + encrypt='-x AES-256 -X admin_test_password#9812'
> + snmpusm -v 3 -u adminextronshaaes256 -n  -l authPriv -a SHA -A
> 'admin_test_password#9812' -x AES-256 -X 'admin_test_password#9812'
> /tmp/xsnmp/snmpagent create danellb adminextronshaaes256
> snmpset: Decryption error
> + status=
>
>
>
> --
> *From:* Bill Fenner 
> *Sent:* Tuesday, June 4, 2024 11:13 PM
> *To:* sukeerthi bj 
> *Cc:* net-snmp-coders@lists.sourceforge.net <
> net-snmp-coders@lists.sourceforge.net>
> *Subject:* Re: AES192 and SHA256 support
>
> Hi Sukeerthi,
>
> You're looking at the code that is used when NETSNMP_USE_PKCS11 is
> defined.  The SHA2 hashes such as SHA256 are only available with OpenSSL,
> in which case we use sc_get_openssl_hashfn() to pick the hash function that
> corresponds with the configured hash algorithm.
>
>   Bill
>
>
> On Fri, May 17, 2024 at 7:44 AM sukeerthi bj 
> wrote:
>
> Hi,
>
> I see AES192 and SHA256 support in SNMP, but wanted to understand if below
> code is doing right? Here for pcks_generate_ku only CKM_SHA_1 is passed.
> For SHA256 should not CKM_SHA256 be passed here instead?
> Can anyone have a look into this and explain?
>
> #ifndef NETSNMP_DISABLE_MD5
> if (NETSNMP_USMAUTH_HMACMD5 == auth_type)
> return pkcs_generate_Ku(CKM_MD5, P, pplen, Ku, kulen);
> else
> #endif
> if (NETSNMP_USMAUTH_HMACSHA1 == auth_type)
> return pkcs_generate_Ku(CKM_SHA_1, P, pplen, Ku, kulen);
> else {
> return (SNMPERR_GENERR);
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: AES192 and SHA256 support

[Bill Fenner]

Hi Sukeerthi,

You're looking at the code that is used when NETSNMP_USE_PKCS11 is
defined.  The SHA2 hashes such as SHA256 are only available with OpenSSL,
in which case we use sc_get_openssl_hashfn() to pick the hash function that
corresponds with the configured hash algorithm.

  Bill


On Fri, May 17, 2024 at 7:44 AM sukeerthi bj  wrote:

> Hi,
>
> I see AES192 and SHA256 support in SNMP, but wanted to understand if below
> code is doing right? Here for pcks_generate_ku only CKM_SHA_1 is passed.
> For SHA256 should not CKM_SHA256 be passed here instead?
> Can anyone have a look into this and explain?
>
> #ifndef NETSNMP_DISABLE_MD5
> if (NETSNMP_USMAUTH_HMACMD5 == auth_type)
> return pkcs_generate_Ku(CKM_MD5, P, pplen, Ku, kulen);
> else
> #endif
> if (NETSNMP_USMAUTH_HMACSHA1 == auth_type)
> return pkcs_generate_Ku(CKM_SHA_1, P, pplen, Ku, kulen);
> else {
> return (SNMPERR_GENERR);
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: SIGHUP for changing snmpv3 context

[Bill Fenner]

Hi Vivek,

There are some types of configuration that can only be applied with a
restart, because the option to change them has not yet been implemented.
There is nothing fundamental that prevents this from being implemented, but
it is not a simple fix, which is why it hasn't been done yet.

  Bill


On Tue, Jan 9, 2024 at 1:58 AM Vivek Aditya  wrote:

> Hi Team,
>
> I want the snmpv3 context to change without snmpd restart. When I checked
> with SIGHUP, looks like adding a new snmpv3 context, SIGHUP works; But
> deleting the context and sending a SIGHUP, the context does not get deleted
> and still able to perform walk with that context.
>
> Is there a way to do it or has this issue already been resolved? Any help
> would be appreciated
>
> --
> Warm Regards,
> Vivek Aditya
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Convert cleartext password to localised key

[Bill Fenner]

Hi Pushpa,

You can try https://gist.github.com/fenner/696cbb2d0e4429a8dff32af70b2bb8b1
for some sample python code.

  Bill


On Fri, Oct 20, 2023 at 4:45 AM Pushpa Thimmaiah 
wrote:

> Hi,
>
> I would like to convert cleartext password to localized key for trapsess
> line.  I understood that one way is by using  'createUser' and copying keys
> to trapsess line.  [
> https://www.mail-archive.com/net-snmp-users@lists.sourceforge.net/msg30097.html
> ]
>
> Is there any alternate way or application that will provide localized key
> for snmpv3 credentials?
>
>
> Thank you,
> Pushpa.T
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: helpers/scalar's realloc() of rootoid vs. netsnmp_subtree_split copying just the known size

[Bill Fenner]

I happened to get to talk to Wes about this, and his answer was basically
that these things were not meant to be mixed in this way.  I have since
changed my code to use netsnmp_register_scalar when I want to shadow a
scalar, and that works fine.

  Bill


On Wed, Nov 9, 2022 at 8:36 AM Bill Fenner  wrote:

> Hi,
>
> I have a MIB module that uses netsnmp_register_scalar() which realloc's
> the given root oid to have one more space in it, so that
> the netsnmp_scalar_helper_handler can use that space to store the ".0"
> instance during the handling of a request.
>
> This all works fine, until we register an instance for the same object via
> netsnmp_register_instance() - or, really, until that instance gets
> unregistered, via unregister_mib_context().  At this point, we go back to
> calling the scalar handler for that object, but, due to the duplicate
> registration, that scalar handler's registration has been duplicated via
> netsnmp_subtree_split.  Understandably, when netsnmp_subtree_split
> duplicates an OID, it doesn't add the magic extra space that the scalar
> helper needs, so after this registration and unregistration, the scalar
> helper starts stomping on memory it doesn't own.
>
> Is anyone familiar enough with this code to be able to suggest a way
> forward? If the scalar helper wants an extra oid's worth of memory in the
> rootoid pointer, it's almost like netsnmp_subtree_split needs to know that
> (e.g., a helper can provide its own implementation of snmp_duplicate_objid)?
>
> Thanks,
>   Bill
>
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

helpers/scalar's realloc() of rootoid vs. netsnmp_subtree_split copying just the known size

[Bill Fenner]

Hi,

I have a MIB module that uses netsnmp_register_scalar() which realloc's the
given root oid to have one more space in it, so that
the netsnmp_scalar_helper_handler can use that space to store the ".0"
instance during the handling of a request.

This all works fine, until we register an instance for the same object via
netsnmp_register_instance() - or, really, until that instance gets
unregistered, via unregister_mib_context().  At this point, we go back to
calling the scalar handler for that object, but, due to the duplicate
registration, that scalar handler's registration has been duplicated via
netsnmp_subtree_split.  Understandably, when netsnmp_subtree_split
duplicates an OID, it doesn't add the magic extra space that the scalar
helper needs, so after this registration and unregistration, the scalar
helper starts stomping on memory it doesn't own.

Is anyone familiar enough with this code to be able to suggest a way
forward? If the scalar helper wants an extra oid's worth of memory in the
rootoid pointer, it's almost like netsnmp_subtree_split needs to know that
(e.g., a helper can provide its own implementation of snmp_duplicate_objid)?

Thanks,
  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: oldEngineID format in snmpd.conf

[Bill Fenner]

On Wed, Jul 20, 2022 at 2:46 AM Feroz  wrote:

> What I configured in snmpd.conf file
>
> *engineID  8000b85c03d0672649a01e*
>

This configured net-snmp to use the string " 8000b85c03d0672649a01e" to
generate an engineID.

If you want to configure the engine-id with a hex string, please use the
"exactEngineID" configuration.  A sample usage:

exactEngineID 0xf5717f06fdc6db4a4600

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: snmpv3 poll

[Bill Fenner]

Hi Paban,

This means that your manager and your agent are not using the same
algorithm for short-key extension.  There are two different algorithms that
are in use to extend the output of a short hash function (like SHA) for use
with longer encryption keys (like AES192).

When you run into this situation, the best way to handle it is to use a
hash function that has a long enough output so that it does not need to be
extended in order to input to the encryption method.  Unsurprisingly, these
combinations are exactly the ones that work in your table.

Alternately, you can try the "other" extension mechanism, which net-snmp
identifies by appending a "C" to the encryption mechanism, e.g., AES192C or
AES256C.  I have no experience with this, I've only seen the code.

  Bill


On Wed, Jul 13, 2022 at 10:29 AM Paban Agarwalla 
wrote:

> Hi,
>
> We are using snmpv3 on our device.
>
> when we configure v3 users. Some of the algorithm combinations failed.
>
> Please find the attached table.
>
> Regards
> Paban
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: multiple subagent with same set of oid.

[Bill Fenner]

If there's interest, I have a patch that allows communities of the form
"community@context" to be treated by the snmp agent as separate community
and context values, eliminating the need to define each combination as a
valid community, and use com2sec to do the mapping.

I hadn't upstreamed it previously because it would change the behavior for
anyone who had an "@" in their community string.  Obviously giving it a
configuration file entry to turn this behavior on would probably address
that concern.

  Bill


On Thu, Apr 21, 2022 at 3:41 PM Wes Hardaker via Net-snmp-coders <
net-snmp-coders@lists.sourceforge.net> wrote:

> Paban Agarwalla  writes:
>
> > We are using to Netsnmp to collect statistics from our device.
> >
> > We are registering multiple subagents with the same set of oids.
> >
> > can i get all sub agent statastics using the same oid with v2c/v1 snmp
> > host?
>
> The only way to deal with problems like that is to use SNMPv3 contexts,
> where each context can map to a different subagent with overlapping OID
> registrations.  You can make v1/v2c communities to v3 contexts using the
> com2sec configuration tokens if you wish.
>
> --
> Wes Hardaker
> Please mail all replies to net-snmp-coders@lists.sourceforge.net
>
>
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: When exactly the response is received from node 2 ?

[Bill Fenner]

On Tue, Nov 2, 2021 at 8:17 AM Nishant Nayan 
wrote:

> Hi,
> Is there a way to track all function calls along with this
> "-Ddumpv,dumph"?
> I would like to track function calls made by 'snmpd' when I run snmpget to
> query OIDs from other snmp abled device.
>

You could try -DALL.  That doesn't quite track all function calls, but at
least it tracks all places where there is any debugging specified.

  Bill


> On Mon, 6 Sept 2021 at 19:26, Bill Fenner  wrote:
>
>> On Sun, Sep 5, 2021 at 9:59 AM Nishant Nayan 
>> wrote:
>>
>>> My aim is to know how various parameters like errorstat and errindex
>>> etc. are set from response.
>>>
>>> For an example command :
>>> snmpget -v1 -c cmty_remotehost1 localhost SNMPv2-MIB::sysName.1
>>> SNMPv2-MIB::sysDescr.0 SNMPv2-MIB::sysObjectID.0
>>>
>>> SNMPv2-MIB::sysName.1 being an incorrect oid
>>>
>>
>> I like to add "-Ddumpv,dumph" to get details of the messages that are
>> being send and received.  Try running your get with that debugging to see
>> if the output helps you understand where each field comes from.  (You can
>> change it to just "-Ddump" to also get a hex dump, which you may be able to
>> compare with the data field you see in your debugger).
>>
>> Each field in the packet is encoded using ASN.1, which is more or less a
>> type/length/value encoding, but is fairly complex.  If you're trying to
>> create your own packets, please see if it's feasible to use an existing
>> ASN.1 encoder, because there have historically been many bugs in ASN.1
>> parsing and encoding so it's best to use a well-tested implementation.
>>
>> Also, if you want to know what the SNMP protocol is doing, as opposed to
>> what the helpful snmpget command is doing, you should add "-Cf" to the
>> snmpget command line - when snmpget gets an error like this, it'll strip
>> out the bad object and try again so that it gets the data that may exist,
>> but that is not how SNMP works per se - that is how snmpget works.
>>
>>   Bill
>>
>>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Varbind orfer in SNMP TRAP's

[Bill Fenner]

On Thu, Oct 28, 2021 at 6:01 PM Fulko Hew  wrote:

>
>
> On Thu, Oct 28, 2021 at 5:23 PM Craig Small  wrote:
>
>> On Fri, 29 Oct 2021 at 05:14, Feroz  wrote:
>>
>>> hi,
>>> Is it necessary to maintain any specific order in SNMP TRAP for varbinds?
>>>
>> For the first two, yes.
>>
>
> I always followed the principles of:
> 1/ least surprise
> 2/ Be precise in what you send, and forgiving in what you receive.
>
> Having said that, reading that the first 'two varbinds are the uptime and
> trapOID respectively'
> and that a MIB source file lists the varbind in some order... Why not send
> them in the order shown?
> Why randomize?  (ie. the principle of least surprise)
>

https://datatracker.ietf.org/doc/html/rfc3416#section-4.2.6 may not use
MUST but does use some pretty specific words with easily understood
meanings:

If the OBJECTS clause is present in the invocation of
   the corresponding NOTIFICATION-TYPE macro, then each corresponding
   variable, as instantiated by this notification, is copied, in order,

   to the variable-bindings field.


To me it is pretty clear that the explicit inclusion of "in order" in this
sentence means that the ordering in the NOTIFICATION-TYPE macro in the MIB
module is the ordering that should be used in the Trap-PDU.

Section 4.2.6 continues:

 If any additional variables are
   being included (at the option of the generating SNMP entity), then
   each is copied to the variable-bindings field.


This addresses one of the points that Fulko mentioned - that an
intermediate proxy might add varbinds - BUT it also covers the case where
the originating agent is supplying additional varbinds beyond those
mentioned in the MIB.  One of our customers reported that their NMS stopped
displaying all of the trap variables when it loaded the MIB module - i.e.,
it only displayed the varbinds defined in the NOTIFICATION-TYPE macro.  But
the spec is clear that an agent has the option of adding additional
varbinds, and it's worth remembering this.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: How to support SNMPv2 mib traps per VRF.

[Bill Fenner]

On Wed, Oct 20, 2021 at 5:00 AM chandrasekharreddy chinnapareddygari <
chandrasekhar...@hotmail.com> wrote:

> Spell check has done in line.
> --
> *From:* chandrasekharreddy chinnapareddygari  >
> *Sent:* Wednesday, 20 October, 2021, 14:15
> *To:* net-snmp-coders@lists.sourceforge.net;
> net-snmp-us...@lists.sourceforge.net
> *Subject:* How to support SNMPv2 mib traps per VRF.
>
> Hi ,
>
>
> We are supporting Multiple snmp servers (snmp server for each VRF).I want
> to enable authenticationfailure traps for each VRF.
>
> Net-snmp has inbuilt token authtrapenable .Authentication Failure traps
> are sending to the receivers ,If authtrapenable is set to 1 in
> /etc/snmp/snmpd.conf .
>
> But, /etc/snmp/snmpd.conf file is common file for all  VRFs. My
> requirement is trapsinks ,  ,authentication failure traps status , cold
> start and  warm start traps should be per VRF.
>
>
> I have tried with adding authtrapenable 1 token in snmp.conf file. Which
> is local for each VRF. But snmpwalk output of snmpEnableAuthenTraps Oid is
> returning as disable(2).
>

How are you getting snmpd to load the per-VRF snmp.conf?  Have you tried
prefixing it with [snmpd], i.e.,

[snmpd] authtrapenable 1

in the snmp.conf (or maybe some other per-VRF config file)?

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: When exactly the response is received from node 2 ?

[Bill Fenner]

On Thu, Sep 23, 2021 at 6:43 AM Nishant Nayan 
wrote:

> Thanks for the suggestions, I have tried that and I could see the data
> sent and data received, however I am interested in the receiver part, as to
> how the date is prepared by the receiver(node 2) based on sender's request
> and then sent back to sender(node1),
>

The terms that we use in the SNMP world to describe these entities are that
the manager sends a request to the agent, who then sends a response back to
the manager.  You are asking how the agent builds its response.  What kind
of agent is it?  Is it also net-snmp, or is it something else?


> specifically how the error index and error status is getting
> prepared/calculated from receiver side, is there a way to debug this?
>

RFC3416 talks about the rules for setting them - e.g., general definitions
in section 4.1
https://datatracker.ietf.org/doc/html/rfc3416#section-4.1
and specifics about how they are set when handling a GetRequest in section
4.2.1
https://datatracker.ietf.org/doc/html/rfc3416#section-4.2.1

  Bill



>
>
> Thanks
> Nishant
>
> On Mon, 6 Sept 2021 at 19:34, Bill Fenner  wrote:
>
>> By the way, I wanted to mention - I noticed your example was using
>> SNMPv1.  SNMPv1 has been obsolete since 2002 (when the RFC was moved to
>> historic status).  You should ideally be using SNMPv3, with its
>> authorization and privacy improvements, and if not, at least use SNMPv2
>> which is not obsolete.
>>
>>   Bill
>>
>>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: I have some qhestions about work you library.

[Bill Fenner]

Hi Ivan,

Does the example at
http://www.net-snmp.org/wiki/index.php/TUT:Simple_Application help?
Specifically, in that example, "session.peername" is the remote DNS name,
but you can place a (string-formatted) IP address in that field as well.

  Bill


On Wed, Sep 15, 2021 at 5:27 PM Иван Иванов  wrote:

> I write some soft for network work with snmp. We have device with snmp
> server and whant to work with it via snmp lib. Now i have got some problem
> with work you snmp applications. I want to make snmpset and snmpget
> programs on the local host, transfering conection to server on device. The
> question is : where i should put ip adress of the snmp server and port for
> remote host. Can you make simple example about it, and it's will be nice if
> you will add this information to the documentation for you tools.
>
>
>
> All the best, Ivan Ivanov.
>
>
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Agent+Sub-Agent

[Bill Fenner]

On Fri, Sep 3, 2021 at 3:43 AM Feroz  wrote:

> My question is, is there a way to block an agent  from responding to
> queries ( by timeout), till time the sub-agent connects to the agent.
>

No, the master agent always lives under the impression that it knows
everything.  You may be able to fake it out by giving it an unreachable
proxy, something like "proxy udp:127.0.0.1:9 .1.3", and then having the
agentx registration use a better priority so that it overrides the proxy
config for each subtree that agentx registers.  However, this does use up
snmp server resources trying to proxy each request to something that will
not respond.

This is an interesting problem, especially if you have multiple
sub-agents.  What if you had one sub-agent that serves IP-MIB, and a
separate one that serves the system MIB?  Would you want to ignore requests
until both subagents are connected?

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: When exactly the response is received from node 2 ?

[Bill Fenner]

By the way, I wanted to mention - I noticed your example was using SNMPv1.
SNMPv1 has been obsolete since 2002 (when the RFC was moved to historic
status).  You should ideally be using SNMPv3, with its authorization and
privacy improvements, and if not, at least use SNMPv2 which is not obsolete.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: When exactly the response is received from node 2 ?

[Bill Fenner]

On Sun, Sep 5, 2021 at 9:59 AM Nishant Nayan 
wrote:

> My aim is to know how various parameters like errorstat and errindex etc.
> are set from response.
>
> For an example command :
> snmpget -v1 -c cmty_remotehost1 localhost SNMPv2-MIB::sysName.1
> SNMPv2-MIB::sysDescr.0 SNMPv2-MIB::sysObjectID.0
>
> SNMPv2-MIB::sysName.1 being an incorrect oid
>

I like to add "-Ddumpv,dumph" to get details of the messages that are being
send and received.  Try running your get with that debugging to see if the
output helps you understand where each field comes from.  (You can change
it to just "-Ddump" to also get a hex dump, which you may be able to
compare with the data field you see in your debugger).

Each field in the packet is encoded using ASN.1, which is more or less a
type/length/value encoding, but is fairly complex.  If you're trying to
create your own packets, please see if it's feasible to use an existing
ASN.1 encoder, because there have historically been many bugs in ASN.1
parsing and encoding so it's best to use a well-tested implementation.

Also, if you want to know what the SNMP protocol is doing, as opposed to
what the helpful snmpget command is doing, you should add "-Cf" to the
snmpget command line - when snmpget gets an error like this, it'll strip
out the bad object and try again so that it gets the data that may exist,
but that is not how SNMP works per se - that is how snmpget works.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: cannot get mac address value starting by "00" with an snmp module

[Bill Fenner]

It's hard to say without seeing your code, but a common source of problems
like this is using functions that are meant for nul-terminated strings
(e.g., strncpy() ) instead of those meant for moving bytes around (e.g.,
memcpy() ).

  Bill


On Fri, Jan 15, 2021 at 10:06 AM dga via Net-snmp-coders <
net-snmp-coders@lists.sourceforge.net> wrote:

> Hello,
>
> I would like to add more details to clarify the problem.
>
> The 6 fields of mac address are returned to the agent under a string of
> 6 chars: (let's say mac[6])
>
> So for the following mac address : "00:48:65:6C:6C:6F" :
>
> "00" => "NULL" = mac[0]
>
> "48" => "H" = mac[1]
>
> "65" => "e" = mac[2]
>
> "6C" => "l" = mac[3]
>
> "6C" => "l" = mac[4]
>
> "6F" => "o" = mac[5]
>
> it means we have : mac[6] = { '\0', 'H', 'e', 'l', 'l', 'o' , '\0'}
>
> This string (mac[6]) is returned with an other parameter (size_t *
> var_len) to giving the size of the string.  Here the size is 6 of course.
>
> But, when I get the corresponding oid value I get : "Hex-STRING: 00 00
> 00 00 00 00"
>
> It seems to be a bug ...
>
> Best Regards,
>
> Damien GARCIA
>
>
> Le 11/01/2021 à 20:27, dga a écrit :
> > Hello,
> >
> > I have written an snmp module to include additional interfaces in the
> > mib2 interface. However I face an issue with the field "ifPhysAddress"
> > (mac address) if the mac address of the interface starts by "00"
> > (example: "00:06:91:C6:B1:3F"). In that case I get "Hex-STRING: 00 00
> > 00 00 00 00" instead of getting  "Hex-STRING: 00 06 91 C6 B1 3F" . Is
> > it a bug ?
> >
> > I have no issue with my module if the mac address that does NOT start
> > by "00".
> >
> > There is also no issue get mac address starting by "00" for the
> > default interfaces of the snmp demon.
> >
> >
> > May be someone has ever face the same issue ? Any help would be
> > greatly appreciated !
> >
> >
> > Best Regards,
> >
> > Damien GARCIA
> >
> >
>
>
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Suggestions for testing changes regarding names of anonymous nodes

[Bill Fenner]

On Mon, Nov 2, 2020 at 9:37 AM Bill Fenner  wrote:

> I imagined writing a test that exercises all of the output options (-Of,
> -On, -Os, -OS, -Ou) for both netSnmpExampleAnonymousIntermediateNode
> and netSnmpExamples.42.1.  Does anyone have any other suggestions of what
> to test?
>

I accidentally stumbled across this bug in my proposed change with -OX
output: if a late index element translates to a string (e.g., a
PhysicalAddress), and an earlier element is a TimeTicks (or its
representation otherwise has a period in it), the output would be
MODULE-NAME::00][string]  (the "00" is the part of [0.00] after the dot..)
- I'm looking for brainstorming about other crazy corner cases like this.

(Concretely, this was
snmptranslate -OX
ARISTA-BRIDGE-EXT-MIB::aristaDot1qTpFdbNumMoves.1.42.40.41.42.43.44.45
ARISTA-BRIDGE-EXT-MIB::01][42][STRING: 28:29:2a:2b:2c:2d]
where the right output was
ARISTA-BRIDGE-EXT-MIB::aristaDot1qTpFdbNumMoves[0:00:00.01][42][STRING:
28:29:2a:2b:2c:2d]
where the INDEX was { aristaDot1qTpFdbTimeMark, dot1qFdbId,
dot1qTpFdbAddress } )

(This doesn't *require* -OX, once I identified the bug, it required "the
representation of the index contained a period followed by a letter",
so Q-BRIDGE-MIB::dot1qTpFdbAddress.42.40.41.42.43.46.66 => Q-BRIDGE-MIB::B'
instead of Q-BRIDGE-MIB::dot1qTpFdbAddress.42.'()*+.B'...)

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Suggestions for testing changes regarding names of anonymous nodes

[Bill Fenner]

Hi,

I found that net-snmp will output a nonsense name if there's an anonymous
node in the path.  For example, if you add

+--
+--  An object defined with an anonymous intermeidate node
+--  for testing object output in "-On" mode
+--
+
+netSnmpExampleAnonymousIntermediateNode OBJECT IDENTIFIER
+  ::= { netSnmpExamples 42 2 }
+

to NET-SNMP-EXAMPLES-MIB, and then "snmptranslate netSnmpExamples.42.1",
you get "NET-SNMP-EXAMPLES-MIB::42.1", which is not an object.  I have a
small patch at
https://github.com/fenner/net-snmp/commit/37d2e018254806ccbd9d84e75c594bbed35708d7
which fixes my example, but I want to make sure that it doesn't have any
bad side effects.

I imagined writing a test that exercises all of the output options (-Of,
-On, -Os, -OS, -Ou) for both netSnmpExampleAnonymousIntermediateNode
and netSnmpExamples.42.1.  Does anyone have any other suggestions of what
to test?

Thanks,
  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: response source IP for SNMP walk

[Bill Fenner]

On Wed, May 13, 2020 at 9:47 AM chandrasekharreddy chinnapareddygari <
chandrasekhar...@hotmail.com> wrote:

> Hi team,
>
>
> I want to  change source ip for snmpwalk like changing source IP for traps.
> I know , we can use clientaddr for changing source IP for traps.
>
>
> Is there any token is available to change source IP for snmpwalk.
>

Yes, in snmpapp.conf, you can use a line like

[snmp] clientaddr 192.0.2.1

to set the client addr for all the apps like snmpget, snmpwalk, etc.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: identical snmpEngineID across multiple device

[Bill Fenner]

On Wed, Mar 18, 2020 at 6:30 AM Pushpa Thimmaiah 
wrote:

> If two device has same snmpEngineID then will it impact on device security?
>

Two things off the top of my head:

1. The localized keys will be the same,  meaning that if a localized key is
stolen it can be used for all devices with the same engineID;
2. A conforming SNMP manager may not be able to talk to multiple devices
with the same EngineID (because it will cache the engineBoots/engineTime,
but different agents will have different engineBoots/engineTime values).
Doing this can cause messages to be determined to be replay attacks
(because the engineID in use identifies a different system).

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [netsnmp-coders] missing information in logmatch trap

[Bill Fenner]

On Sat, Sep 28, 2019 at 10:14 AM Thommandra Gowtham 
wrote:

> Thank you Bill for your response.
>
> When you said that I have configured two separate features, can you
> explain? How else can we get a logmatch trap by just one directive?
>

You currently can not. That is how I imagine the feature you're looking for
would be implemented.  What you have now is: logmatch increments a counter
when the log is seen, and disman sends you a trap when the counter
changes.  It's the fact that the interface between those pieces is a
counter that means that you can not get the actual message.

For b), which part of the code has the actual string that is matched? I can
> probably use it to raise a trap if needed.
>

https://github.com/net-snmp/net-snmp/blob/master/agent/mibgroup/ucd-snmp/logmatch.c#L291
If you want to know just what part of the line matched the regexp, then you
will have to pass in nmatch and pmatch arguments to regexec(), otherwise if
you just want the whole line it's in "inbuf" at that point.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [netsnmp-coders] missing information in logmatch trap

[Bill Fenner]

Hi Gowtham,

Please file your request at https://github.com/net-snmp/net-snmp/issues .
The reason the info is not present in the trap is because you have
configured two separate features:

1. count log file matches in the logMatch table - note that there is no
place in this table for a list of matches -
http://www.net-snmp.org/docs/mibs/ucdavis.html#logMatchTable
2. report via DISMAN (monitor) when the count goes up

In order to provide the actual match, the code would have to be changed to
either
a) send the trap from inside the logMatch code, and/or
b) maintain a list of matches in a new table

so it's not as straightforward as it may sound.

  Bill

On Tue, Sep 24, 2019 at 2:26 AM Thommandra Gowtham 
wrote:

> Hi Jeff,
>
> Can I get a response for the request?
>
> Thanks,
> Gowtham
>
> On Sat, Sep 7, 2019 at 9:23 AM Thommandra Gowtham 
> wrote:
>
>> Jeff,
>>
>> Thanks for your reply.
>>
>> It was a deliberate mail to net-snmp-coders. Because, I knew about the
>> pattern matching but that would not suffice because we get a trap like
>> below when we give a '.*' in pattern
>>
>> DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3022) 0:00:30.22
>> SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired
>> DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: Log Match
>> DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING:
>> DISMAN-EVENT-MIB::mteHotContextName.0 = STRING:
>> DISMAN-EVENT-MIB::mteHotOID.0 = OID: UCD-SNMP-MIB::logMatchCurrentCount.1
>> DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 9 UCD-SNMP-MIB::logMatchName.1 =
>> STRING: loginFailure UCD-SNMP-MIB::logMatchFilename.1 = STRING:
>> /var/log/auth.log UCD-SNMP-MIB::logMatchCurrentCount.1 = INTEGER: 9
>> UCD-SNMP-MIB::logMatchRegEx.1 = STRING: Failed password .*
>>
>> For the following config,
>> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
>> and line in log fine as below
>> Sep  5 19:51:43  sshd[23557]: Failed password for root from xx.xx.xx.xx
>> port 41569 ssh2
>>
>> It will match the string but it will not print the username in the trap
>> data. So, I was looking for any code changes that an be done to make it
>> expand the pattern and then send that data in trap.
>>
>> REgards,
>> Gowtham
>>
>> On Sat, Sep 7, 2019 at 2:26 AM Jeff Gehlbach  wrote:
>>
>>> On 9/5/19 10:58 PM, Thommandra Gowtham wrote:
>>>
>>> > - How can we get more information in a logmatch trap other than the
>>> > pattern matched?
>>>
>>> Making your pattern match more text should do the trick. For example:
>>>
>>> logmatch loginFailure /var/log/auth.log 30 Failed password for .*
>>>
>>> BTW, this kind of question isn't really what the net-snmp-coders list is
>>> for. The net-snmp-users list is a better fit:
>>>
>>> https://sourceforge.net/projects/net-snmp/lists/net-snmp-users
>>>
>>> -jeff
>>>
>>>
>>> ___
>>> Net-snmp-coders mailing list
>>> Net-snmp-coders@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>>>
>> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: snmpv3 context partial output

[Bill Fenner]

On Mon, Sep 23, 2019 at 11:48 AM T S, SURYA  wrote:

> So is there any way to merge null subtree with context subtree in netsnmp,
> so that I can get access to entire oid with context specifc oids on
> snmpwalk with context.
>

I looked into this a couple of months ago.  In my opinion, it would require
rewriting the OID tree code to support this feature well.

If you had a list of registrations that you'd like to have appear in the
alternate contexts, then for each context you *might* be able to register a
proxy handler in your snmpd.conf for each registration.  E.g.,

proxy [snmp credentials] -Cn VRF-1 system localhost

I haven't tried this because I didn't want to rewrite the config file for
every VRF.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: snmptrapd

[Bill Fenner]

On Wed, Sep 18, 2019 at 7:13 AM jayshankar nair 
wrote:

> Hi,
>
> I  am using variant of snmptrapd.
>

In what way is it a variant?


> The snmptrapd is processing trap packet at 4min delay. Why so much delay??.
>

Does this delay happen with unmodified snmptrapd?

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: MAC Address As Index

[Bill Fenner]

On Tue, Sep 17, 2019 at 4:27 AM Krishna Chaitanya 
wrote:

> On Tue, Sep 17, 2019 at 5:18 AM Bill Fenner  wrote:
> >
> > You can do this if you use snmp_varlist_add_variable() to create the
> index info (you can't use netsnmp_table_helper_add_indexes).  The code
> would be something like
> >
> > table_info = SNMP_MALLOC_TYPEDEF( netsnmp_table_registration_info );
> > snmp_varlist_add_variable(&table_info->indexes,
> >   NULL,
> >   0,
> >   ASN_TYPE_OF_IFACE_NAME,
> >   NULL,
> >   0);
> > snmp_varlist_add_variable(&table_info->indexes,
> >   NULL,
> >   0,
> >   ASN_IMPLIED_OCTET_STR,
> >   "XX",
> >   6);
> > snmp_varlist_add_variable(&table_info->indexes,
> >   NULL,
> >   0,
> >   ASN_TYPE_OF_HIST_CLASS,
> >   NULL,
> >   0);
> > snmp_varlist_add_variable(&table_info->indexes,
> >   NULL,
> >   0,
> >   ASN_TYPE_OF_HISTBIN_INDEX,
> >   NULL,
> >   0);
> >
> Thanks, Bill. I was using  "netsnmp_table_set_add_indexes" for the
> initial addition (don't have access to index_data but only type),
>

You should be able to replace "table_info" above by "tset->table" and add
the 4 calls to snmp_varlist_add_variable in place of the call to
"netsnmp_table_set_add_indexes".

and then when the data is available I either use
> "netsnmp_table_dataset_replace_row/netsnmp_table_dataset_add_row"
> using the API "netsnmp_table_row_add_index" for index.
>

This will continue to work.  The real difference is setting vp->val_len in
the indexes that you supply when you're registering the table.  For most
types this is not relevant but for the ASN_PRIV_IMPLIED types if you do not
set the length, as you saw it will consume the whole rest of the data and
not parse the indexes from the OID after that.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: MAC Address As Index

[Bill Fenner]

You can do this if you use snmp_varlist_add_variable() to create the index
info (you can't use netsnmp_table_helper_add_indexes).  The code would be
something like

table_info = SNMP_MALLOC_TYPEDEF( netsnmp_table_registration_info );
snmp_varlist_add_variable(&table_info->indexes,
  NULL,
  0,
  ASN_TYPE_OF_IFACE_NAME,
  NULL,
  0);
snmp_varlist_add_variable(&table_info->indexes,
  NULL,
  0,
  ASN_IMPLIED_OCTET_STR,
  "XX",
  6);
snmp_varlist_add_variable(&table_info->indexes,
  NULL,
  0,
  ASN_TYPE_OF_HIST_CLASS,
  NULL,
  0);
snmp_varlist_add_variable(&table_info->indexes,
  NULL,
  0,
  ASN_TYPE_OF_HISTBIN_INDEX,
  NULL,
  0);


  Bill


On Mon, Sep 16, 2019 at 10:23 AM Krishna Chaitanya 
wrote:

> On Tue, Sep 3, 2019 at 5:23 PM Krishna Chaitanya
>  wrote:
> >
> > On Tue, Aug 27, 2019 at 2:12 PM Krishna Chaitanya
> >  wrote:
> > >
> > > On Mon, Aug 26, 2019 at 9:22 PM Bill Fenner  wrote:
> > > >
> > > > On Tue, Aug 20, 2019 at 8:45 AM Krishna Chaitanya <
> chaitanya.m...@gmail.com> 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.
> >
> > After this change, I was getting a lot of duplicate data exists
> > errors, upon further debugging found a similar issue
> > which is quite old
> >
> https://www.mail-archive.com/net-snmp-coders@lists.sourceforge.net/msg06286.html
> .
> > In the current code even though there is support to handle IMPLIED
> > strings, but subsequent indexes are not processed.
> > See snippet below: out of 4 indexes only 2 are processed (the indexes
> > after ASN_PRIV_IMPLIED_OCTET_STR
> > failed to parse. Any ideas?
> >
> > histStatsData: Request Mode is: 160 name: wlp8s0f0 col: 3
> > histStatsData: Add row
> > duplicate table data attempted to be entered. row exists
> > helper:table:req: Got GETNEXT (161) mode request for handler table:
> > base oid:SNMPv2-SMI::mib-2.43932.2.2
> > helper:table:col:   have at least a column (3)
> > helper:table: have 17 bytes of index
> > helper:table:   looking for 4 indexes
> >
> > parse_oid_indexes: Parsed str(4): wlp8s0f0
> > helper:table:   got 1 (incomplete=0)
> >
> > parse_oid_indexes: Parsed str(196):
> > helper:table:   got 1 (incomplete=0)
> >
> > helper:table:   oid indexes not complete:
> >
> SNMPv2-SMI::mib-2.43932.2.2.1.3.8.119.108.112.56.115.48.102.48.0.128.225.66.153.1.2.15
> > helper:table:results:   found 2 indexes
> > helper:table:results:   column: 3, indexes: 2   index: type=4(04),
> > value=STRING: "wlp8s0f0"   index: type=196(c4), value=Variable has bad
> > type
> >
>
> As a workaround moved the MAC address index to last and it works fine
> with ASN_IMPLIED_OCTER_STR, this should be good enough for parsing
> programmatically, but
> for end-user its a bit counter-intuitive, having MAC Address as the
> 2nd index out of 4 is
> more readable. This was the diff in MIB:
>
> -  INDEX { ifaceName, remoteMAC, HistClass, HistBinIndex}
> +  INDEX { ifaceName, HistClass, HistBinIndex, remoteMAC}
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Tue, Aug 27, 2019 at 11:11 PM Bart Van Assche  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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Regarding snmpv3 inform packet

[Bill Fenner]

On Fri, Aug 23, 2019 at 12:19 PM Pushpa Thimmaiah <
pushpa.thimma...@gmail.com> 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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

On Mon, Aug 26, 2019 at 9:51 PM Bart Van Assche  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


src-address-in-snmpd-conf.diff
Description: Binary data
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner 
wrote:

> On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
> nore...@code.net-snmp.p.re.sourceforge.net> 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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Mon, Aug 26, 2019 at 4:51 PM Bart Van Assche  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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Mon, Aug 26, 2019 at 12:34 PM Bill Fenner 
wrote:

> On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner 
> wrote:
>
>> On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
>> nore...@code.net-snmp.p.re.sourceforge.net> 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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner 
wrote:

> On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
> nore...@code.net-snmp.p.re.sourceforge.net> 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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

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 , using the same
 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  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 
> 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.
>>
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

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  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.
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: MAC Address As Index

[Bill Fenner]

On Tue, Aug 20, 2019 at 8:45 AM 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?
>

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
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository <
nore...@code.net-snmp.p.re.sourceforge.net> 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-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Mon, Jul 8, 2019 at 9:53 AM Bart Van Assche  wrote:

> Hi Bill,
>
> To avoid confusion: does your comment apply to commit a88d81f1144e
> ("NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space") only or
> also to commit 4e3ace87b566 ("NET-SNMP-SYSTEM-MIB: Account reclaimable
> space")?
>

 I'm fine with 4e3ace87b566 ("NET-SNMP-SYSTEM-MIB: Account reclaimable
space").  It's change a88d81f1144e ("NET-SNMP-SYSTEM-MIB, Linux: Update
calculation of free space") that I'm concerned about, that changes the
long-standing values reported.

  Bill


>
> On 7/8/19 5:18 AM, Bill Fenner via Net-snmp-coders wrote:
>
> There's a long history of telling people "You're polling a Linux system,
> you have to know that you subtract buffers and cached from physical before
> you report free memory" in the HOST-RESOURCES-MIB.  I'm not against
> simplifying, but - if people have data collection set up for "the old way",
> where you have to subtract buffers and cached after collecting them, then
> this change will result in double-subtraction.
>
> In Arista EOS we handled this by adding another row to the table, to avoid
> breaking existing data collection when someone upgrades.
>
>   Bill
>
>
> On Mon, Jul 8, 2019 at 12:27 AM net-snmp Git repository <
> nore...@code.net-snmp.p.re.sourceforge.net> wrote:
>
>> Branch: V5-8-patches
>>
>> NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space
>>
>> Update calculation of free space for Physical and Virtual memory on linux.
>> Based on
>> https://gitlab.com/procps-ng/procps/blob/master/proc/sysinfo.c#L789
>>
>> [ bvanassche: edited patch subject ]
>>
>> By Josef Ridky on 07/04/2019 06:45
>> *View Changes*
>> <https://sourceforge.net/p/net-snmp/code/ci/a88d81f1144ecf33f0ca02ada042b77368855a94/>
>> --
>> Branch: master
>>
>> Merge branch 'V5-8-patches'
>>
>> * V5-8-patches:
>> NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space
>>
>> By Bart Van Assche on 07/08/2019 04:15
>> *View Changes*
>> <https://sourceforge.net/p/net-snmp/code/ci/8d5cdf8aeb6b3521e09b2f2a921ed5061da221e9/>
>> --
>>
>> Sent from sourceforge.net because you indicated interest in
>> https://sourceforge.net/p/net-snmp/code/
>>
>> To unsubscribe from further messages, please visit
>> https://sourceforge.net/auth/subscriptions/
>>
>
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

There's a long history of telling people "You're polling a Linux system,
you have to know that you subtract buffers and cached from physical before
you report free memory" in the HOST-RESOURCES-MIB.  I'm not against
simplifying, but - if people have data collection set up for "the old way",
where you have to subtract buffers and cached after collecting them, then
this change will result in double-subtraction.

In Arista EOS we handled this by adding another row to the table, to avoid
breaking existing data collection when someone upgrades.

  Bill


On Mon, Jul 8, 2019 at 12:27 AM net-snmp Git repository <
nore...@code.net-snmp.p.re.sourceforge.net> wrote:

> Branch: V5-8-patches
>
> NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space
>
> Update calculation of free space for Physical and Virtual memory on linux.
> Based on
> https://gitlab.com/procps-ng/procps/blob/master/proc/sysinfo.c#L789
>
> [ bvanassche: edited patch subject ]
>
> By Josef Ridky on 07/04/2019 06:45
> *View Changes*
> 
> --
> Branch: master
>
> Merge branch 'V5-8-patches'
>
> * V5-8-patches:
> NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space
>
> By Bart Van Assche on 07/08/2019 04:15
> *View Changes*
> 
> --
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/net-snmp/code/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

The memory leak is gone in the current V5-8-patches. I have not dug into
trying to bisect which change fixed it.

  Bill


On Tue, May 14, 2019 at 7:01 AM Bill Fenner  wrote:

> Perhaps getbulk no longer dumps core, but I can not get it to return
> anything but GENERR any more, and, it seems to leak memory.
>
> Any "large enough" request seems to fail in this way, e.g., snmpbulkget -v
> 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime sysUpTime sysUpTime .1
>
> This is particularly frustrating because code was added to 5.8 to rebuild
> a getbulk reply if it's too big.  But there was already code to not build
> the PDU too big, it's just not taking the v3 header into account properly
> (that's my best guess, at least).  So now there are two different
> mechanisms to send a "right-size" reply and they both don't work.  Around
> 5.8 release time I was working with Robert Story to fix this, but that
> effort kind of petered out and Robert's work didn't make it into git.
>
> Can anyone get getbulk to work in the current 5.8-patches with SNMPv3?
>
> I've attached a test script with 504 failing test cases when I run it
> against an unmodified V5-8-patches branch, and net-snmp leaks about a meg
> of RAM during the test.  This is an adaptation of my internal test to the
> net-snmp test framework; the complete test would use all supported values
> for -l, -a, -x but for now this is the simplest one using nanp.
>
> Thanks,
>   Bill
>
>
>
>
> On Wed, Apr 10, 2019 at 10:25 AM Bart Van Assche <
> bvass...@users.sourceforge.net> wrote:
>
>> This patch has been applied on the v5.8 and master branches. Thanks for
>> the patch!
>> --
>>
>> * [patches:#1388] <https://sourceforge.net/p/net-snmp/patches/1388/>
>> patch for bug 2923: snmpv3 bulkget errors result in double free core dump*
>>
>> *Status:* open
>> *Group:* backport-needed
>> *Created:* Tue Mar 05, 2019 09:56 AM UTC by Sam Tannous
>> *Last Updated:* Tue Mar 05, 2019 09:56 AM UTC
>> *Owner:* nobody
>> *Attachments:*
>>
>>- v3doublefree2.patch
>>
>> <https://sourceforge.net/p/net-snmp/patches/1388/attachment/v3doublefree2.patch>
>>(14.2 kB; application/octet-stream)
>>
>> This is a patch for https://sourceforge.net/p/net-snmp/bugs/2923/ when
>> almost any v3 bulkget
>> error will cause a core dump of snmpd.
>> --
>>
>> Sent from sourceforge.net because you indicated interest in
>> https://sourceforge.net/p/net-snmp/patches/1388/
>>
>> To unsubscribe from further messages, please visit
>> https://sourceforge.net/auth/subscriptions/
>>
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

To try to make it easier I've created a fake pull request, allowing
comments on the diff and discussion, and a clear set of diffs between this
stuff and 5.8-patches:

https://github.com/fenner/net-snmp/pull/3

  Bill


On Mon, May 20, 2019 at 11:27 AM Bill Fenner  wrote:

> Some of the back and forth with rstory happened on the admin list; some of
> it was unicast.  I put together all of the patches, even though there are
> now at least 2 fixes for the problem, and published them at
> https://github.com/fenner/net-snmp/commits/rstory-getbulk-patches .
>
> I can't imagine that the changes are useful as they are (other than the
> added debugging, perhaps) but may be useful to see what kinds of things we
> ran into.
>
> And my opinion remains that the fundamental problem here is that the
> reverse encoding knows how to stop encoding in time, but doesn't know about
> the overhead that usm adds, and for some reason the changes in 5.8 try to
> address this by switching to forward encoding, which relies on the state
> that was freed (and really probably only helps because forward encoding
> uses a fixed-sized 1472-byte buffer).  (It's possible that the delayed free
> that Sam introduced helps the "state that was freed" part.  With 3
> different solutions for the problem it's hard to figure out exactly how to
> proceed.)
>
>   Bill
>
>
> On Mon, May 20, 2019 at 9:28 AM Bill Fenner  wrote:
>
>> On Tue, May 14, 2019 at 1:38 PM Bart Van Assche 
>> wrote:
>>
>>> On 5/14/19 4:01 PM, Bill Fenner wrote:
>>> > Perhaps getbulk no longer dumps core, but I can not get it to return
>>> > anything but GENERR any more, and, it seems to leak memory.
>>> >
>>> > Any "large enough" request seems to fail in this way, e.g.,
>>> > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime
>>> > sysUpTime sysUpTime .1
>>> >
>>> > This is particularly frustrating because code was added to 5.8 to
>>> > rebuild a getbulk reply if it's too big.  But there was already code
>>> > to not build the PDU too big, it's just not taking the v3 header into
>>> > account properly (that's my best guess, at least).  So now there are
>>> > two different mechanisms to send a "right-size" reply and they both
>>> > don't work.  Around 5.8 release time I was working with Robert Story
>>> > to fix this, but that effort kind of petered out and Robert's work
>>> > didn't make it into git.
>>> >
>>> > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3?
>>> >
>>> > I've attached a test script with 504 failing test cases when I run it
>>> > against an unmodified V5-8-patches branch, and net-snmp leaks about a
>>> > meg of RAM during the test.  This is an adaptation of my internal test
>>> > to the net-snmp test framework; the complete test would use all
>>> > supported values for -l, -a, -x but for now this is the simplest one
>>> > using nanp.
>>>
>>>
>>> Hi Bill,
>>>
>>> A new test has been added
>>> (testing/fulltests/default/T0221snmpbulkget_large_simple). That test
>>> passes on my setup. Can you have a look whether that test covers the
>>> issue you ran into?
>>>
>>
>> It doesn't - the problems arise when the agent decides that the message
>> is too big and doesn't fit in the buffer.  (E.g., the usage
>> of --sendMessageMaxSize in my test, or, the repetition of .1 .1 .1 .1 on
>> the snmpbulkget command line).
>>
>> Regarding the "memory leak": RSS is not a reliable source of information
>>> to detect memory leaks. If you want to verify whether or not a new
>>> memory leak has been introduced please use Valgrind.
>>>
>>
>> Yes, my internal test uses valgrind and shows the leaks, I was using RSS
>> growth as a proxy.  I also used a script something like
>> http://www.net-snmp.org/wiki/index.php/Running_Net-SNMP_Regression_Tests_under_Valgrind
>>  and
>> it showed leaks when I ran the test that I sent, e.g.,
>>
>> ==32438== 31,584 (8,736 direct, 22,848 indirect) bytes in 168 blocks are
>> definitely lost in loss record 756 of 758
>> ==32438==at 0x402D05E: calloc (vg_replace_malloc.c:711)
>> ==32438==by 0x430EA7A: usm_malloc_usmStateReference (snmpusm.c:288)
>> ==32438==by 0x43117A7: usm_process_in_msg (snmpusm.c:2431)
>> ==32438==by 0x4312B44: usm_secmod_process_in_msg (snmpusm.c:2335)
>> ==32438== 

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

[Bill Fenner]

Some of the back and forth with rstory happened on the admin list; some of
it was unicast.  I put together all of the patches, even though there are
now at least 2 fixes for the problem, and published them at
https://github.com/fenner/net-snmp/commits/rstory-getbulk-patches .

I can't imagine that the changes are useful as they are (other than the
added debugging, perhaps) but may be useful to see what kinds of things we
ran into.

And my opinion remains that the fundamental problem here is that the
reverse encoding knows how to stop encoding in time, but doesn't know about
the overhead that usm adds, and for some reason the changes in 5.8 try to
address this by switching to forward encoding, which relies on the state
that was freed (and really probably only helps because forward encoding
uses a fixed-sized 1472-byte buffer).  (It's possible that the delayed free
that Sam introduced helps the "state that was freed" part.  With 3
different solutions for the problem it's hard to figure out exactly how to
proceed.)

  Bill


On Mon, May 20, 2019 at 9:28 AM Bill Fenner  wrote:

> On Tue, May 14, 2019 at 1:38 PM Bart Van Assche 
> wrote:
>
>> On 5/14/19 4:01 PM, Bill Fenner wrote:
>> > Perhaps getbulk no longer dumps core, but I can not get it to return
>> > anything but GENERR any more, and, it seems to leak memory.
>> >
>> > Any "large enough" request seems to fail in this way, e.g.,
>> > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime
>> > sysUpTime sysUpTime .1
>> >
>> > This is particularly frustrating because code was added to 5.8 to
>> > rebuild a getbulk reply if it's too big.  But there was already code
>> > to not build the PDU too big, it's just not taking the v3 header into
>> > account properly (that's my best guess, at least).  So now there are
>> > two different mechanisms to send a "right-size" reply and they both
>> > don't work.  Around 5.8 release time I was working with Robert Story
>> > to fix this, but that effort kind of petered out and Robert's work
>> > didn't make it into git.
>> >
>> > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3?
>> >
>> > I've attached a test script with 504 failing test cases when I run it
>> > against an unmodified V5-8-patches branch, and net-snmp leaks about a
>> > meg of RAM during the test.  This is an adaptation of my internal test
>> > to the net-snmp test framework; the complete test would use all
>> > supported values for -l, -a, -x but for now this is the simplest one
>> > using nanp.
>>
>>
>> Hi Bill,
>>
>> A new test has been added
>> (testing/fulltests/default/T0221snmpbulkget_large_simple). That test
>> passes on my setup. Can you have a look whether that test covers the
>> issue you ran into?
>>
>
> It doesn't - the problems arise when the agent decides that the message is
> too big and doesn't fit in the buffer.  (E.g., the usage
> of --sendMessageMaxSize in my test, or, the repetition of .1 .1 .1 .1 on
> the snmpbulkget command line).
>
> Regarding the "memory leak": RSS is not a reliable source of information
>> to detect memory leaks. If you want to verify whether or not a new
>> memory leak has been introduced please use Valgrind.
>>
>
> Yes, my internal test uses valgrind and shows the leaks, I was using RSS
> growth as a proxy.  I also used a script something like
> http://www.net-snmp.org/wiki/index.php/Running_Net-SNMP_Regression_Tests_under_Valgrind
>  and
> it showed leaks when I ran the test that I sent, e.g.,
>
> ==32438== 31,584 (8,736 direct, 22,848 indirect) bytes in 168 blocks are
> definitely lost in loss record 756 of 758
> ==32438==at 0x402D05E: calloc (vg_replace_malloc.c:711)
> ==32438==by 0x430EA7A: usm_malloc_usmStateReference (snmpusm.c:288)
> ==32438==by 0x43117A7: usm_process_in_msg (snmpusm.c:2431)
> ==32438==by 0x4312B44: usm_secmod_process_in_msg (snmpusm.c:2335)
> ==32438==by 0x42D45EF: snmpv3_parse (snmp_api.c:3938)
>
> When I run your new test, I agree it passes:
> ~/src/test-for-bart/testing @fenner-test-for-bart.sjc% ./RUNFULLTESTS -r
> T0221
> large SNMPv3 bulkget .. ok
>
> If I add "--sendMessageMaxSize=1472", then it fails in the same way as my
> test fails: returning genError.
>
> Your subsequent patch may address this problem if the manager does not
> specify a max response size, but as this is part of the SNMPv3 protocol and
> we do not necessarily control what the manager does, it's not sufficient.
>
>   Bill
>
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

On Tue, May 14, 2019 at 1:38 PM Bart Van Assche  wrote:

> On 5/14/19 4:01 PM, Bill Fenner wrote:
> > Perhaps getbulk no longer dumps core, but I can not get it to return
> > anything but GENERR any more, and, it seems to leak memory.
> >
> > Any "large enough" request seems to fail in this way, e.g.,
> > snmpbulkget -v 3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime
> > sysUpTime sysUpTime .1
> >
> > This is particularly frustrating because code was added to 5.8 to
> > rebuild a getbulk reply if it's too big.  But there was already code
> > to not build the PDU too big, it's just not taking the v3 header into
> > account properly (that's my best guess, at least).  So now there are
> > two different mechanisms to send a "right-size" reply and they both
> > don't work.  Around 5.8 release time I was working with Robert Story
> > to fix this, but that effort kind of petered out and Robert's work
> > didn't make it into git.
> >
> > Can anyone get getbulk to work in the current 5.8-patches with SNMPv3?
> >
> > I've attached a test script with 504 failing test cases when I run it
> > against an unmodified V5-8-patches branch, and net-snmp leaks about a
> > meg of RAM during the test.  This is an adaptation of my internal test
> > to the net-snmp test framework; the complete test would use all
> > supported values for -l, -a, -x but for now this is the simplest one
> > using nanp.
>
>
> Hi Bill,
>
> A new test has been added
> (testing/fulltests/default/T0221snmpbulkget_large_simple). That test
> passes on my setup. Can you have a look whether that test covers the
> issue you ran into?
>

It doesn't - the problems arise when the agent decides that the message is
too big and doesn't fit in the buffer.  (E.g., the usage
of --sendMessageMaxSize in my test, or, the repetition of .1 .1 .1 .1 on
the snmpbulkget command line).

Regarding the "memory leak": RSS is not a reliable source of information
> to detect memory leaks. If you want to verify whether or not a new
> memory leak has been introduced please use Valgrind.
>

Yes, my internal test uses valgrind and shows the leaks, I was using RSS
growth as a proxy.  I also used a script something like
http://www.net-snmp.org/wiki/index.php/Running_Net-SNMP_Regression_Tests_under_Valgrind
and
it showed leaks when I ran the test that I sent, e.g.,

==32438== 31,584 (8,736 direct, 22,848 indirect) bytes in 168 blocks are
definitely lost in loss record 756 of 758
==32438==at 0x402D05E: calloc (vg_replace_malloc.c:711)
==32438==by 0x430EA7A: usm_malloc_usmStateReference (snmpusm.c:288)
==32438==by 0x43117A7: usm_process_in_msg (snmpusm.c:2431)
==32438==by 0x4312B44: usm_secmod_process_in_msg (snmpusm.c:2335)
==32438==by 0x42D45EF: snmpv3_parse (snmp_api.c:3938)

When I run your new test, I agree it passes:
~/src/test-for-bart/testing @fenner-test-for-bart.sjc% ./RUNFULLTESTS -r
T0221
large SNMPv3 bulkget .. ok

If I add "--sendMessageMaxSize=1472", then it fails in the same way as my
test fails: returning genError.

Your subsequent patch may address this problem if the manager does not
specify a max response size, but as this is part of the SNMPv3 protocol and
we do not necessarily control what the manager does, it's not sufficient.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

Perhaps getbulk no longer dumps core, but I can not get it to return
anything but GENERR any more, and, it seems to leak memory.

Any "large enough" request seems to fail in this way, e.g., snmpbulkget -v
3 ... -Cn 5 -Cr 50 sysUpTime sysUpTime sysUpTime sysUpTime sysUpTime .1

This is particularly frustrating because code was added to 5.8 to rebuild a
getbulk reply if it's too big.  But there was already code to not build the
PDU too big, it's just not taking the v3 header into account properly
(that's my best guess, at least).  So now there are two different
mechanisms to send a "right-size" reply and they both don't work.  Around
5.8 release time I was working with Robert Story to fix this, but that
effort kind of petered out and Robert's work didn't make it into git.

Can anyone get getbulk to work in the current 5.8-patches with SNMPv3?

I've attached a test script with 504 failing test cases when I run it
against an unmodified V5-8-patches branch, and net-snmp leaks about a meg
of RAM during the test.  This is an adaptation of my internal test to the
net-snmp test framework; the complete test would use all supported values
for -l, -a, -x but for now this is the simplest one using nanp.

Thanks,
  Bill




On Wed, Apr 10, 2019 at 10:25 AM Bart Van Assche <
bvass...@users.sourceforge.net> wrote:

> This patch has been applied on the v5.8 and master branches. Thanks for
> the patch!
> --
>
> * [patches:#1388]  patch
> for bug 2923: snmpv3 bulkget errors result in double free core dump*
>
> *Status:* open
> *Group:* backport-needed
> *Created:* Tue Mar 05, 2019 09:56 AM UTC by Sam Tannous
> *Last Updated:* Tue Mar 05, 2019 09:56 AM UTC
> *Owner:* nobody
> *Attachments:*
>
>- v3doublefree2.patch
>
> 
>(14.2 kB; application/octet-stream)
>
> This is a patch for https://sourceforge.net/p/net-snmp/bugs/2923/ when
> almost any v3 bulkget
> error will cause a core dump of snmpd.
> --
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/net-snmp/patches/1388/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>


T0221snmpv3bulkbig_simple
Description: Binary data
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Tue, May 7, 2019 at 7:41 PM Bart Van Assche  wrote:

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

Yes, this is great, thanks!

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Mon, Apr 29, 2019 at 7:10 PM Bart Van Assche  wrote:

> On Mon, 2019-04-29 at 17:19 -0400, Bill Fenner wrote:
>
> On Sun, Apr 28, 2019 at 7:52 PM net-snmp Git repository <
> nore...@code.net-snmp.p.re.sourceforge.net> wrote:
>
> Branch: V5-8-patches
>
> configure: Determine endianness at compile time instead of at configure
> time
>
> The new test supports cross-compilation. In other words, --with-endianness
> no longer has to be specified during cross-compilation.
>
> By Bart Van Assche on 04/28/2019 20:40
> *View Changes*
> <https://sourceforge.net/p/net-snmp/code/ci/484524cda94838dfec8eb1ae92b069ea8ce448f6/>
>
>
> Hi Bart,
>
> This change exposes md5.c's "big lie" of const-ness.  Before, it was
> hidden behind #if BIG_ENDIAN, so I never saw it - now, it's exposed since
> MDReverse(X) can be called at runtime.  Obviously, MDReverse(X) can modify
> the value that's passed throughout as const.
>
> For now I've patched my local copy to eliminate the const lie throughout
> md5.[ch].
>
>
> Hi Bill,
>
> Do you plan to check in your patch or do you perhaps prefer that I look
> further into this?
>

I was hoping you might have an idea of a more graceful solution that allows
keeping const'ness.  If not, I can check in my change.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Sun, Apr 28, 2019 at 7:52 PM net-snmp Git repository <
nore...@code.net-snmp.p.re.sourceforge.net> wrote:

> Branch: V5-8-patches
>
> configure: Determine endianness at compile time instead of at configure
> time
>
> The new test supports cross-compilation. In other words, --with-endianness
> no longer has to be specified during cross-compilation.
>
> By Bart Van Assche on 04/28/2019 20:40
> *View Changes*
> 
>
> Hi Bart,

This change exposes md5.c's "big lie" of const-ness.  Before, it was hidden
behind #if BIG_ENDIAN, so I never saw it - now, it's exposed since
MDReverse(X) can be called at runtime.  Obviously, MDReverse(X) can modify
the value that's passed throughout as const.

For now I've patched my local copy to eliminate the const lie throughout
md5.[ch].

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Fri, Jan 25, 2019 at 11:37 AM Magnus Fromreide 
wrote:

> On Sun, Oct 28, 2018 at 01:54:22PM -0700, Bart Van Assche wrote:
> > Hello,
> >
> > As you may have noticed multiple people asked to add SO_BINDTODEVICE
> support
> > to Net-SNMP. This patch series adds such support by allowing to specify
> the
> > name of the network interface to bind a Net-SNMP endpoint to as
> > "@". An example:
> >
> > agent/snmpd -Mmibs -f -Lo -c .../snmpd.conf udp6:localhost@lo:1161 -r
> > apps/snmpwalk -Mmibs -v2c -cpublic udp6:localhost:1161 .1
>
> I have no real feeling one way or the other over the patch per se but I
> am wondering if the clash with virtual interface names on linux (e.g.
> lo:1) makes the choosen syntax problematic for the interface name
> parser?
>

This syntax is obsolete.  The supported mechanism is to use iproute2 to
manage multiple addresses/prefixes per interface.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

I was thinking about adding text below the table instead - "When specifying
*hostname*, *IPv4-address* or *IPv6-address* in the tcp, udp, tcp6 or udp6
transports, you can also ...".  I don't want to clutter up the main
documentation with these kind-of-corner-cases.

  Bill


On Fri, Jan 25, 2019 at 3:53 AM Anders Wallin  wrote:

> What about something like this ( I skipped the "or")
> diff --git a/man/snmpcmd.1.def b/man/snmpcmd.1.def
> index aea3ca40a..d4f896000 100644
> --- a/man/snmpcmd.1.def
> +++ b/man/snmpcmd.1.def
> @@ -367,12 +367,12 @@ to the following table:
>  .BR ""
>  .BR " format"
>  .IP "udp" 28
> -hostname[:port]
> -.I or
> -IPv4-address[:port]
> +hostname[@interface[@namespace]][:port]
> +.IP "" 28
> +IPv4-address[@interface[@namespace]][:port]
>  .IP "tcp" 28
>
> which gives
> format
>
>  udp
>  hostname[@interface[@namespace]][:port]
>
>
>  IPv4-address[@interface[@namespace]][:port]
>
>
>
> ons 23 jan. 2019 kl 20:38 skrev Bill Fenner  >:
>
>> My attempts at updating the man page formats really poorly in 80 columns:
>>
>>At its simplest, the AGENT specification may consist of a  host-
>>
>>name, or an IPv4 address in the standard "dotted quad" notation.
>>
>>In this case, communication will be attempted using UDP/IPv4  to
>>
>>port  161 of the given host.  Otherwise, the 
>>
>>part of the specification is parsed according to  the  following
>>
>>table:
>>
>>
>>format
>>
>>
>>udp hostname[@interface[@names-
>>
>>pace]][:port] or
>>
>>IPv4-address[@interface[@names-
>>
>>pace]][:port]
>>
>>
>>tcp hostname[@interface[@names-
>>
>>pace]][:port] or
>>
>>IPv4-address[@interface[@names-
>>
>>pace]][:port]
>>
>>
>>unixpathname
>>
>>
>>ipx [network]:node[/port]
>>
>>
>>aal5pvc or pvc  [interface.][VPI.]VCI
>>
>>
>>udp6 or udpv6 or udpipv6hostname[@interface[@names-
>>
>>pace]][:port] or
>>
>>IPv6-address[@interface[@names-
>>
>>pace]]:port or
>>
>> '['IPv6-address']'[@inter-
>>
>>face[@namespace]][:port]
>>
>>
>>tcp6 or tcpv6 or tcpipv6hostname[@interface[@names-
>>
>>pace]][:port] or
>>
>>IPv6-address[@interface[@names-
>>
>>pace]]:port or
>>
>> '['IPv6-address']'[@inter-
>>
>>face[@namespace]][:port]
>>
>> ...
>>
>>udp:hostnameidentical to the previous specification.
>>
>>The   "udp:"  is  redundant  here  since
>>
>>UDP/IPv4 is the default transport.
>>
>>
>>hostname@eth0:161   identical to the previous specification,
>>
>>except  that the communication is forced
>>
>>to eth0 using the SO_BINDTODEVICE socket
>>
>>option.
>>
>>
>>hostname@eth0@blue  identical to the previous specification,
>>
>>except  that  the  communication  occurs
>>
>>using  the  eth0  interface  inside  the
>>
>>namespace named "blue"  (created,  e.g.,
>>
>>using ip netns add ).
>>
>> ...
>>
>>If the platform supports  binding  to  an  interface  using  the
>>
>>SO_BINDTODEVICE socket option, the optional @interface specifier
>>
>>can be added to an IP address or host name.
>>
>>
>>If the platform supports network namespaces using the setns sys-
>>
>>tem  call,  the  optional @netns specifier can be added to an IP
>>
>>address or host name.  If an interface specification (see above)
>>
>>is not required, two @ s are used, e.g., 127.0.0.1@@blue .
>>
>>
>> Perhaps I can fix the formatting of the first table by separating out the
>> "hostname or ip_ address" and "followed by optional @interface, @namespace,
>> :port"? Any suggestions?
>>
>>
>> Thanks,
>>
>>   Bill
>>
>>
>>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Wed, Jan 23, 2019 at 10:17 PM Bart Van Assche  wrote:

> On 1/23/19 9:43 AM, Bill Fenner wrote:
> > The pattern I was trying to follow from the existing code appeared to be
> > basically
> >
> > if (cp == delimiter of optional section) {
> >  *cp = '\0'; /* terminate previous section at delimiter */
> >  this = cp + 1; /* handle this section */
> >  cp = ... /* find next optional delimiter or NULL */
> > }
> >
> > Are you suggesting instead to put the "find next optional delimiter"
> > code between sections, e.g.,
> >
> > /* parse IP address, cp still points at beginning of address */
> > maybeintf = strchr( cp, '@' );
> > if (maybeintf) {
> > *maybeintf = '\0';
> > cp = maybeintf + 1;
> > intf = cp;
> > }
> > maybens = strchr( cp, '@' );
> > if (maybens) {
> > ...
> > }
> > maybeport = strchr( cp, ':' );
> > if (maybeport) {
> > ...
> > }
>
> Hi Bill,
>
> No matter which approach will be chosen, please add test cases into
> testing/fulltests/unit-tests/T022netsnmp_parse_ep_str_clib.c.


There are several new test cases for namespace names in what’s on github
now, and in a revision I haven’t pushed yet I added some corner cases like
“hostname@@“ and “hostname@@:”. Was there anything else you thought was
missing?

(Thanks for having written that test, by the way; it helped me find a bug
in my initial code.)

Thanks,
  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

My attempts at updating the man page formats really poorly in 80 columns:

   At its simplest, the AGENT specification may consist of a  host-

   name, or an IPv4 address in the standard "dotted quad" notation.

   In this case, communication will be attempted using UDP/IPv4  to

   port  161 of the given host.  Otherwise, the 

   part of the specification is parsed according to  the  following

   table:


   format


   udp hostname[@interface[@names-

   pace]][:port] or

   IPv4-address[@interface[@names-

   pace]][:port]


   tcp hostname[@interface[@names-

   pace]][:port] or

   IPv4-address[@interface[@names-

   pace]][:port]


   unixpathname


   ipx [network]:node[/port]


   aal5pvc or pvc  [interface.][VPI.]VCI


   udp6 or udpv6 or udpipv6hostname[@interface[@names-

   pace]][:port] or

   IPv6-address[@interface[@names-

   pace]]:port or

'['IPv6-address']'[@inter-

   face[@namespace]][:port]


   tcp6 or tcpv6 or tcpipv6hostname[@interface[@names-

   pace]][:port] or

   IPv6-address[@interface[@names-

   pace]]:port or

'['IPv6-address']'[@inter-

   face[@namespace]][:port]

...

   udp:hostnameidentical to the previous specification.

   The   "udp:"  is  redundant  here  since

   UDP/IPv4 is the default transport.


   hostname@eth0:161   identical to the previous specification,

   except  that the communication is forced

   to eth0 using the SO_BINDTODEVICE socket

   option.


   hostname@eth0@blue  identical to the previous specification,

   except  that  the  communication  occurs

   using  the  eth0  interface  inside  the

   namespace named "blue"  (created,  e.g.,

   using ip netns add ).

...

   If the platform supports  binding  to  an  interface  using  the

   SO_BINDTODEVICE socket option, the optional @interface specifier

   can be added to an IP address or host name.


   If the platform supports network namespaces using the setns sys-

   tem  call,  the  optional @netns specifier can be added to an IP

   address or host name.  If an interface specification (see above)

   is not required, two @ s are used, e.g., 127.0.0.1@@blue .


Perhaps I can fix the formatting of the first table by separating out the
"hostname or ip_ address" and "followed by optional @interface, @namespace,
:port"? Any suggestions?


Thanks,

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Wed, Jan 23, 2019 at 12:58 AM Anders Wallin  wrote:

> Hi Bill,
>
> I'm missing updates to the documentation/man pages. (I can't find that the
> man pages are update with @iface either)
>

Yes, I documented it in the same place as @intf ;-)

I'll fix that.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Wed, Jan 23, 2019 at 12:15 AM Bart Van Assche  wrote:

> On 1/22/19 12:40 PM, Bill Fenner wrote:
> > On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche  > <mailto:bvanass...@acm.org>> wrote:
> >
> >     On 11/6/18 8:03 AM, Bill Fenner wrote:
> >  > Given your proposed code structure, I imagine that we could add
> > network
> >  > namespaces to netsnmp_ep too - this basically ends up using
> > "socketat(
> >  > /* magic */, family, type, protocol )" instead of socket() to
> > create the
> >  > socket, and the magic can be derived from what we store in ep.
> >
> > That sounds like a good idea to me.
> >
> >
> > I've finally done this, and would like to request some eyes on it before
> > I push it to 5-8-patches.
> >
> >
> https://github.com/fenner/net-snmp/compare/V5-8-patches...fenner:linux-namespace
>
> Hi Bill,
>
> The following new code in netsnmp_parse_ep_str() looks a bit fragile to me:
>
>  cp = strchr(iface, '@');
>  if (!cp)
>  cp = strchr(iface, ':');
>
> Wouldn't it be better to backtrack to the previous value of 'cp' if no
> second '@' sign is found? That will avoid that this code fails if
> support for a new delimiter between '@' and ':' would be added.
>

The pattern I was trying to follow from the existing code appeared to be
basically

if (cp == delimiter of optional section) {
*cp = '\0'; /* terminate previous section at delimiter */
this = cp + 1; /* handle this section */
cp = ... /* find next optional delimiter or NULL */
}

Are you suggesting instead to put the "find next optional delimiter" code
between sections, e.g.,

/* parse IP address, cp still points at beginning of address */
maybeintf = strchr( cp, '@' );
if (maybeintf) {
   *maybeintf = '\0';
   cp = maybeintf + 1;
   intf = cp;
}
maybens = strchr( cp, '@' );
if (maybens) {
...
}
maybeport = strchr( cp, ':' );
if (maybeport) {
...
}

where at the end of each block, cp still points to the beginning of the
thing that was parsed by the block (address, intf, namespace, or port) and
we advance the pointer between blocks?


The following code looks unusual to me:
>
> #ifdef HAVE_SETNS
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #endif
>
> I'm not aware of any other Net-SNMP code that guards include directives
> with the result of a test for a system call.
>

Well, I was just trying to reduce the #include footprint to match the new
code - if the new code in netsnmp_socketat() isn't compiled, then the new
#includes that it requires aren't required.  Maybe this is a leftover habit
from learning C in the 1980's :-)

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche  wrote:

> On 11/6/18 8:03 AM, Bill Fenner wrote:
> > Given your proposed code structure, I imagine that we could add network
> > namespaces to netsnmp_ep too - this basically ends up using "socketat(
> > /* magic */, family, type, protocol )" instead of socket() to create the
> > socket, and the magic can be derived from what we store in ep.
>
> That sounds like a good idea to me.
>

I've finally done this, and would like to request some eyes on it before I
push it to 5-8-patches.

https://github.com/fenner/net-snmp/compare/V5-8-patches...fenner:linux-namespace

Thanks,
  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

I've applied my clientaddr parsing fix for IPv4 and IPv6, passing ":0" as
the default transport, and also modified the IPv6 address parser to handle
a bare IPv6 address (no brackets, no port).  With these changes, all of the
tests pass in their original form.

I'd like to add some more tests for specifying a port explicitly, after
which we can get rid of the complex code that tries to do this for the
limited v4 case, and make all 4 cases (v4 source address, v4 clientaddr, v6
source address, v6 clientaddr) the same, but I've run out of time for now.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

> On Nov 7, 2018, at 1:27 AM, Bart Van Assche  wrote:
> 
>> On 11/6/18 12:31 PM, Bill Fenner wrote:
>> Playing with this in V5-8-patches, I see it broke my fix for using 
>> clientaddr to specify the source address for traps:
>> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1", default_target 
>> ":0"
>> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target "[NIL]"
>> netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 <http://0.0.0.0:161> }
>> netsnmp_sockaddr_in: hostname (resolved okay)
>> netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 <http://127.0.0.1:161> }
>> In the previous implementation, specifying a default_target of ":0" would 
>> set the port number to zero, meaning, let the kernel decide.  Now, it 
>> appears to mean, use the SNMP default.  This causes the bind() to fail, of 
>> course, since binding to 127.0.0.1:0 <http://127.0.0.1:0> would work fine, 
>> but binding to 127.0.0.1:161 <http://127.0.0.1:161> conflicts with the 
>> actual snmpd port.
>> netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
>> netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
>> netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
>> snmpd: netsnmp_create_notification_session:
>> /tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8: 
>> Error: cannot create sink: udp:172.25.24.62:5716 <http://172.25.24.62:5716>
>> I've committed my tests for trap2sink, trapsess, and using "-s" with 
>> trapsess.  None of the v6 versions work, but the v4 trapsess versions work, 
>> after fixing netsnmp_udpipv4base_transport_with_source() to use the 
>> "bind_addr" variable.  I believe that fixing the parsing of ":0" to return a 
>> zero port like it did before would fix trap2sink.  I haven't looked at 
>> what's wrong with v6 yet.
>> (The confusing code in netsnmp_udpipv4base_transport() around "have_port" 
>> and "uses_port", including the introduction of 
>> NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working around 
>> this same bug of setting the port when it doesn't need to be set, and could 
>> be eliminated altogether if that bug is fixed.)
> 
> Oops, that's something I was not aware of. Can you check that whether the 
> changes I checked in earlier today fix this regression? Are there any other 
> regressions than this one that you are aware of?

5.8 was released with regressions in this area already, so the regressions that 
are present in this branch are not necessarily due to your changes. The T18* 
tests (without the change to specify the port explicitly) should all pass (and 
do in the 5-7-patches branch).

I think one thing for v6 is that it needs to be able to parse a bare IP address 
without port or brackets (for clientaddr purposes).


The T18* tests should probably be improved to prohibit receiving traps sourced 
from port 161 or 162, in case someone runs the tests as root. I will look at 
making this change.

  Bill



___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner via Net-snmp-coders]

I screwed up the v6 tests a little, and just pushed some fixes to it.  The
current status is: the 4 tests that are in V5-7-patches all pass
(trap2sink, v6 trap2sink, trapsess, v6 trapsess).  I applied the same
clientaddr port zeroing to v6 as v4 already has in V5-7-patches to get the
v6 trapsink version to pass.

Since the code is all different in 5.8, the fixes don't apply.  The v4
trapsink case and all of the v6 cases (including the added case for "-s"
with trapsess) fail.  The two v4 trapsess cases succeed.  All of the
failures in 5.8 are regressions from V5-7-patches.  (They were regressions
before your changes here, but your changes broke my fix that Sam tried in
https://sourceforge.net/p/net-snmp/bugs/2888/ )

  Bill


On Tue, Nov 6, 2018 at 3:31 PM Bill Fenner 
wrote:

> Playing with this in V5-8-patches, I see it broke my fix for using
> clientaddr to specify the source address for traps:
>
> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1",
> default_target ":0"
> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target
> "[NIL]"
> netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
> netsnmp_sockaddr_in: hostname (resolved okay)
> netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
>
> In the previous implementation, specifying a default_target of ":0" would
> set the port number to zero, meaning, let the kernel decide.  Now, it
> appears to mean, use the SNMP default.  This causes the bind() to fail, of
> course, since binding to 127.0.0.1:0 would work fine, but binding to
> 127.0.0.1:161 conflicts with the actual snmpd port.
>
> netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
> netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
> netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
> snmpd: netsnmp_create_notification_session:
> /tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8:
> Error: cannot create sink: udp:172.25.24.62:5716
>
> I've committed my tests for trap2sink, trapsess, and using "-s" with
> trapsess.  None of the v6 versions work, but the v4 trapsess versions work,
> after fixing netsnmp_udpipv4base_transport_with_source() to use the
> "bind_addr" variable.  I believe that fixing the parsing of ":0" to return
> a zero port like it did before would fix trap2sink.  I haven't looked at
> what's wrong with v6 yet.
>
> (The confusing code in netsnmp_udpipv4base_transport() around "have_port"
> and "uses_port", including the introduction
> of NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working
> around this same bug of setting the port when it doesn't need to be set,
> and could be eliminated altogether if that bug is fixed.)
>
>   Bill
>
>
> On Tue, Nov 6, 2018 at 11:03 AM Bill Fenner 
> wrote:
>
>> Hi Bart,
>>
>> My main question is, what's the advantage of storing the IPv4/IPv6
>> address as a string and a port number, instead of as a sockaddr_*?  I.e.,
>> why use netsnmp_ep_str?
>>
>> Is the API change here ok?  Are we assuming that nobody ever calls
>> netsnmp_foo_transport() directly?
>>
>> Should there be an #ifdef in patch 5 to make the interface name optional,
>> both in the struct and the parser, for platforms that don't support it?  Is
>> it better to return a parse error on the address that includes interface
>> name, or a "failed to open socket" without much more information?
>>
>> Given your proposed code structure, I imagine that we could add network
>> namespaces to netsnmp_ep too - this basically ends up using "socketat( /*
>> magic */, family, type, protocol )" instead of socket() to create the
>> socket, and the magic can be derived from what we store in ep.
>>
>> I don't have a strong opinion about which this code should go in.
>>
>>   Bill
>>
>>
>> On Sun, Oct 28, 2018 at 5:19 PM Bart Van Assche 
>> wrote:
>>
>>> Hello,
>>>
>>> As you may have noticed multiple people asked to add SO_BINDTODEVICE
>>> support
>>> to Net-SNMP. This patch series adds such support by allowing to specify
>>> the
>>> name of the network interface to bind a Net-SNMP endpoint to as
>>> "@". An example:
>>>
>>> agent/snmpd -Mmibs -f -Lo -c .../snmpd.conf udp6:localhost@lo:1161 -r
>>> apps/snmpwalk -Mmibs -v2c -cpublic udp6:localhost:1161 .1
>>>
>>> The reason I'm posting this patch series on the Net-SNMP mailing list is
>>> to
>>> gather feedback about this patch seri

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

[Bill Fenner via Net-snmp-coders]

Playing with this in V5-8-patches, I see it broke my fix for using
clientaddr to specify the source address for traps:

netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1",
default_target ":0"
netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target
"[NIL]"
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }

In the previous implementation, specifying a default_target of ":0" would
set the port number to zero, meaning, let the kernel decide.  Now, it
appears to mean, use the SNMP default.  This causes the bind() to fail, of
course, since binding to 127.0.0.1:0 would work fine, but binding to
127.0.0.1:161 conflicts with the actual snmpd port.

netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
snmpd: netsnmp_create_notification_session:
/tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8:
Error: cannot create sink: udp:172.25.24.62:5716

I've committed my tests for trap2sink, trapsess, and using "-s" with
trapsess.  None of the v6 versions work, but the v4 trapsess versions work,
after fixing netsnmp_udpipv4base_transport_with_source() to use the
"bind_addr" variable.  I believe that fixing the parsing of ":0" to return
a zero port like it did before would fix trap2sink.  I haven't looked at
what's wrong with v6 yet.

(The confusing code in netsnmp_udpipv4base_transport() around "have_port"
and "uses_port", including the introduction
of NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working
around this same bug of setting the port when it doesn't need to be set,
and could be eliminated altogether if that bug is fixed.)

  Bill


On Tue, Nov 6, 2018 at 11:03 AM Bill Fenner 
wrote:

> Hi Bart,
>
> My main question is, what's the advantage of storing the IPv4/IPv6 address
> as a string and a port number, instead of as a sockaddr_*?  I.e., why use
> netsnmp_ep_str?
>
> Is the API change here ok?  Are we assuming that nobody ever calls
> netsnmp_foo_transport() directly?
>
> Should there be an #ifdef in patch 5 to make the interface name optional,
> both in the struct and the parser, for platforms that don't support it?  Is
> it better to return a parse error on the address that includes interface
> name, or a "failed to open socket" without much more information?
>
> Given your proposed code structure, I imagine that we could add network
> namespaces to netsnmp_ep too - this basically ends up using "socketat( /*
> magic */, family, type, protocol )" instead of socket() to create the
> socket, and the magic can be derived from what we store in ep.
>
> I don't have a strong opinion about which this code should go in.
>
>   Bill
>
>
> On Sun, Oct 28, 2018 at 5:19 PM Bart Van Assche 
> wrote:
>
>> Hello,
>>
>> As you may have noticed multiple people asked to add SO_BINDTODEVICE
>> support
>> to Net-SNMP. This patch series adds such support by allowing to specify
>> the
>> name of the network interface to bind a Net-SNMP endpoint to as
>> "@". An example:
>>
>> agent/snmpd -Mmibs -f -Lo -c .../snmpd.conf udp6:localhost@lo:1161 -r
>> apps/snmpwalk -Mmibs -v2c -cpublic udp6:localhost:1161 .1
>>
>> The reason I'm posting this patch series on the Net-SNMP mailing list is
>> to
>> gather feedback about this patch series. Does everyone agree with the code
>> changes in this patch series? If so, on which branch(es) should these
>> patches
>> be applied? Master only or v5.8 and master?
>>
>> See also:
>> * Add SO_BINDTODEVICE support
>>   (https://sourceforge.net/p/net-snmp/patches/1296/).
>> * Add Linux VRF support (https://sourceforge.net/p/net-snmp/patches/1376/
>> ).
>>
>> Thanks,
>>
>> Bart.
>>
>> Bart Van Assche (6):
>>   libsnmp/transports: Introduce netsnmp_parse_ep_str()
>>   libsnmp/transports: Introduce netsnmp_sockaddr_in3() and
>> netsnmp_sockaddr_in6_3()
>>   libsnmp/transports: Change multiple sockaddr_in* arguments into
>> netsnmp_ep
>>   configure: Add a test for SO_BINDTODEVICE
>>   libsnmp/transports: Add support for interface binding
>>   testing/fulltests/unit-tests: Add netsnmp_parse_ep_str() unit test
>>
>>  configure |  34 +++
>>  configure.d/config_os_misc4   |  15 ++
>>  include/net-snmp/library/snmpDTLSUDPDomai

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

[Bill Fenner via Net-snmp-coders]

Hi Bart,

My main question is, what's the advantage of storing the IPv4/IPv6 address
as a string and a port number, instead of as a sockaddr_*?  I.e., why use
netsnmp_ep_str?

Is the API change here ok?  Are we assuming that nobody ever calls
netsnmp_foo_transport() directly?

Should there be an #ifdef in patch 5 to make the interface name optional,
both in the struct and the parser, for platforms that don't support it?  Is
it better to return a parse error on the address that includes interface
name, or a "failed to open socket" without much more information?

Given your proposed code structure, I imagine that we could add network
namespaces to netsnmp_ep too - this basically ends up using "socketat( /*
magic */, family, type, protocol )" instead of socket() to create the
socket, and the magic can be derived from what we store in ep.

I don't have a strong opinion about which this code should go in.

  Bill


On Sun, Oct 28, 2018 at 5:19 PM Bart Van Assche  wrote:

> Hello,
>
> As you may have noticed multiple people asked to add SO_BINDTODEVICE
> support
> to Net-SNMP. This patch series adds such support by allowing to specify the
> name of the network interface to bind a Net-SNMP endpoint to as
> "@". An example:
>
> agent/snmpd -Mmibs -f -Lo -c .../snmpd.conf udp6:localhost@lo:1161 -r
> apps/snmpwalk -Mmibs -v2c -cpublic udp6:localhost:1161 .1
>
> The reason I'm posting this patch series on the Net-SNMP mailing list is to
> gather feedback about this patch series. Does everyone agree with the code
> changes in this patch series? If so, on which branch(es) should these
> patches
> be applied? Master only or v5.8 and master?
>
> See also:
> * Add SO_BINDTODEVICE support
>   (https://sourceforge.net/p/net-snmp/patches/1296/).
> * Add Linux VRF support (https://sourceforge.net/p/net-snmp/patches/1376/
> ).
>
> Thanks,
>
> Bart.
>
> Bart Van Assche (6):
>   libsnmp/transports: Introduce netsnmp_parse_ep_str()
>   libsnmp/transports: Introduce netsnmp_sockaddr_in3() and
> netsnmp_sockaddr_in6_3()
>   libsnmp/transports: Change multiple sockaddr_in* arguments into
> netsnmp_ep
>   configure: Add a test for SO_BINDTODEVICE
>   libsnmp/transports: Add support for interface binding
>   testing/fulltests/unit-tests: Add netsnmp_parse_ep_str() unit test
>
>  configure |  34 +++
>  configure.d/config_os_misc4   |  15 ++
>  include/net-snmp/library/snmpDTLSUDPDomain.h  |   4 +-
>  include/net-snmp/library/snmpIPBaseDomain.h   |  36 +++
>  include/net-snmp/library/snmpIPv4BaseDomain.h |   7 +
>  include/net-snmp/library/snmpIPv6BaseDomain.h |   5 +
>  include/net-snmp/library/snmpTCPDomain.h  |   4 +-
>  include/net-snmp/library/snmpTCPIPv6Domain.h  |   4 +-
>  include/net-snmp/library/snmpUDPDomain.h  |   8 +-
>  .../net-snmp/library/snmpUDPIPv4BaseDomain.h  |  12 +-
>  include/net-snmp/library/snmpUDPIPv6Domain.h  |  11 +-
>  .../net-snmp/library/snmpUDPsharedDomain.h|   6 +-
>  include/net-snmp/net-snmp-config.h.in |   3 +
>  snmplib/transports/snmpDTLSUDPDomain.c|  36 +--
>  snmplib/transports/snmpIPBaseDomain.c | 114 +
>  snmplib/transports/snmpIPv4BaseDomain.c   | 118 +++--
>  snmplib/transports/snmpIPv6BaseDomain.c   | 238 --
>  snmplib/transports/snmpTCPDomain.c|  24 +-
>  snmplib/transports/snmpTCPIPv6Domain.c|  23 +-
>  snmplib/transports/snmpUDPDomain.c|  22 +-
>  snmplib/transports/snmpUDPIPv4BaseDomain.c|  58 +++--
>  snmplib/transports/snmpUDPIPv6Domain.c|  70 +++---
>  snmplib/transports/snmpUDPsharedDomain.c  |  90 ---
>  testing/fulltests/support/clib_build  |   1 +
>  .../T022netsnmp_parse_ep_str_clib.c   |  55 
>  win32/libsnmp/Makefile.in |   1 +
>  win32/libsnmp_dll/Makefile.in |   1 +
>  27 files changed, 561 insertions(+), 439 deletions(-)
>  create mode 100644 include/net-snmp/library/snmpIPBaseDomain.h
>  create mode 100644 snmplib/transports/snmpIPBaseDomain.c
>  create mode 100644
> testing/fulltests/unit-tests/T022netsnmp_parse_ep_str_clib.c
>
> --
> 2.19.1
>
>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: configure interface to send traps

[Bill Fenner]

On Thu, Oct 4, 2018 at 1:19 AM Pushpa Thimmaiah 
wrote:

> Hi All,
>
> I have understood that option 'clientAddr'  to provide source-IP address
> for outgoing traps.  There is no option to provide source-interface to send
> traps.
> Kindly let me know reason for this restriction.
>

The source IP address is all that the UNIX socket interface allows net-snmp
to control.  (There's an exception for the case that the trap receiver is
directly connected on the given interface, but when that is true, it almost
always works the way you want anyway.)

Eg: I have one physical interface 'eth1' and vlans 'eth1.101', 'eth1.102'.
> Traps sent out via eth1 by default . How can configure 'snmptrap' tool to
> use eth1.101 to send traps.
>

Configure your routing table so that packets towards the trap destination
go out eth1.101.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Bill Fenner]

On Mon, Oct 8, 2018 at 9:46 PM Bart Van Assche  wrote:

> On 10/8/18 3:00 AM, ClusterFuzz-External via monorail wrote:
>
> Status: New Owner:  CC: ma...@lysator.liu.se, bvanass...@acm.org,
> harda...@users.sourceforge.net, fen...@gmail.com, rst...@freesnmp.com
> Labels: Proj-net-snmp Type: Build-Failure New issue 10852 by
> ClusterFuzz-External: net-snmp: Build failure
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10852 The last 2
> builds for net-snmp have been failing. Build log:
> https://oss-fuzz-build-logs.storage.googleapis.com/log-8b5d8edb-027f-4a24-8603-32bc5eb09bf7.txt
> Build type: fuzzing To reproduce locally, please see:
> https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md#reproducing-build-failures
> If you have any questions, please file a bug on
> https://github.com/google/oss-fuzz/issues/new.
>
>
> In the build log I found the following:
>
> Step #4: In file included from ucd-snmp/proc.c:55:
> Step #4: ../../include/net-snmp/data_access/swrun.h:93:53: error: unknown
> type name 'netsnmp_regex_ptr'
> Step #4: int  swrun_count_processes_by_regex(char *name,
> netsnmp_regex_ptr regexp);
> Step #4: ^
>
> So it seems like ClusterFuzz has trouble with the commit I checked in
> yesterday. That's weird. If I try to build Net-SNMP locally, the build
> passes. Travis and Appveyor also seem to be fine with the regex changes.
> See also https://travis-ci.org/bvanassche/net-snmp/builds and
> https://ci.appveyor.com/project/BVanAssche87257/net-snmp/history.
>

This is because the prototype is only protected with #ifndef
NETSNMP_FEATURE_REMOVE_SWRUN_COUNT_PROCESSES_BY_REGEX and doesn't have the
"#ifdef HAVE_PCRE_H" added to it, so if you compile without HAVE_PCRE_H,
the definition of netsnmp_regex_ptr is omitted, and the definition of the
function itself is omitted, but the header still declares the prototype.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Test code review request

[Bill Fenner]

On Mon, Sep 17, 2018 at 12:58 AM Anders Wallin  wrote:

> One more thing;
> I think it would make sense to add tests for the usage of "-s $localhost"
> since this was introduced in 5.8
> e.g T184..
> #!/bin/sh
>
>
> . ../support/simple_eval_tools.sh
> HEADER Agent uses clientaddr for trapsink source
> SKIPIF NETSNMP_DISABLE_SNMPV2C
> . ./S180trapaddrinfra
> INITV4
> CONFIGAGENT trap2sink -s $localhost
> ${SNMP_TRANSPORT_SPEC}:${SNMP_TEST_DEST}${SNMP_SNMPTRAPD_PORT} public
> RUNTEST
>

Absolutely - but I'm adding these tests first in 5-7-patches and will add
the -s tests in 5-8-patches.

  Bill


>
> /Anders
>
>
> mån 17 sep. 2018 kl 06:50 skrev Anders Wallin :
>
>> Hi Bill,
>>
>> On Ubuntu using dash as default shell you get
>> # ./RUNFULLTESTS -g default -r T180
>> Agent uses clientaddr for trapsink source ..
>> /root/net-snmp/testing/fulltests/support/simple_run: 21: [: unexpected
>> operator
>> Agent uses clientaddr for trapsink source .. ok
>> All tests successful.
>> Files=1, Tests=2,  1 wallclock secs ( 0.01 usr  0.00 sys +  0.02 cusr
>> 0.01 csys =  0.04 CPU)
>> Result: PASS
>>
>> Don't use bash specific "==", use single "=" instead to avoid this
>> printout.
>>
>> Use "$localhost" in T180 and T181 instead of fixed IP's
>>
>> (Patch appended)
>>
>> Regards
>>
>> Anders
>>
>> mån 17 sep. 2018 kl 03:31 skrev Bill Fenner :
>>
>>> On Sun, Sep 16, 2018 at 12:11 AM Bart Van Assche 
>>> wrote:
>>>
>>>> On 09/13/18 10:55, Bill Fenner wrote:
>>>> > I wrote some tests for traps and clientaddr, since there were a bunch
>>>> of
>>>> > changes between 5.7 and 5.8 in this area.  I did a couple of unusual
>>>> things:
>>>> >
>>>> > 1. I factored a ton of the test code out into a support file,
>>>> > S180trapaddrinfra, since the bulk of the tests were the same.
>>>> > 2. I created a little helper, "myip", which uses IO::Socket::IP.
>>>> When I
>>>> > pushed this to travis, I found out that IO::Socket::IP isn't
>>>> "normally"
>>>> > installed.  Is it reasonable to make this a requirement, or should I
>>>> > rewrite the code to use IO::Socket::INET and IO::Socket::INET6?  (In
>>>> my
>>>> > "normal" work area, IO::Socket::INET6 isn't installed, so it's not
>>>> clear
>>>> > that this is any better).
>>>> >
>>>> > I checked in the code at
>>>> >
>>>> https://github.com/fenner/net-snmp/commit/8572a9d54873f380a2388a354ee85f5eb531c875
>>>> >
>>>> > Do these tests look ok to commit as-is or is there some better way to
>>>> > structure a group of similar tests like this?
>>>>
>>>> Is it possible to implement the Perl script such that it detects which
>>>> packages are available and uses the one that is available?
>>>> IO::Socket::INET and IO::Socket::INET6 are available on the AIX system
>>>> I
>>>> have access to but IO::Socket::IP is not available on that system. On
>>>> the FreeBSD system I have access to IO::Socket::IP is available but
>>>> none
>>>> of the other socket packages. I do not have sufficient rights to
>>>> install
>>>> additional packages on these systems.
>>>>
>>>
>>> I ended up rewriting it to use just "Socket".  The code is now:
>>>
>>> https://github.com/fenner/net-snmp/blob/V5-7-travis/testing/fulltests/support/myip
>>>
>>> so the IO::Socket::IP issue is resolved.
>>>
>>>   Bill
>>>
>>> ___
>>> Net-snmp-coders mailing list
>>> Net-snmp-coders@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>>>
>>
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Test code review request

[Bill Fenner]

On Sun, Sep 16, 2018 at 12:11 AM Bart Van Assche  wrote:

> On 09/13/18 10:55, Bill Fenner wrote:
> > I wrote some tests for traps and clientaddr, since there were a bunch of
> > changes between 5.7 and 5.8 in this area.  I did a couple of unusual
> things:
> >
> > 1. I factored a ton of the test code out into a support file,
> > S180trapaddrinfra, since the bulk of the tests were the same.
> > 2. I created a little helper, "myip", which uses IO::Socket::IP.  When I
> > pushed this to travis, I found out that IO::Socket::IP isn't "normally"
> > installed.  Is it reasonable to make this a requirement, or should I
> > rewrite the code to use IO::Socket::INET and IO::Socket::INET6?  (In my
> > "normal" work area, IO::Socket::INET6 isn't installed, so it's not clear
> > that this is any better).
> >
> > I checked in the code at
> >
> https://github.com/fenner/net-snmp/commit/8572a9d54873f380a2388a354ee85f5eb531c875
> >
> > Do these tests look ok to commit as-is or is there some better way to
> > structure a group of similar tests like this?
>
> Is it possible to implement the Perl script such that it detects which
> packages are available and uses the one that is available?
> IO::Socket::INET and IO::Socket::INET6 are available on the AIX system I
> have access to but IO::Socket::IP is not available on that system. On
> the FreeBSD system I have access to IO::Socket::IP is available but none
> of the other socket packages. I do not have sufficient rights to install
> additional packages on these systems.
>

I ended up rewriting it to use just "Socket".  The code is now:
https://github.com/fenner/net-snmp/blob/V5-7-travis/testing/fulltests/support/myip

so the IO::Socket::IP issue is resolved.

  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Test code review request

[Bill Fenner]

I wrote some tests for traps and clientaddr, since there were a bunch of
changes between 5.7 and 5.8 in this area.  I did a couple of unusual things:

1. I factored a ton of the test code out into a support file,
S180trapaddrinfra, since the bulk of the tests were the same.
2. I created a little helper, "myip", which uses IO::Socket::IP.  When I
pushed this to travis, I found out that IO::Socket::IP isn't "normally"
installed.  Is it reasonable to make this a requirement, or should I
rewrite the code to use IO::Socket::INET and IO::Socket::INET6?  (In my
"normal" work area, IO::Socket::INET6 isn't installed, so it's not clear
that this is any better).

I checked in the code at
https://github.com/fenner/net-snmp/commit/8572a9d54873f380a2388a354ee85f5eb531c875

Do these tests look ok to commit as-is or is there some better way to
structure a group of similar tests like this?

Thanks,
  Bill
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: [PATCH / request for votes] Support double byte characters

[Bill Fenner]

I agree with the concept of handling UTF-8, but I do not like this
implementation. We discussed this a couple of months ago,
https://sourceforge.net/p/net-snmp/mailman/message/36322758/

  Bill


On Mon, Jul 16, 2018 at 5:16 AM Josef Ridky  wrote:

> Net-SNMP isn't able to handle double byte characters like UTF-8.
> Though it can handle single byte characters (US-ASCII characters)
> properly, UTF-8 and ShiftJIS characters are displays as "."
>
> Steps to Reproduce:
> - Edit /etc/snmp/snmptrapd.conf and add or uncomment the following line.
>
> authCommunity log,execute,net public
>
> Start snmptrapd service.
>
> # systemctl start snmptrapd
>
> Run following command.
>
> # snmptrap -v 2c -c public localhost  ''  .1.3.6.1.4.1.8072.2.1.3
> .1.3.6.1.4.1.8072.2.1.3 s "データ"
>
> Check the /var/log/messages or journalctl
>
> Following patch brings support for double byte characters (UTF-8).
> All comments are welcome.
>
> ---
> diff -urNp old/snmplib/mib.c new/snmplib/mib.c
> --- old/snmplib/mib.c   2017-10-18 09:47:39.345569965 +0200
> +++ new/snmplib/mib.c   2017-10-18 14:05:11.237452328 +0200
> @@ -370,7 +371,31 @@ sprint_realloc_hexstring(u_char ** buf,
>  return 1;
>  }
>
> +/**
> + * Check, if given character contains value specific for UTF-8 encoding.
> + *
> + * @param cp   character to check
> + *
> + * @return 0 on failure, 2 for two-byte character, 3 for three-byte
> character
> + * and 4 for four-byte character
> + */
> +int
> +isUTF8MultiByte(const u_char cp)
> +{
> +if(cp >= 0xC2 && cp <= 0xDF){
> +return 2;
> +}
> +
> +if(cp >= 0xE0 && cp <= 0xEF){
> +return 3;
> +}
>
> +if(cp >= 0xF2 && cp <= 0xFF){
> +return 4;
> +}
> +
> +return 0;
> +}
>
>  /**
>   * Prints an ascii string into a buffer.
> @@ -396,22 +421,36 @@ sprint_realloc_asciistring(u_char ** buf
> size_t * out_len, int allow_realloc,
> const u_char * cp, size_t len)
>  {
> -int i;
> +int i, j, multibyte;
>
>  for (i = 0; i < (int) len; i++) {
> -if (isprint(*cp) || isspace(*cp)) {
> -if (*cp == '\\' || *cp == '"') {
> +if (isprint(*cp) || isspace(*cp) || isUTF8MultiByte(*cp) > 0) {
> +
> +multibyte = isUTF8MultiByte(*cp);
> +
> +if(multibyte > 0){
> +for(j = 0; j < multibyte; j++, i++) {
> +if ((*out_len >= *buf_len) &&
> +!(allow_realloc && snmp_realloc(buf, buf_len))) {
> +return 0;
> +}
> +*(*buf + (*out_len)++) = *cp++;
> +
> +}
> +} else {
> +if (*cp == '\\' || *cp == '"') {
> +if ((*out_len >= *buf_len) &&
> +!(allow_realloc && snmp_realloc(buf, buf_len))) {
> +return 0;
> +}
> +*(*buf + (*out_len)++) = '\\';
> +}
>  if ((*out_len >= *buf_len) &&
>  !(allow_realloc && snmp_realloc(buf, buf_len))) {
>  return 0;
>  }
> -*(*buf + (*out_len)++) = '\\';
> -}
> -if ((*out_len >= *buf_len) &&
> -!(allow_realloc && snmp_realloc(buf, buf_len))) {
> -return 0;
> +*(*buf + (*out_len)++) = *cp++;
>  }
> -*(*buf + (*out_len)++) = *cp++;
>  } else {
>  if ((*out_len >= *buf_len) &&
>  !(allow_realloc && snmp_realloc(buf, buf_len))) {
> ---
>
> Regards
>
> Josef Ridky
> Associate Software Engineer
> Core Services Team
> Red Hat Czech, s.r.o.
>
>
>
> --
> 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 5/9] snmplib/transports: Unbreak the MSVC build

[Bill Fenner]

On Thu, Jul 12, 2018 at 10:33 AM Bart Van Assche  wrote:

> On 07/12/18 04:59, Bill Fenner wrote:
> > I see that when it's a souce, you use "const char *", and when it's a
> > destination, you use "unsigned char *".  I understand the reason for the
> > constness difference, but is there a reason for the signedness
> difference?
>
> There is no particular reason for this difference. It would be more
> consistent to have used signed char or unsigned char in all cases.
> Anyway, changing signedness wouldn't affect the behavior of the code.
>

I agree, and wasn't trying to suggest a change, just wanted to understand
if there was something that I was missing.

Thanks,
  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 5/9] snmplib/transports: Unbreak the MSVC build

[Bill Fenner]

Hi Bart,

I see that when it's a souce, you use "const char *", and when it's a
destination, you use "unsigned char *".  I understand the reason for the
constness difference, but is there a reason for the signedness difference?

  Bill


On Thu, Jun 21, 2018 at 10:23 PM Bart Van Assche  wrote:

> Adding an integer to a void pointer works fine with gcc but not with MSVC.
> Hence convert the expressions that add an integer to a void pointer into
> a construct that is standard C.
> ---
>  snmplib/transports/snmpIPXDomain.c  | 16 ++--
>  snmplib/transports/snmpIPv4BaseDomain.c | 12 
>  snmplib/transports/snmpIPv6BaseDomain.c | 12 
>  3 files changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/snmplib/transports/snmpIPXDomain.c
> b/snmplib/transports/snmpIPXDomain.c
> index 55070476ce1e..f5753f5a788a 100644
> --- a/snmplib/transports/snmpIPXDomain.c
> +++ b/snmplib/transports/snmpIPXDomain.c
> @@ -78,9 +78,11 @@ static void netsnmp_ipx_get_taddr(struct
> netsnmp_transport_s *t,
>  netsnmp_assert(t->remote_length == sizeof(*sa));
>  *addr_len = 12;
>  if ((*addr = malloc(*addr_len))) {
> -memcpy(*addr + 0,  &sa->sipx_network, 4);
> -memcpy(*addr + 4,  &sa->sipx_node,6);
> -memcpy(*addr + 10, &sa->sipx_port,2);
> +unsigned char *p = *addr;
> +
> +memcpy(p + 0,  &sa->sipx_network, 4);
> +memcpy(p + 4,  &sa->sipx_node,6);
> +memcpy(p + 10, &sa->sipx_port,2);
>  }
>  }
>
> @@ -447,14 +449,16 @@ netsnmp_ipx_create_tstring(const char *str, int
> local,
>  static int netsnmp_ipx_ostring_to_sockaddr(struct sockaddr_ipx *sa,
> const void *o, size_t o_len)
>  {
> +const char *p = o;
> +
>  if (o_len != 12)
>  return 0;
>
>  memset(sa, 0, sizeof(*sa));
>  sa->sipx_family = AF_IPX;
> -memcpy(&sa->sipx_network, o + 0, 4);
> -memcpy(&sa->sipx_node,o + 4, 6);
> -memcpy(&sa->sipx_port,o + 10, 2);
> +memcpy(&sa->sipx_network, p + 0, 4);
> +memcpy(&sa->sipx_node,p + 4, 6);
> +memcpy(&sa->sipx_port,p + 10, 2);
>  return 1;
>  }
>
> diff --git a/snmplib/transports/snmpIPv4BaseDomain.c
> b/snmplib/transports/snmpIPv4BaseDomain.c
> index fafc1ab8045c..37ef72d4ed42 100644
> --- a/snmplib/transports/snmpIPv4BaseDomain.c
> +++ b/snmplib/transports/snmpIPv4BaseDomain.c
> @@ -251,20 +251,24 @@ void netsnmp_ipv4_get_taddr(struct
> netsnmp_transport_s *t, void **addr,
>
>  *addr_len = 6;
>  if ((*addr = malloc(*addr_len))) {
> -memcpy(*addr, &sin->sin_addr, 4);
> -memcpy(*addr + 4, &sin->sin_port, 2);
> +unsigned char *p = *addr;
> +
> +memcpy(p, &sin->sin_addr, 4);
> +memcpy(p + 4, &sin->sin_port, 2);
>  }
>  }
>
>  int netsnmp_ipv4_ostring_to_sockaddr(struct sockaddr_in *sin, const void
> *o,
>   size_t o_len)
>  {
> +const char *p = o;
> +
>  if (o_len != 6)
>  return 0;
>
>  memset(sin, 0, sizeof(*sin));
>  sin->sin_family = AF_INET;
> -memcpy(&sin->sin_addr, o + 0, 4);
> -memcpy(&sin->sin_port, o + 4, 2);
> +memcpy(&sin->sin_addr, p + 0, 4);
> +memcpy(&sin->sin_port, p + 4, 2);
>  return 1;
>  }
> diff --git a/snmplib/transports/snmpIPv6BaseDomain.c
> b/snmplib/transports/snmpIPv6BaseDomain.c
> index c4a801f87228..46f70c028cda 100644
> --- a/snmplib/transports/snmpIPv6BaseDomain.c
> +++ b/snmplib/transports/snmpIPv6BaseDomain.c
> @@ -160,21 +160,25 @@ void netsnmp_ipv6_get_taddr(struct
> netsnmp_transport_s *t, void **addr,
>
>  *addr_len = 18;
>  if ((*addr = malloc(*addr_len))) {
> -memcpy(*addr,  &sin6->sin6_addr, 16);
> -memcpy(*addr + 16, &sin6->sin6_port, 2);
> +unsigned char *p = *addr;
> +
> +memcpy(p,  &sin6->sin6_addr, 16);
> +memcpy(p + 16, &sin6->sin6_port, 2);
>  }
>  }
>
>  int netsnmp_ipv6_ostring_to_sockaddr(struct sockaddr_in6 *sin6, const
> void *o,
>   size_t o_len)
>  {
> +const char *p = o;
> +
>  if (o_len != 18)
>  return 0;
>
>  memset(sin6, 0, sizeof(*sin6));
>  sin6->sin6_family = AF_INET6;
> -memcpy(&sin6->sin6_addr, o + 0,  16);
> -memcpy(&sin6->sin6_port, o + 16, 2);
> +memcpy(&sin6->sin6_addr, p + 0,  16);
> +memcpy(&sin6->sin6_port, p + 16, 2);
>  return 1;
>  }
>
> --
> 2.17.1
>
>
>
> --
> 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

Re: net-snmp 5.8: "unknown snmp version 193" from agentx subagent

[Bill Fenner]

Oops, it turns out that the reason that it works is because the agentx
session is in the session list that is always iterated over, so, this fix
is wrong: we should just silently ignore agentx sessions in this code.
--
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: net-snmp 5.8: "unknown snmp version 193" from agentx subagent

[Bill Fenner]

On Wed, Mar 21, 2018 at 10:58 AM Bill Fenner  wrote:

> The new code in net-snmp 5.8 that tries to account for v1 or v2 trap
> sessions logs an error from an agentx subagent, since the agentx code
> registers the session as being AGENTX_VERSION_1.  This constant is only
> defined in the agentx code, so agent_trap.c doesn't know what it is.
>
> ...
>


> 3. Teach agent_trap.c about AGENTX_VERSION_ numbers.  I don't think anyone
> wants to do this, since otherwise the agentx code is encapsulated in
> mibgroup/agentx/
>

I don't know how I missed this, but it turns out agent_trap.c explicitly
knows about agentx, so my theory about this being a problem is kersplut.
This means that the fix is:

@@ -171,6 +171,9 @@ _trap_version_incr(int version)
 #ifndef NETSNMP_DISABLE_SNMPV2C
 case SNMP_VERSION_2c:
 #endif
+#ifdef USING_AGENTX_PROTOCOL_MODULE
+case AGENTX_VERSION_1:
+#endif
 case SNMP_VERSION_3:
 ++_v2_sessions;
 break;
@@ -195,6 +198,9 @@ _trap_version_decr(int version)
 #ifndef NETSNMP_DISABLE_SNMPV2C
 case SNMP_VERSION_2c:
 #endif
+#ifdef USING_AGENTX_PROTOCOL_MODULE
+case AGENTX_VERSION_1:
+#endif
 case SNMP_VERSION_3:
 if (--_v2_sessions < 0) {
 snmp_log(LOG_ERR,"v2 session count < 0! fixed.\n");

T113agentxtrap_simple tests the agentx trap sending code path, and the
traps work, so my earlier reading of the code that made me think that this
could break agentx traps was wrong.  This is just cosmetic (you can see the
"unknown snmp version 193" message in the T113 log file).  I'll commit the
fix after 5.8.

  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; request for votes] snmplib: Avoid that sprint_realloc_octet_string() triggers a segmentation fault

[Bill Fenner]

On Mon, May 21, 2018 at 11:18 AM, Wes Hardaker <
harda...@users.sourceforge.net> wrote:

> Bill Fenner  writes:
>
> > So, +1 on committing Bart's patch, because it accomplishes the goal of
> > fixing the regression, with the caveat that I really think that this
> > whole area needs to be revisited.
>
> I think this comment is spot on.  So I'd accept the patch too, though my
> gut reaction is to revert to whatever was in 5.7.1 because of the late
> point in this release cycle and we're redsigning critical code on the
> fly right before a release.
>
> We really need a test C function to check this stuff.  Any volunteers?
> (I'm not a UTF-8 expert at all)


The one I alluded to in an earlier email:
http://bjoern.hoehrmann.de/utf-8/decoder/dfa/

If we accept the dense magic, the code can be used for both "is this string
valid utf8" and "print all the valid utf8 if the last utf8-encoded
character got cut off on an octet boundary".

  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; request for votes] snmplib: Avoid that sprint_realloc_octet_string() triggers a segmentation fault

[Bill Fenner]

On Sun, May 20, 2018 at 2:25 PM, Robert Story  wrote:

> On Sun, 20 May 2018 13:06:43 -0400 Bill wrote:
> BF> I do not think that now is the time to try to deal with any of
> BF> the fundamentals, but just not regress from previous released
> BF> behavior, and deal with the underlying issue in 5.8.1 / 5.7.4.
>
> Just to clarify, do you mean
>
> a) accepts Bart's RFV patch to fix the UTF-8 patch
>
>  or
>
> b) revert the UTF-8 patch entirely an deal with the issue after a
> fuller discussion?
>
> If these are my only two options, I pick (a), since (b) results in a
regression from 5.7.1's behavior.

The original code was:

-for (x = 0; x < width && cp < ecp; x++) {
-*(*buf + *out_len) = *cp++;
-(*out_len)++;
 }
-*(*buf + *out_len) = '\0';


which is not that different from the memcpy() that Bart's patch adds.

So, +1 on committing Bart's patch, because it accomplishes the goal of
fixing the regression, with the caveat that I really think that this whole
area needs to be revisited.  My fundamental proposal is to use the one-pass
"is this utf8" predicate and "if so" memcpy, and "if not" use the ascii
print.  This ignores for now the question of an octet string that is
truncated in the middle of a UTF-8 sequence (the "t" format says "output
all the well-formed UTF-8 sequences", and my proposal would print it as
ascii with all the "."s, but we can talk about that later.  It's possible
that we could modify the "is this utf8" to say "give me the prefix that is
utf8", to fix the truncation issue.

  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; request for votes] snmplib: Avoid that sprint_realloc_octet_string() triggers a segmentation fault

[Bill Fenner]

On Sun, May 20, 2018 at 12:18 AM, Robert Story  wrote:

> On Sat, 19 May 2018 14:07:56 -0700 Bart wrote:
> BVA> strlcpy() implementations typically scan for the end of the
> BVA> source argument passed to strlcpy(). Hence avoid passing an
> BVA> unterminated string to strlcpy().
>
> I'm going to say -1, but for the patch and not the need to fix the
> issue.
>
> This code is treating 'a' and 't' hints the same. There should
> never be UTF-8 in an ascii string. Why not revert back to the
> original code for 'a' case and put UTF-8 handling where it belongs,
> under the 't' case.
>

There's a much longer discussion to be had here, one hint at how complex
the discussion will get is that RFC2571 says that SnmpAdminString is
"encoded as an octet  string using the UTF-8 transformation" and has a
DISPLAY-HINT of "255a".  So, does "a" mean UTF-8 or ASCII or is it
fundamentally a little indeterminate due to ancient mistakes and current
conventions?

My personal feeling is that if a string is valid UTF-8 (which can be
determined in one pass using the algorithm I pointed to in the bug), it
should be output as-is, whether the DISPLAY-HINT is "a" or "t".  We should
protect against not just NUL bytes as the current code does but also
control characters (e.g., if there's an embedded "\n" in the string, will
that foil a future log parser that's trying to do line-based parsing of a
log file?).

I do not think that now is the time to try to deal with any of the
fundamentals, but just not regress from previous released behavior, and
deal with the underlying issue in 5.8.1 / 5.7.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]

On Thu, May 17, 2018 at 9:56 AM, Niels Baggesen via Net-snmp-coders <
net-snmp-coders@lists.sourceforge.net> wrote:

> Den 17-05-2018 kl. 15:54 skrev Robert Story:
>
>> On Wed, 16 May 2018 07:23:32 -0700 Bart wrote:
>> BVA> This patch makes it possible to enable Travis and Appveyor
>> BVA> continuous integration support. On Travis Net-SNMP is built
>> BVA> with all MIBs, with --disable-set-support, with
>> BVA> --enable-mini-agent, with --enable-minimalist and with
>> BVA> --enable-read-only. All these configurations are built on
>> BVA> Linux and on OS/X. On Appveyor Net-SNMP is built with MSVC and
>> BVA> dynamic libraries, with MSVC and statically linked libraryes,
>> BVA> with MinGW64, with Cygwin32 and with Cygwin64. As one can see
>> BVA> in the scripts in the "ci" directory the to-do items are as
>> BVA> follows:
>>
>> Given that this doesn't affect code and CI support is a good thing:
>> +1
>>
>
> Another +1


I'm a big fan of automated testing, and I've looked at the scripts and
output.  +1 from me too!

  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: RFC: fix --enable-read-only build failure due to snmpping

[Bill Fenner]

On Tue, May 15, 2018 at 9:40 PM, Robert Story  wrote:

> On Wed, 16 May 2018 03:13:34 +0200 Magnus wrote:
> MF> > Yes, but it doesn't break for a default configure, which is
> MF> > the criteria for a show stopper in the RC phase. Of course +3
> MF> > votes for anything is an automatic show stopper too, so we're
> MF> > one vote away from that.
> MF>
> MF> +1
>
>
> I seriously doubt we'll get another -1 vote, so Bill you are go for
> launch.
>
> Done, thanks.

  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: RFC: fix clientaddr for 5.8

[Bill Fenner]

I got myself confused again with the rewritten transport code. "Applying
the patch to 5.8" is nonsense, so, nevermind this request.

  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

RFC: fix --enable-minimalist build failure due to target MIB

[Bill Fenner]

When I was looking at the master travis results, I saw that
--enable-minimalist was broken since the target MIB started using
netsnmp_compare_mem() without requiring the feature.  This change unbreaks
it:

https://github.com/fenner/net-snmp/commit/be725381766a60b16ef32a14378cda0fdbaecd23

  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: On the nature of backward comparability

[Bill Fenner]

On Tue, May 15, 2018 at 11:33 AM, Wes Hardaker via Net-snmp-coders <
net-snmp-coders@lists.sourceforge.net> wrote:

> 3) --enable-minimalist is an interesting one that is also designed for
>code reduction in that one section of code can declare the need for a
>function, and if and only if that function is needed by something
>else will it be included.  If you want a really reduced code base for
>auditing, security, etc, this is the flag that will get you the
>farthest there.
>

And it constantly breaks (it's broken again in master), this time in mib
modules that I don't use so only noticed when I started poking at the
travis results because of Bart's report about snmpping.

  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

RFC: fix --enable-read-only build failure due to snmpping

[Bill Fenner]

Since snmpping requires set support, it should be conditional.  My proposed
patch is

https://github.com/fenner/net-snmp/commit/b6e69f9ccbadcb7d4a49a4a6020ef932e84bbc5c

The build with --enable-read-only now succeeds, as can be seen by the fact
that we got to tests:

https://travis-ci.org/fenner/net-snmp/jobs/379261972#L

so I'm requesting permission to cherry-pick this commit into master for 5.8.

  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

snmpping doesn't build with --enable-read-only

[Bill Fenner]

On Tue, May 15, 2018 at 9:58 AM, Bart Van Assche  wrote:

> Even if I do not enable any additional MIBs building with
> --enable-read-only fails on the master branch:
>
> snmpping.c: In function ‘cleanup_ctlTable’:
> snmpping.c:276:27: error: ‘SNMP_MSG_SET’ undeclared (first use in this
> function)
>  pdu = snmp_pdu_create(SNMP_MSG_SET);
>^
> snmpping.c:276:27: note: each undeclared identifier is reported only once
> for each function it appears in
>
> Is this a known issue?
>

Whoops, I messed up when introducing snmpping to the Makefile; it should be
protected with NETSNMP_BUILD_SET_PROG_TRUE/FALSE instead of being added to
the list unconditionally.  I'll prepare a patch to propose.

  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

RFC: fix clientaddr for 5.8

[Bill Fenner]

I've committed the following fix to the 5.7-patches branch:

https://sourceforge.net/p/net-snmp/code/ci/3defab66a7aee60ba582a8254412abd2e630c321/

It turns out that when you specify a clientaddr, the steps the function
takes are:

- zero out addr_pair
- store the remote address in addr_pair
- lookup the clientaddr
- zero out addr_pair
- store the clientaddr in addr_pair

The second zeroing out (added in cea974008da30de8d39a1f8ede7189265d93d598)
results in the remote address being 0.0.0.0, which results in simply
getting an error from sendto because you can not send to 0.0.0.0.

I'd like to merge this to master so that sessions using clientaddr work in
the 5.8 release.

Thanks,
  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: RFC: "-@" command line argument to set clientaddr per request/session

[Bill Fenner]

On Sun, May 6, 2018 at 7:33 PM, Bill Fenner  wrote:

> On Sun, May 6, 2018 at 4:33 PM, Robert Story  wrote:
>
>> BF> The tests:
>> BF> https://github.com/fenner/net-snmp/commit/41be11b4e3ab93cda3
>> 76bf044de2f77534b56518
>> BF> (T180 and T181 fail. T181 is testing the new functionality in
>> BF> 5.8, so, no biggie.  T180 tests functionality that worked in
>> BF> 5.7.3.  T182 and T183 pass; this maybe makes the other failures
>> BF> less bad since if a user wants this behavior they can configure
>> BF> the session using trapsess instead of trap*sink).
>> BF> (I think the "myip" perl script belongs in support, not in
>> BF> fulltests/default/; I'll move it before i commit to the master
>> BF> branch.)
>>
>> I'm going to skip these for rc1. What do we need to make the tests
>> pass?
>>
>
> T182 and T183 should pass now.  T180 and T181 failures have the same root
> cause: netsnmp_udpipv4base_tspec_transport() doesn't zero out the default
> "161" port that netsnmp_sockaddr_in2() fills in.  Compare the code
> in netsnmp_udpipv4base_transport() that's checking the clientaddr for
> having a port, and zeroes it out if not (the "have_port" check).  There is
> no similar code in netsnmp_udpipv4base_tspec_transport().
>
> One plausible answer is to factor out the code in
> netsnmp_udpipv4base_transport() (although I am dubious of
> NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT code, and don't think that should be
> copied to the tspec_transport() case).
>

I rewrote the tests and ran them against 5.7-patches, and, to my surprise,
they all failed.  I ran them against 5.7.3 itself and 3/4 worked:

Agent uses clientaddr for trapsink source . ok
Agent uses clientaddr for v6 trapsink source .. 1/?
not ok 1 - found 0 copies of 'UDP6: \[::1\]:[0-9]*->' in output
(/tmp/snmp-test-T181trap2sinkclientaddr6_simple-36979/snmptrapd.log);
expected 1
Agent uses clientaddr for v6 trapsink source .. Dubious, test returned 1
(wstat 256, 0x100)
Failed 1/2 subtests
Agent uses clientaddr for trapsess source . ok
Agent uses clientaddr for v6 trapsess source .. ok

I hope that 5.8 should be able to do at least as well on these tests as
5.7.3.  I will try to look at this tonight but my concussion is really
slowing me down.

  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: RFC: "-@" command line argument to set clientaddr per request/session

[Bill Fenner]

On Sun, May 6, 2018 at 4:33 PM, Robert Story  wrote:

> BF> The tests:
> BF> https://github.com/fenner/net-snmp/commit/
> 41be11b4e3ab93cda376bf044de2f77534b56518
> BF> (T180 and T181 fail. T181 is testing the new functionality in
> BF> 5.8, so, no biggie.  T180 tests functionality that worked in
> BF> 5.7.3.  T182 and T183 pass; this maybe makes the other failures
> BF> less bad since if a user wants this behavior they can configure
> BF> the session using trapsess instead of trap*sink).
> BF> (I think the "myip" perl script belongs in support, not in
> BF> fulltests/default/; I'll move it before i commit to the master
> BF> branch.)
>
> I'm going to skip these for rc1. What do we need to make the tests
> pass?
>

T182 and T183 should pass now.  T180 and T181 failures have the same root
cause: netsnmp_udpipv4base_tspec_transport() doesn't zero out the default
"161" port that netsnmp_sockaddr_in2() fills in.  Compare the code
in netsnmp_udpipv4base_transport() that's checking the clientaddr for
having a port, and zeroes it out if not (the "have_port" check).  There is
no similar code in netsnmp_udpipv4base_tspec_transport().

One plausible answer is to factor out the code in
netsnmp_udpipv4base_transport() (although I am dubious of
NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT code, and don't think that should be
copied to the tspec_transport() case).

  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: RFC: "-@" command line argument to set clientaddr per request/session

[Bill Fenner]

On Fri, May 4, 2018 at 5:10 PM, Robert Story  wrote:

> On Fri, 4 May 2018 11:40:21 -0400 Bill wrote:
> BF> I apologize for mis-speaking.  I meant, session.localname,
> BF> which is used in _sess_open() as follows:
> BF>
> BF> https://sourceforge.net/p/net-snmp/code/ci/master/tree/
> snmplib/snmp_api.c#l1629
>
> Ok, thanks for the pointer. So right now the only use of localname
> appears to be from netsnmp_create_v1v2_notification_session().
>

I hadn't actually looked at where else it had been used - just at the fact
that it appeared in the API and had the desired effect.

I think feature parity is a good thing. How close are you to having
> this patch ready? I'd say create a branch for it and push it to teh
> SF or github repo. Seeing the actual patch will help me form my
> opinion on rc1 (maybe if you're quick), 5.8.1 (seams reasonable,
> but does it change any existing ABI?), or 5.9.
>

The patch:
https://github.com/fenner/net-snmp/commit/28144b2831ab544ea9e63e2b9585d1f1d58422ad
A couple of trivial lines in snmp_parse_args, plus an exact replica of the
code from _sess_open in agent_trap.c.
(Both this code and the code in _sess_open could be made simpler by using
the new struct-based transport interface, since that allows specifying a
source address in that API, but
a) it's too close to the release for a change like this;
b) I think that API is why the trap*sink stuff is broken anyway
)
The only difference between this patch and the one that we've been using
for years is the use of "s" instead of "@" for the argument character,
since that's what the trap*sink parser uses.

The tests:
https://github.com/fenner/net-snmp/commit/41be11b4e3ab93cda376bf044de2f77534b56518
(T180 and T181 fail. T181 is testing the new functionality in 5.8, so, no
biggie.  T180 tests functionality that worked in 5.7.3.  T182 and T183
pass; this maybe makes the other failures less bad since if a user wants
this behavior they can configure the session using trapsess instead of
trap*sink).
(I think the "myip" perl script belongs in support, not in
fulltests/default/; I'll move it before i commit to the master branch.)

The bugfix:
T182 fails without
https://github.com/fenner/net-snmp/commit/f714d0a7790c477f63e5f56f65a922c0c460432a

These tests all need IPv6 versions, too.  And the bug2864 fix needs an IPv6
variant.

  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 Fri, May 4, 2018 at 5:20 PM, Robert Story  wrote:

> On Fri, 4 May 2018 11:25:35 -0400 Bill wrote:
> BF> My proposed fix works for my trapsess case, so I guess that's
> BF> something. Should I commit the broken tests so anyone else who
> BF> wants to try to fix the trap*sink code has a starting point?
> BF> Is the "specifying clientaddr and trap*sink together fails"
> BF> regression a release blocker or just something to release-note?
>
> I don't want to add any release blockers at this point. Maybe
> commit the test to a branch? If you get it working before 5.8
> final I'd vote for inclusion.


To be clear, it's the functionality that's broken, not the test.  My
T180trap2sinkclientaddr_simple works on 5.7.3 and fails on
5.8.  T182trapsessclientaddr_simple works on both after my
fix.  T181trap2sinksourceaddr_simple tests functionality that was
introduced in 5.8, but was broken.  The T180 and T181 are broken for the
same reason in 5.8, with the new code.

If these are not release blockers, that's fine: clientaddr + trap session
is probably a little unusual.  The result is that traps will be broken in
5.8 for this case.  The fact that a new feature is also broken is not that
big a deal, I guess, since nobody is depending on it to work.  But it may
be worth marking the broken behavior in the release notes, and maybe
opening up a bug, so that users who want this behavior will have more
information about it, and will know not to bother trying the new feature.

  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 Fri, May 4, 2018 at 11:25 AM, Bill Fenner  wrote:

> Should I commit the broken tests so anyone else who wants to try to fix
> the trap*sink code has a starting point?
>
> Here are the tests:

https://github.com/fenner/net-snmp/compare/master...fenner:trapsourcetests?expand=1

T182 works with the change to the return value check, but T180 and T181 do
not (because they end up using port 161).

  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: RFC: "-@" command line argument to set clientaddr per request/session

[Bill Fenner]

On Fri, May 4, 2018 at 12:06 AM, Robert Story  wrote:

> On Thu, 3 May 2018 14:29:09 -0400 Bill wrote:
> BF> On Thu, May 3, 2018 at 1:07 PM, Robert Story
> BF>  wrote:
> BF> Depends on at what level you are looking at the functionality.
> BF> -@ would set session.localaddr, which is a little different
> BF> than setting clientaddr.
>
> Can you be more specific about the difference? I don't see a
> localaddr field in the netsnmp_session structure.
>

I apologize for mis-speaking.  I meant, session.localname, which is used in
_sess_open() as follows:

https://sourceforge.net/p/net-snmp/code/ci/master/tree/snmplib/snmp_api.c#l1629

My change includes a combination of allowing setting session.localname in
snmp_parse_args(), and using it when opening the session in agent_trap.c by
temporarily setting NETSNMP_DS_LIB_CLIENT_ADDR in the same way that
_sess_open() does.  (This is what led me to discover that 5.8 broke
NETSNMP_DS_LIB_CLIENT_ADDR).

I'm inclined to say it's too late, it being the day before rc1


I've been using and testing this code in EOS for 3 years, so it's not that
it's a brand new idea asking to get into rc1.  There could be better
timing, sure, but this all unraveled from me doing a better job of looking
at Arista's test results because rc1 is coming up, and finding that
clientaddr is just broken.

and
> it mainly being a feature for testing.


I apologize for being unclear about the goal here.  The goal is to allow
specifying a source address in a trap session created with the "trapsess"
configuration command.  The implementation that I chose allows using it for
testing too, but that's really secondary to the goal.

5.8 introduces the ability to do this with "trap*sink" (although as
mentioned in the other thread, it seems to be broken).  But it's not
possible to configure SNMPv3 trap sinks with the "trap*sink" commands, so
EOS configures all of its trap destinations with "trapsess".

If this is too esoteric, and it's not desirable to give "trapsess" feature
parity with "trap*sink", I can keep this patch local to Arista. Or maybe
since it's "feature parity" and not "new feature" it can go into 5.8.1.  Or
I can hold onto it for 5.9.

  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 Fri, May 4, 2018 at 12:08 AM, Robert Story  wrote:

> On Thu, 3 May 2018 14:32:40 -0400 Bill wrote:
> BF> > On Wed, 2 May 2018 11:08:44 -0400 Bill wrote:
> BF> > BF> I just filed
> BF> > BF> https://sourceforge.net/p/net-snmp/bugs/2864/ :
> BF> > BF> "clientaddr" doesn't work to set the source address for
> BF> > BF> traps any more.  (And given that the code path is the
> BF> > BF> same, I suspect it doesn't work for client requests
> BF> > BF> either).  This is a regression against 5.7.3; that code
> BF> > BF> has been restructured so it's not surprising that
> BF> > BF> something has changed.
> BF> >
> BF> > I think the fix you found looks right. Does it work in your
> BF> > testing?
> BF>
> BF> Yes, and v6 needs the same fix, and it looks like there are
> BF> other calls to the address parsers that make the wrong
> BF> assumption about the return value. I have an idea about adding
> BF> tests for traps, so that we could test "clientaddr" and the
> BF> "trapsink" family of session creations with their "-s"
> BF> arguments, but I don't know how to invoke the other
> BF> mechanisms.  Although, maybe a unit test would be better for
> BF> this, to invoke the transport creation with clientaddr set, or
> BF> with seession.localaddr set, or by setting ->source in the
> BF> transport config, and making sure that the expected value is
> BF> filled in in the returned session.
>
> I'm probably not going to hold up rc1 for this, but fixing other
> address parsers handling of the return code is something I'd vote
> for allowing after rc1.
>

I started writing a test for this, and found that it's seriously
convoluted.  The combination of clientaddr + trap*sink results in the
bind() attempting to use port 161 for the clientaddr, so it doesn't work as
non-root (in the test context) and would either not work as root or
intercept actual SNMP packets destined for the given address.  The same
happens with the "-s" argument for the trap2sink command.

My proposed fix works for my trapsess case, so I guess that's something.
Should I commit the broken tests so anyone else who wants to try to fix the
trap*sink code has a starting point?  Is the "specifying clientaddr and
trap*sink together fails" regression a release blocker or just something to
release-note?

  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, May 3, 2018 at 12:53 PM, Robert Story  wrote:

> On Wed, 2 May 2018 11:08:44 -0400 Bill wrote:
> BF> I just filed https://sourceforge.net/p/net-snmp/bugs/2864/ :
> BF> "clientaddr" doesn't work to set the source address for traps
> BF> any more.  (And given that the code path is the same, I suspect
> BF> it doesn't work for client requests either).  This is a
> BF> regression against 5.7.3; that code has been restructured so
> BF> it's not surprising that something has changed.
> BF>
> BF> I poked around a little and couldn't find a smoking gun.  This
> BF> is a showstopper for my application: we can't use 5.8 as is
> BF> with this bug - but that doesn't necessarily mean that the
> BF> project can't go ahead with the release, there are other needs
> BF> than mine.
>
> I think the fix you found looks right. Does it work in your testing?


Yes, and v6 needs the same fix, and it looks like there are other calls to
the address parsers that make the wrong assumption about the return value.
I have an idea about adding tests for traps, so that we could test
"clientaddr" and the "trapsink" family of session creations with their "-s"
arguments, but I don't know how to invoke the other mechanisms.  Although,
maybe a unit test would be better for this, to invoke the transport
creation with clientaddr set, or with seession.localaddr set, or by setting
->source in the transport config, and making sure that the expected value
is filled in in the returned session.

  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: RFC: "-@" command line argument to set clientaddr per request/session

[Bill Fenner]

On Thu, May 3, 2018 at 1:07 PM, Robert Story  wrote:

> On Wed, 2 May 2018 11:49:46 -0400 Bill wrote:
> BF> Is it too late to add this? This occurs to me just because it’s
> BF> an easier way to test the transports’ support of clientaddr, by
> BF> being able to set clientaddr dynamically via the command line,
> BF> and I just noticed that this is broken in 5.8.
>
> This would duplicate functionality.. Pretty much any config option
> can be set on the command line using '--TOKEN-VALUE'. e.g.
>
>
>  snmpget [...] --clientaddr=192.168.1.111 [...]
>

Depends on at what level you are looking at the functionality.  -@ would
set session.localaddr, which is a little different than setting
clientaddr.  In the sense of "how does my request look" when focusing on
the snmpget invocation, it's the same.  In the sense of "how do I set the
local source for a trapsess", it's different.

Since the v1/v2 trap sink commands have gained a "-s" argument, it might be
better to call this "-s" too instead of "-@".

  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]

I just filed https://sourceforge.net/p/net-snmp/bugs/2864/ : "clientaddr"
doesn't work to set the source address for traps any more.  (And given that
the code path is the same, I suspect it doesn't work for client requests
either).  This is a regression against 5.7.3; that code has been
restructured so it's not surprising that something has changed.

I poked around a little and couldn't find a smoking gun.  This is a
showstopper for my application: we can't use 5.8 as is with this bug - but
that doesn't necessarily mean that the project can't go ahead with the
release, there are other needs than mine.

  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]

On Fri, Apr 27, 2018 at 12:15 PM, Keith Mendoza  wrote:

> Bill,
>
> On Thu, Apr 26, 2018, at 6:54 PM, Bill Fenner wrote:
> > 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.
>
> Would it be worth it to update RUNFULLTEST or T154dismanpingmib_simple to
> only run on Linux?
>

 T154dismanpingmib_simple runs if the module is compiled in (e.g.,
--with-mib-modules=disman/ping), which it isn't by default.

  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

RFC: "-@" command line argument to set clientaddr per request/session

[Bill Fenner]

I’ve got a local patch that’s been hanging around for a long time to set
session.localaddr from an -@ command line argument. The use case is a bit
esoteric, but has been mentioned a couple of times on the lists: the
existing clientaddr configuration has only one value, so we can’t set
values for IPv4 and IPv6. (And, an even more esoteric case, when you have
trap destinations in different VRFs, you have to be able to set different
source addresses even for the same IP address family.)

It’s paired with a patch that modifies NETSNMP_DS_LIB_CLIENT_ADDR around the

transport = netsnmp_transport_open_client("snmptrap", session.peername);

in the same way that _sess_open() does.

(Yes, source address specification was added to the *sink directives, but
that doesn’t help v3 sessions.)

Is it too late to add this? This occurs to me just because it’s an easier
way to test the transports’ support of clientaddr, by being able to set
clientaddr dynamically via the command line, and I just noticed that this
is broken in 5.8.

Thanks,
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 Fri, Apr 27, 2018 at 6:36 PM, Robert Story  wrote:

> On Thu, 26 Apr 2018 22:07:27 -0400 Bill wrote:
> BF> >>> (The context is that the library now tries to suppress
> BF> >>> converting traps from v1 to v2 or vice versa if there is no
> BF> >>> trap sink of the right type, but, it does not know how to
> BF> >>> treat agentx sessions so doesn't count them - so if there's
> BF> >>> only an agentx session open it may not send *any* traps
> BF> >>> since it "knows" there are no v1 or v2 trap sessions open)
>
> Drat. I should have added a log message when neither matched.
>

That's how I noticed. "Unknown SNMP version 193".

BF> It's plausible that a workaround as simple as
> BF>
> BF> +/*
> BF> + * We lie about being SNMPv3, because ...
> BF> + */
> BF>  if (add_trap_session(main_session, AGENTX_MSG_NOTIFY, 1,
> BF> - AGENTX_VERSION_1)) {
> BF> + SNMP_VERSION_3)) {
> BF>
> BF> would work.  (I picked V3 because you can't disable it, unlike
> BF> v2c.)  I also didn't feel like writing the rest of the
> BF> comment :-)
>
> Hmm.. I'm not a fan of lying if it's avoidable... The fix should be
> to recognize the agentx sessions properly...


Well, the rest of the system doesn't know anything about agentx, it's all
encapsulated inside of mibgroup/agentx.  That certainly makes lying the
easier solution.

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