I have noticed strange behavior for SNMP::TrapSession on SNMPv3.
It seems that unlikely command-line utilities and the C library interface,
Perl XS wrapper doesn't initialized session structure with default values.
The reason for it seems to be that the structure is filled in by input values,
however, it makes the difference in behavior of the wrapper and command-line utilities.
Function snmp_sess_init fills-in value for netsnmp_session.flags = SNMP_FLAGS_DONT_PROBE.
If this flag is not set, some traps sent by SNMPv3 protocol can take longer time to send than expected.
This is associated with value of timeout and number of retries, which may serve as a workaround for older versions.
Hasn't this already been fixed by commit [56287c139e56] ("Perl: Initialize session objects correctly"; v5.8)?
Oh, well, seems to be it. I probably haven't checked upstream.
I'm utilizing CentOS 7.4 which has 5.7.3.
Since it is marked as LTS(http://www.net-snmp.org/download.html) can you backport this patch there just in case?
Commit [56287c139e56] has been backported to the v5.7 branch. Please
have a look.
Well, okay but the tarball isn't updated & this seems to be the cause why Red Hat is not concerned with this.
Aside from usage of Perl of cource.
Is only 5.7.3 are LTS or the whole 5.7 branch?
What I mean is can you release yet another version of this branch so that update will come to maintainers in better form than a patch?
P.S. Sorry, got distracted
The information on the downloads page is outdated. The v5.7 branch has been an LTS branch but no new v5.7.x releases are planned. I will see whether I can update the downloads page.
BTW, Red Hat shouldn't ignore the V5-7-patches branch.
Any way to notify them?
I think I figured out how to update
http://www.net-snmp.org/download.html.
Can you have another look at that page?
Seems clear now that 5.7.3 is not supported anymote but that doesn't clear the idea of LTS release. Is there still support for this release or not?
If not, how can I trigger RedHat to update package of this branch?
I'm not sure what the best approach is to grab Red Hat's attention. Last
time I was working with RHEL I had to work with a Technical Account
Manager to make sure that the bugs we had reported got proper attention.
See also
https://www.redhat.com/en/services/support/technical-account-management.