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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
