Jan> Hi to the Tkined-List,
Jan> at the moment I try to set the SNMP variable
Jan> internet.private.enterprises.sec.powermon.
Jan> powermonUPS1.ups.upsIdent.upsIdentManufacturer.0
Jan> via Tkined. The permissions are "read-write" and I can read all of the
Jan> variables inside this MIB. Everytime I try to set a variable in the
Jan> upsIdent group I get back a
Jan> noSuchName 1 {1.3.6.1.2.1.33.1.1.1.0} {OctetString} {Siemens}
Jan> Where does this OID string come from? Is this a wrong pointer inside of
Jan> Tkined or is this a problem of the ups agent?
Please be more precise when reporting possible bugs because otherwise
I have to guess what people are trying to do (which is a waste of
time). Note that Tkined does not have any clue about SNMP - it is the
Tnm Tcl extensions that does SNMP processing.
Your message could have been easier to understand if you would have
included a script like this:
set s [snmp session -alias upsagent]
set oid [mib oid ups.upsIdent.upsIdentManufacturer.0]
set vbl [list [list $oid foobar]]
puts "$vbl"
catch {$s set $vbl} msg
puts "$msg"
I guess that you get a SNMP response with an OID which is not the same
as the OID in the $vbl variable, right? If yes, I am 99.9 % sure that
your agent is broken. You can check by adding a "snmp watch on" to the
script which will dump the PDUs to stderr. BTW, why does it make sense
to make a variable named upsIdentManufacturer writable?
Juergen
-- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)