On Thu, May 3, 2018 at 12:53 PM, Robert Story <rst...@freesnmp.com> 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
