Help write write-only variables && ucd-snmp-3.1.2.1 possible problem?

Help write write-only variables && ucd-snmp-3.1.2.1 possible problem?

Post by David Newcom » Thu, 10 Apr 1997 04:00:00



Lee (+ any one else),

Yes, that was the problem that I found. I tried puting 'no such var' but
this stops the snmpwalk prematurly ie. when it tries to read the variable.
I also tried 'no Access' but this as a similar effect.
I have tried to keep the MIB in line with the standards; so I resorted
to making the variables read-write. Now the snmpwalk can be done but the
results it gives for these variables sometimes have little meaning.

I am using the ucd-snmp-3.1.2.1 version which I have stripped and added
to. I noticed that when you set a MIB variable, the response to the set
should include the newly set variable: Book(1).
This does not happen. If the agent sees that the 'set' worked
successfully it just clones the incoming request and packages it up as
a 'get-response'.
Which is where my orginal problem came from. I using at set request, as
a MIB query, ie set a field with a printer name and in the get-response
reply comes the printer status as set by the agent. This is why I wanted
to make the variable write-only, because to read it straight has a value
but no meaning. It would be better if the walk just displayed the write-
only variables as WO and continued on the walk.

I was wandering what the offical thing to do in this situtation is....?

David.

_____________________________________oOOo_________________________________


> I suppose you've long since solved this, but we return a
> zero for write-only vars just to avoid this. My understanding
> is that 'no such var' is also a legitimate response, but
> it does break an snmpwalk, which is why we do the former.

> lee

> > Hello all,

> > I am writing a manager from the UCD snmp manager which I have hacked.
> > Several of my variables are write only and are used to query the snmp
> > database.

> > Which works find. My problem is when an agent does a GETNEXT request
> > in order to walk through the date-base. It comes to the write-only
> > variable and tries to read it. It failed.

> > What error message must be returned, or what must happen, in order
> > for the snmpwalk to continue.

> > The in-src comments, situated in agent/snmp_agent.c:parse_var_op_list(),
> > suggests that acls for individual variables (of a complete packet) are
> > checked in the agent/snmp_vars.c:getStatPtr() src file.

> > I am unsure of where to put the acl check for the variables.

> > Any help would be appreciated,


> > ------------------------------------------------
> > David Newcomb,
> > Macro4 Open Systems Ltd.
> > Fairfield House,
> > Carey Road,

> > Berkshire,
> > RG40  2NP,           Tel:    +44 (0)118 989 2626
> > United Kingdom.      Fax:    +44 (0)118 989 0414

> --
>   Lee Slaughter, network management development - submarine stuff
>   Navy R & D, Point Loma, San Diego, CA              619-553-5486
>   "Giving credence to his ramblings indicates a cognitive disorder..."
>                                 - Lee's psychiatrist, circa 1952

--

------------------------------------------------
David Newcomb,
Macro4 Open Systems Ltd.
Fairfield House,
Carey Road,

Berkshire,
RG40  2NP,           Tel:    +44 (0)118 989 2626
United Kingdom.      Fax:    +44 (0)118 989 0414

 
 
 

Help write write-only variables && ucd-snmp-3.1.2.1 possible problem?

Post by David Newcom » Fri, 11 Apr 1997 04:00:00



> Hi David,

Hi Lee,

Quote:> BTW, my agents have been written using CMU, but i've been tasked
> to try to find a faster way (tho privately i think there is none).
> do you know how the ucd code compares? i haven't heard much
> about it. i'm currently exploring  scotty to see if it might
> expedite things in the fashioning of a real agent.

I played with the CMU src code for a while before getting into the UCD code.
There is very little difference. I think UCD was born out of CMU. The UCD
has more comments and more helpful comments than CMU. The UCD came with
all source codes for the snmp programs (snmpget, snmpwalk, etc..) and an
extendible agent.
The config file you ran looked at you system and created the <hash>include
headers for all the files, which made it easier to compile and install.
The UCD has jumped in with both feet trying to implement SNMPv2.
As far as I know there is no SNMPv2 'standard' so everyone is trying to
make an educated guess, and this is UCD attempt.

My Agent/Manager is SNMPv1 so I am in the process of removing much of the
SNMPv2 stuff but they seem to have insestually linked them, which is a
little frustating at times.

Quote:> i haven't looked it up personally (where?) but my snmp colleague here                                      RFCs
> says it isn't clearly specified; that you either return zero or
> 'no such var'.

I think I will look at sending back a NULL packet or an empty string.

What is you agent/manger going to do?

David.

------------------------------------------------
David Newcomb,
Macro4 Open Systems Ltd.
Fairfield House,
Carey Road,

Berkshire,
RG40  2NP,           Tel:    +44 (0)118 989 2626
United Kingdom.      Fax:    +44 (0)118 989 0414

 
 
 

Help write write-only variables && ucd-snmp-3.1.2.1 possible problem?

Post by David T. Perkin » Wed, 16 Apr 1997 04:00:00


HI

In the middle of the message below, it appears that David Newcomb wants
an SNMP SET request to change the value of an object, perform an action,
and return the results of that action. Unfortunately for him, this is
NOT VALID in the SNMP protocol. Also, other approaches, such as specifying
values in a GET or GETNEXT request are NOT VALID either.

To accomplish the goal, MIB objects must be designed to contain the
values for the parameters of the action, to trigger the action, and report
the results. You will have to create a table for these objects if you
want to allow more than one manager (application) to access the agent.
Thus, you will need at least one SET request to supply the parameters
and trigger the action. And at least one GET request to retrieve the
result. (Remember that when you design the MIB objects you must account
for SNMP requests that are duplicated, and responses that are dropped
(which cause the request to be retried after the action has occured).
If you don't, it will be easy for the action to be performed multiple
times. This may cause problems on the managed system, or may confuse
your application.)

And note that "write-only" objects are stricly not allowed by SMIv2.
SMIv1 is ambiguous on this issue. However, the standard interpretation
is that "write-only" objects are illegal. A MIB module containing them
is flagged by SMICng (a leading MIB compiler that actually has checks
for most SMI rules).

Regards
/david t. perkins


> Lee (+ any one else),

> Yes, that was the problem that I found. I tried puting 'no such var' but
> this stops the snmpwalk prematurly ie. when it tries to read the variable.
> I also tried 'no Access' but this as a similar effect.
> I have tried to keep the MIB in line with the standards; so I resorted
> to making the variables read-write. Now the snmpwalk can be done but the
> results it gives for these variables sometimes have little meaning.

> I am using the ucd-snmp-3.1.2.1 version which I have stripped and added
> to. I noticed that when you set a MIB variable, the response to the set
> should include the newly set variable: Book(1).
> This does not happen. If the agent sees that the 'set' worked
> successfully it just clones the incoming request and packages it up as
> a 'get-response'.
> Which is where my orginal problem came from. I using at set request, as
> a MIB query, ie set a field with a printer name and in the get-response
> reply comes the printer status as set by the agent. This is why I wanted
> to make the variable write-only, because to read it straight has a value
> but no meaning. It would be better if the walk just displayed the write-
> only variables as WO and continued on the walk.

> I was wandering what the offical thing to do in this situtation is....?

> David Newcomb.

> _____________________________________oOOo_________________________________

> > I suppose you've long since solved this, but we return a
> > zero for write-only vars just to avoid this. My understanding
> > is that 'no such var' is also a legitimate response, but
> > it does break an snmpwalk, which is why we do the former.

> > lee

> > > Hello all,

> > > I am writing a manager from the UCD snmp manager which I have hacked.
> > > Several of my variables are write only and are used to query the snmp
> > > database.

> > > Which works find. My problem is when an agent does a GETNEXT request
> > > in order to walk through the date-base. It comes to the write-only
> > > variable and tries to read it. It failed.

> > > What error message must be returned, or what must happen, in order
> > > for the snmpwalk to continue.

> > > The in-src comments, situated in agent/snmp_agent.c:parse_var_op_list(),
> > > suggests that acls for individual variables (of a complete packet) are
> > > checked in the agent/snmp_vars.c:getStatPtr() src file.

> > > I am unsure of where to put the acl check for the variables.

> > > Any help would be appreciated,

 
 
 

Help write write-only variables && ucd-snmp-3.1.2.1 possible problem?

Post by Dan Bresla » Wed, 23 Apr 1997 04:00:00


Something looks to be missing from the discussion below.  RFC 1157
says that the agent, in processing a GetNext request, returns the
next value "... immediately available for get operations in the
relevant MIB view...".  Doesn't this mean that a varbind which
might return noSuchName for a get is simply passed over by the
agent when doing a getNext?  Hence snmpwalk shouldn't break;
the agent should just be skipping to the next readable value.

Someone please help me out if I'm wrong...

Dan Breslau


> HI

> In the middle of the message below, it appears that David Newcomb wants
> an SNMP SET request to change the value of an object, perform an action,
> and return the results of that action. Unfortunately for him, this is
> NOT VALID in the SNMP protocol. Also, other approaches, such as specifying
> values in a GET or GETNEXT request are NOT VALID either.

[... remainder snipped ...]
 
 
 

Help write write-only variables && ucd-snmp-3.1.2.1 possible problem?

Post by David T. Perkin » Wed, 23 Apr 1997 04:00:00


On the below, the issue is not what is returned by a GETNEXT, but whether
it is OK to put values is a GET or GETNEXT request and have the agent
use then in processing the request. (Your point about how GETNEXT decides
which objects to return is correct, but is not the issue of the message.)

The orignal message was asking if it was OK to return different values in a
response to a SET request. Both RFCs 1157 and 1905 are quite clear about
the contents of a response PDU for a successful SET request. Also, the SNMP
protocol (both v1 and v2)  is clearing explained and diagrammed in Appendex
B of "Understanding SNMP MIBs" by perkins and mcginnis, with ISBN
0134377087. Here is the text from RFC 1157, last paragraph of section 4.1.5
that describes the contents of the response PDU for a successful SET
request:

   The receiving entity then sends to the originator of the received
   message the GetResponse-PDU of identical form except that the value
   of the error-status field of the generated message is noError and the
   value of the error-index field is zero.

The key words in the above are "identical form".


> Something looks to be missing from the discussion below.  RFC 1157
> says that the agent, in processing a GetNext request, returns the
> next value "... immediately available for get operations in the
> relevant MIB view...".  Doesn't this mean that a varbind which
> might return noSuchName for a get is simply passed over by the
> agent when doing a getNext?  Hence snmpwalk shouldn't break;
> the agent should just be skipping to the next readable value.

> Someone please help me out if I'm wrong...

> Dan Breslau


> > HI

> > In the middle of the message below, it appears that David Newcomb wants
> > an SNMP SET request to change the value of an object, perform an action,
> > and return the results of that action. Unfortunately for him, this is
> > NOT VALID in the SNMP protocol. Also, other approaches, such as specifying
> > values in a GET or GETNEXT request are NOT VALID either.

> [... remainder snipped ...]

Regards,

 
 
 

Help write write-only variables && ucd-snmp-3.1.2.1 possible problem?

Post by Dan Bresla » Wed, 23 Apr 1997 04:00:00



> On the below, the issue is not what is returned by a GETNEXT, but whether
> it is OK to put values is a GET or GETNEXT request and have the agent
> use then in processing the request. (Your point about how GETNEXT decides
> which objects to return is correct, but is not the issue of the message.)

[...]

Thanks for your response.  The entire thread, though, did talk
about GetNext (isn't that what snmpwalk does?) as well as Set.
There were statements to the effect that their agent(s) were returning
noSuchName in response to a GetNext query which would have lead to
a 'write-only' variable.  This is what I was responding to. (I had
to snip most of the quoted message due to overly restrictive posting
software...)

Dan