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

On Fri, May 4, 2018 at 12:06 AM, Robert Story <[email protected]> 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> <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders