[Pkg-net-snmp-devel] bug #575810 and suggested change to patch

Corey Wright undefined at pobox.com
Sat Nov 20 22:47:09 UTC 2010


i believe that the patch for net-snmp bug #575810 should have included:

-+                    (subfeature->mapping == 0) &&
++                    (subfeature->type == (feature->type << 8)) &&

i agree with the bug report that "subfeature->mapping == 0" causes snmpd to
only report on the first feature, but the suggested/accepted patch should
cause all subfeatures of all features to be reported, which is definitely
not the historical behavior of snmpd.

now every subfeature (eg fan1_input, fan1_min, fan1_div & fan1_alarm) of
every feature (eg fan1) is reported, and to a casual observer they are
indistinguishable in the snmpd output because they are only identified with
the feature's name (eg "fan1"; ie "label = sensors_get_label(chip,
feature)").

what i believe was intended by the original code (ie "subfeature->mapping
== 0") was that only the first subfeature of each feature would be reported
(eg fan1_input), because that's the historical output of snmpd and the
primary output of the sensors command (eg the other subfeatures are printed
following fan1_input and within parens).

a quick "hack" to enable that functionality is "subfeature->type ==
(feature->type << 8)".  this is based off how sensors.h (lines 148-204)
spaces the subfeatures (line 148: "All the sensor types (in, fan, temp,
vid) are a multiple of 0x100 apart") and how that is based off the
associated feature (line 151: "SENSORS_SUBFEATURE_IN_INPUT =
SENSORS_FEATURE_IN << 8").

a more thorough patch would probably be logic similar to the sensors
command (ie for every feature [fan1] query what type it is
[SENSORS_FEATURE_FAN] and pull the appropriate subfeature by name
[SENSORS_SUBFEATURE_FAN_INPUT]), but that patch is much more invasive, but
it could also probably eliminate the imperfect guessing of feature type by
label (ie lmSensors.c, lines 973-996; eg "if (strstr(label, "V")) type =
VOLT_TYPE;").

FULL DISCLOSURE: i have not tested my suggested change to the snmpd package
in debian squeeze (5.4.3~dfsg-1), but instead the snmpd package in ubuntu
lucid (5.4.2.1~dfsg0ubuntu1-0ubuntu2.1, after applying the patch attached
to the #575810 bug report).

i run debian lenny on my servers and workstations (which does not exhibit
this problem) and ubuntu lucid on my desktops/laptops/netbooks.  the lucid
snmpd package only reports the first subfeature (as documented in
#575810).  after applying #575810's patch, snmpd reports all subfeatures.
#after applying my above suggested change, snmpd functions the same as with
#lenny only reporting the *_INPUT/first/primary subfeature.  as i don't
#have a squeeze installation to test, i've reviewed squeeze's net-snmp
#changelog and see no other change mentioned (besides #575810) that should
#address the behavior i'm seeing in the ubuntu package.

thanks to ISHIKAWA Mutsumi for the bug report and initial patch and the
Net-SNMP Packaging Team for providing debian's snmpd package and being
ubuntu's upstream.

corey
-- 
undefined at pobox.com



More information about the Pkg-net-snmp-devel mailing list