On Fri, 16 Mar 2012 09:33:58 +0100 Ingeborg Hellemo ingeborg.hellemo@uit.no wrote:
After upgrading to 3.11.0 this has magically corrected itself, but for one box.
In 'sensor' I find two rows with oid=.1.3.6.1.4.1.9.9.13.1.5.1.3.[12]. So I guess if I just remove these everything will be OK?
Ok, that was strange. Since you don't have an SNMP community set for the UPS, its pre-existing list of sensors should never be edited by NAV (since the SNMP collector doesn't run for that UPS any more).
No, these two issues were unrelated. The device with the unknown OID was a switch with correct community-settings. Over the weekend the troublesome OID has removed itself from the 'sensor'-table and the cricket-config is correct. Go figure.
But yes, deleting the sensor entries related to the UPS' netboxid should do the trick. I'll whip up a patch to _not_ generate cricket-config for sensors for devices without a community.
That would be sensible.
I guess the SNMP community has once been set. And I would like to set it again, but when I edit the device I get
TypeMismatchError at /seeddb/netbox/edit/1853/
Octet-stream parse error at Pdus
Another device with a wonky SNMP implementation? Do you have a full traceback from the error? If so, please file a bug report: https://bugs.launchpad.net/nav/+filebug
Will do.
As a fix for now I will set the community directly into the database.
Ok. No problems with the device in ipdevpoll.log then?
Well, we get a lot of [WARNING twsnmp.protocol] Bad response from ('129.242.35.52', 161): '0&\x02\x01\x01\x04\x06<SNMPCOMMUNITY>\xa2\x1e\x02\x03#S\xb1\x02\x01\x05\x02\x0 1\x000\x0c0\n\x06\x06+\x06\x01\x02\x01\x01\x05\x00' but we also get these from other devices which do not crash the webinterface.
--Ingeborg