Hi Jurij!
On So, 07 Aug 2005, Jurij Smakov wrote:
> Package: libnet-snmp-perl
> Version: 5.1.0-1
> Severity: normal
> 1.3.6.1.2.1.31.1.1.1.19.3 = TimeTicks: 0.00 seconds
> 1.3.6.1.2.1.31.1.1.1.19.3 = endOfMibView: endOfMibView
> Note an extra space, added to the last OID. It confuses the application
> I maintain, and it seems like it should not be there. Looking at
> ethereal dump of the communication between libnet-snmp-perl and snmpd
> for this command, I don't immediately see anything suspicious. The last
> part of response to GETBULK request (decoded by ethereal) looks like
> that:
>
> [...]
> Object Identifier 6: 1.3.6.1.2.1.31.1.1.1.19.3
> Value: TIMETICKS: 0 (0)
> Object Identifier 6: 1.3.6.1.2.1.31.1.1.1.19.3
> Value: ENDOFMIBVIEW: end of mib view
>
> The last OID is immediately followed by hex value of 82 00, signalling
> the ENDOFMIBVIEW condition, so it does not look like it's snmpd's fault.
> I would be glad to provide further debugging information.
This seems to be intended upstream. it is generated in Net::SNMP::PDU
_prepare_var_bind_list():
# Populate the "var_bind_*" data so we can provide consistent
# output for the methods regardless of whether we are a request
# or a response PDU. Make sure the HASH key is unique if in
# case duplicate OBJECT IDENTIFIERs are provided.
while (exists $this->{_var_bind_list}->{$name_value}) {
$name_value .= q{ }; # Pad with spaces
}
Since the OIDs are keys of a hash, the duplicate OID as above would
cause trouble. To work around this, the second instance of
1.3.6.1.2.1.31.1.1.1.19.3 is suffixed by the whitespace.
To work around this, just strip off the trailing space(s) from the OID
when iterating over var_bind_names() keys. Maybe I should do this for
all examples.
Tschoeeee
Roland
