Re: 5.8 testing status

On Fri, Apr 27, 2018 at 6:36 PM, Robert Story <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders