Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SNMP Plugin making wrong interpretation data type #50

Closed
ghost opened this issue Mar 10, 2012 · 1 comment
Closed

SNMP Plugin making wrong interpretation data type #50

ghost opened this issue Mar 10, 2012 · 1 comment

Comments

@ghost
Copy link

ghost commented Mar 10, 2012

Hello, i am using collectd (4.8.2-1ubuntu0.1) to graph informations from my HP Procurve switches using collectd snmp plugin. One of the data i am collecting is the uptime.

<Plugin snmp>
        <Data "procurve_uptime">
                Type "uptime"
                Table false
                Values ".1.3.6.1.2.1.1.3.0"
                Scale 0.01
        </Data>
        <Host "HP5406zl-2">
                Address "xxx.xxx.xxx.xxx"
                Version 2
                Community "public"
                Collect "procurve_uptime" 
        </Host>
</Plugin>

SysUpTime (.1.3.6.1.2.1.1.3.0) is a 32 bit value and snmp plugin should be able to get value from 0 to 4294967295 (uptime data type is defined like this).

I can get the correct values from most of Procurve Switches (using csv plugini can see positive values) but on somes switches with highest uptime (using snmpwalk i get 2367115384 which is far less than 4294967295) collectd snmp plugin is making a wrong interpretation of the data type and csv plugin shows negatives values.

may this be a bug?.........

thanks

@octo
Copy link
Member

octo commented Mar 11, 2012

The problem is that we do not keep track of the signedness of the original ASN/SNMP value and then need to cast to a double. The code unconditionally uses the signed interpretation, which breaks for numbers larger than 2^31-1. I'll prepare a patch for this.

octo added a commit that referenced this issue Mar 11, 2012
Prior to this, the signed variant was used when casting to gauge_t. This caused
problems with values larger than 2^31-1, since they were casted to negative
values.

Hopefully fixes GitHub issue #50.
@octo octo closed this as completed Mar 11, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant