Re: 5.8 testing status

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