[Pkg-torrus-maintainers] Bug#715365: Bug#715365: torrus-common: Please backport the upstream SNMPv1 fixes

[Bernhard Schmidt]

Control: tag 715365 + patch
Control: fixed 715365 2.07-1

On Mon, Jul 08, 2013 at 01:53:45PM +0200, Andre Beck wrote:

Hello Andre,

thanks for your detailled bugreport...

> please backport Commit 5985de2ace378ff8179ab9229470bd321728d061 (Bugfix
> in walkSnmpTable(): maxrepetitions is only applicable in SNMPv2 or v3) and
> Commit 2f468f3e0aef02657b066baa98504dc98e841888 (Bugfix in collector:
> maxrepetitions is unsupported in SNMPv1) as found in
> git://torrus.git.sourceforge.net/gitroot/torrus/torrus to stable.
> 
> Rationale:
> 
> These patches are essential for proper operation of Torrus (as supplied in
> Wheezy) against SNMPv1-only targets. Without these patches, the following
> symptoms may be observed:
> 
> 1) cbQoS will never start to fill graphs with data. It *is* discovering
>    the QoS trees correctly, but will never collect them from targets
>    through SNMP (note that this isn't limited to v1 targets), and graphs
>    will show NaN values forever.
> 
> 2) SNMPv1 targets will neither discover nor collect the ifTable tree.
>    This also stops interface mapping from ever completing, which in
>    turn causes (1) as the cbQoS collector in this version will not start
>    up for a target when the number of open mapping sessions isn't zero.
>    As soon as one SNMPv1 target was encountered, no more targets will have
>    their cbQoS collection started, the exact impact of which depends a lot
>    on the actual trees and targets and their sequence of initialization.
>    In my case, two out of several hundred targets still had live cbQoS
>    data...
> 
> Please note that (1) is probably also fixed by Commit
> 13ce4e222408ca89c786a903ffed39d737f81bf1 (Bugfix in cbQoS collector
> initialization) which generally changes collection to start for an individual
> target as soon as that target has completed interface mapping. In this case,
> that is a fix for cbQoS startup being hampered by unreachable devices which
> prevent interface mapping from ever terminating in much the same way as the
> SNMPv1 issues do. I had, however, some difficulties in backporting that
> commit to 2.03 as found in Wheezy, given it is based on a way newer codebase.
> 
> The patches from 5985de2ace378ff8179ab9229470bd321728d061 and
> 2f468f3e0aef02657b066baa98504dc98e841888, on the other hand, apply
> cleanly and are "obviously right", so there should not be any problem
> with backporting them.

Makes sense. I will try to whip up a fixed package over the weekend,
maybe we can get it into a point-release (never done that before).

Thanks,
Bernhard