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