I have the same problem (SNMPv1, Scotty 2.1.10, Tcl 7.6, Sun Solaris).
I have found two partially satisfactory solutions:
1) edit your MIB (for scotty only!) to change the access of select MIB
objects from read-write to read-create. "read-create" is not a valid
SNMPv1 access, but using it tricks Scotty into allowing a "set-request"
message to call "create" callbacks.
2) in a "begin" callback, for "set_request" messsages only, scan the
list of varBinds looking for entries that don't exist in the current
tree of mib instances and should be created. Create the instances.
Now the "set" callback will be called for that variable, and you can
go on your merry way.
Now I've got a related question:
Our MIB has a table in it that reads differently depending on who is
reading it. The reader is identified by the return IP address (%A).
The table lists recent trap messages sent to that IP address -
each address listening for trap messages will receive a slightly
different list of trap messages.
In a standard C SNMP agent, a "get" callback can be registered so it
is called before the table index is looked up in the tree of mib instances.
The callback can translate the OID index based on the incoming IP
address and return data as appropriate.
Scotty, on the other hand, looks up the complete instance OID in the
instance tree before calling a "get" callback, so SCOTTY has already
generated the "noSuchName" error before I get control.
The only implementation I can think of is to use a "begin" callback
that searches "get-request" and "get-next-request" messages for entries
within this table, and creates the appropriate set of instances
based on the IP address.
This will be very inefficient if I get interleaved requests to read
this table from different IP addresses - I'll have to tear down and
recreate the table instances on each message.
This also won't work correctly on get-next-request for the last MIB
instance before this table - I don't have a chance to reconfigure
the table before the Scotty get-next code walks into the part of the
instance tree that contains this table and grabs a row that was
intended for another IP address.
This table is only a small part of a much larger MIB.
The SNMP manager will be walking over the entire MIB with get-next to
discover which table entries exist, so the get-next scenario above
will happen.
Anyone have any suggestions on how to implement this efficiently?
I'm considering patching the Scotty source to behave more like our
C MIB compiler, calling "get" bindings based on the object ID, before
looking up the specific instance. This probably means calling
"get" bindings from the top of the tree down, instead of from the
bottom up. This will be very ugly for "get-next-request" processing,
since the code won't know whic sub-trees have instances until AFTER
the "get" callbacks have run. ((Hmmmmm - if the "get" callback doesn't
create a MIB instance below itself in the tree, "get-next" will have to
continue on to a different branch of the MIB tree...... Interesting
coding problem.))
-- Judah Greenblatt judah@bbt.com +1-919-405-4716 BroadBand Technologies, Durham, NC, USA-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.