snmp broken in trunk ?

[richlv]

it seems to me that snmp is broken in trunk, revision 7130.
i tried to strip relevant information from verbose log - it seems that value is received correctly, but then crap data is inserted in the db...
can anybody verify this ?
ip is replaced by <IP> here, logfiles & db contain actual ip.
i'm also not sure why port appears twice in "SNMP [public@<IP>:161:161]"

In get_value(key:upsAdvIdentSerialNumber.0)
In get_value_snmp(key:upsAdvIdentSerialNumber.0,oid:P owerNet-MIB::upsAdvIdentSerialNumber.0)
In snmp_normalize(oid:PowerNet-MIB::upsAdvIdentSerialNumber.0)
End of snmp_normalize():PowerNet-MIB::upsAdvIdentSerialNumber.0
In get_snmp(oid:PowerNet-MIB::upsAdvIdentSerialNumber.0)
SNMP [public@<IP>:161:161]
AV loop OID [PowerNet-MIB::upsAdvIdentSerialNumber.0] Type [4] 'STRING: "QS0609121239"'
End get_value()
Query [begin;]
In process_new_value(upsAdvIdentSerialNumber.0)
In add_history(key:upsAdvIdentSerialNumber.0,value_ty pe:1,type:4)
In add_history(itemid:22188,STRING:<IP>:161)
In add_history_str()
Query [insert into history_str (clock,itemid,value) values (1238750381,22188,'<IP>:161')]
End of add_history():SUCCEED

[richlv]

this also happens both with textual and numeric oids - anybody with a bright idea what's going on ?

[richlv]

anybody ?
this looks quite critical to me, i'd suggest everybody who wants to use snmp in future to chime in ;>
also, doesn't look like a bug with net-snmp libs or something else - 1.6 on the same machine retrieves snmp items correctly, and trunk also receives it correctly - only upon storing the value in the db it's broken.

[richlv]

ok, this gets a bit more weird.
it seems that the problem only appears if received data is non-numeric, like serial number, description etc.
numeric data like network traffic is stored correctly.

[richlv]

for the record, problem still there in rev 7243

[richlv]

while i missed particular commit, the problem is gone in current trunk, revision 7302