net-snmp

Robert Story wrote:
> I think the real question is why you end up in the routine
> add_strings_to_oid() when your index is an integer.

This is all client-side stuff mind, not in snmpd or my custom modules.
The trace I'm working on is snmpset - when I ask it to create row number
116 it gives me an out-of-range error before it even sends a packet.

> The code you mentioned
> is for adding an octect string to and oid. Octet strings start with a
> length byte, which is what the library is doing.

It's called from snmp_parse_oid(). A public, and as far as I can tell
undocumented, function of libsnmp. I believe it's purpose is to take an
OID string
(".iso.org.dod.internet.private.enterprises.ucdavis.laTable.laEntry.laIndex.1")
and turn it into an array of type oid. snmp_parse_oid() calls at least
read_objid() and get_node() which in turn call _add_strings_to_oid().

On mature reflection, I think a comparison line needs to be there, but
instead of:

	if (*objidlen + len + 1 >= maxlen) goto bad_id;

I think it should be:

	if (*objidlen + 1 >= maxlen) goto bad_id;

because it's clearly adding one and only one more oid to the objid[]
array, and it increments *objidlen immediately afterwards.

Paul.

On Thu, May 17, 2001 at 12:46:14PM +0100, Paul Kelly wrote:
> Robert Story wrote:
> > I think the real question is why you end up in the routine
> > add_strings_to_oid() when your index is an integer.
> 
> This is all client-side stuff mind, not in snmpd or my custom modules.
> The trace I'm working on is snmpset - when I ask it to create row number
> 116 it gives me an out-of-range error before it even sends a packet.

What does your MIB specify for the objects? As Robert says, you are only
supposed to enter that section of code if the INDEX clause of your table
entry has a type of OCTET STRING which is not IMPLIED. The routine
thinks it is parsing the length specifier for the string.

Could you post your MIB and an example of the error when using one of the
standard tools?

/Niels

-- 
Niels Baggesen  --  @home  --  Århus  --  Denmark
Email: niels@...

Niels Baggesen wrote:
> > > I think the real question is why you end up in the routine
> > > add_strings_to_oid() when your index is an integer.
> What does your MIB specify for the objects? As Robert says, you are only
> supposed to enter that section of code if the INDEX clause of your table
> entry has a type of OCTET STRING which is not IMPLIED. The routine
> thinks it is parsing the length specifier for the string.

Oooooh. I think I've totally misunderstood the INDEX clause.

Please ignore me while I beat myself repeatedly over the head with both
my hard-back SNMP books.

Paul.

Paul Kelly wrote:
> > > > I think the real question is why you end up in the routine
> > > > add_strings_to_oid() when your index is an integer.
> > What does your MIB specify for the objects? As Robert says, you are only
> > supposed to enter that section of code if the INDEX clause of your table
> > entry has a type of OCTET STRING which is not IMPLIED. The routine
> > thinks it is parsing the length specifier for the string.
> Please ignore me while I beat myself repeatedly over the head with both
> my hard-back SNMP books.

I think the beatings are starting to work.

All I want in life is a nice simple table where the last element of the
OID goes from 1 all the way up to a Big Number, each of which uniquely
identifies a row and corresponding set of objects. Is this too much to
ask of SNMP?

Is it fair to say I should just delete the INDEX clause from my MIB, or
is it required for a table? Should I instead have a not-accessible
afIndex object of type INTEGER that simply mirrors the last element of
the OID?

Or am I totally missing the game here again?

Paul.

>>>>> On Mon, 14 May 2001 11:19:49 +0100, Dave Shield <D.T.Shield@...> said:

Dave> b)  To ensure that what finally gets released is generally
Dave> accessible.  I'm sure the old 'complex_handler' stuff
Dave> would have been very useful, but nobody other than
Dave> you seemed to know how it worked!

Yep, that was my fault.

Dave> This project (along with many others), seems to have a history
Dave> of template code ending up in final releases!

The open-source model of "release early, release often" sometimes is
translated to "release early, write documentation later" it seems.  I
certainly follow this model more than I should (like I have to tell
*you* that).

Wes> The column being accessed (ie, table.entry.colnum.index1...)

Dave> In other words, this is roughly equivalent to 'magic' in the old scheme?

Right, for *this* type of helper data (ie, specific to something
making use of the table helper).  For the scalar example, discussed in
a different thread, a magic number isn't needed since a single thread
is being registered.  For the old_api helper I'm going to write, it'll
use the previous magic number definition.

IE, the magic number usage is now helper dependent.

Dave> table_set_result_name( reginfo, var, table_info);
Dave> snmp_set_var_typed_value(var, ASN_INTEGER, &result, 4);
Dave> would be another :-)

<heh> So you argued earlier for a single api for registering the mib,
but 2 for setting answers (and I'd note here which will be used more
often when coding and thus might warrant a more compact notation)?

Wes> It's been completely scrapped.  See the new code I sent you in my last
Wes> note.

Dave> Yes.   Which still has:

Dave> init_test_handler(){
Dave> table_registration_info *table_info;
Dave> }
Dave> my_test_table_handler(){
Dave> table_request_info *table_info;
Dave> }

Dave> Two variables, with the same name, serving different purposes.
Dave> Which is what completely threw me first time through.   All I'm
Dave> asking is that you try and use different names for different
Dave> jobs.

Ahh.  Sorry, I'll fix that instance to.

-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@...

(coincidentally, I'm writing this note from inside a discussion panel
entitled "Can WBEM replace SNMP?")

>>>>> On Mon, 14 May 2001 11:19:45 +0100, Dave Shield <D.T.Shield@...> said:

Dave> Yup - looks good (and pretty simple to follow).  I'm rapidly
Dave> coming round to this model, Wes.  They need somewhat better
Dave> documenting, of course, but I won't mention that now.

Well, duh...  There is not documentation yet so I agree it needs to be
improved (ie: written).

Dave> I notice that the example scalar handler registers {1,2,3,6,1}
Dave> Is this an instance (presumably within a table), or an object (with
Dave> the implicit instance {1,2,3,6,1,0} )  ?

I was waiting for you to bring this up (and am surprised it took so
long).  Currently, .1.2.3.6.1 directly.  No .0 at the end.

Note that I wrote the file before making that decision, so the file
(and api) needs to be renamed away frow scalar to probably "instance"
or something instead.

The reasoning is that the helper could be used to register anything,
not just scalars, which I think is important.  If someone really
wanted to register just the scalar, there is certainly nothing wrong
with supporting both a scalar helper and a instance helper (and in
fact the scalar helper could merely use the instance helper with a
slightly longer OID registration, all within about 10 lines of
additional code).

Wes> Specifically, what if you do a request like: snmpget -t 6
Wes> ... sysUpTime.0 some.sleep.oid.5 sysUpTime.0 would you expect the
Wes> values of the 2 sysUpTime.0 requests to be?  equal, or 5 seconds
Wes> apart?

Dave> I'd say that this is implementation dependent.

Exactly.  We agree.

Dave> Does the controlling agent framework detect [doing nothing] as
Dave> an error - if so how?

Dave> Your suggestion for handling errors (as opposed to exceptions)
Dave> seems reasonable.  Suck it and see.  But that's not quite what I
Dave> meant.  Taking the subtree as an example, this registers
Dave> {1,2,3,4} and everything below.  The handler itself then checks
Dave> against {1,2,3,4,5,6} - and returns a suitable INTEGER value.
Dave> But with a GET request for {1,2,3,4,5,7}, or {1,2,3,4,5,6,7} -
Dave> the handler won't set a value, but will still return NOERROR.
Dave> What I was asking was where this will be picked up?  At what
Dave> stage in the handler chain is this checked for?  It's fine if
Dave> there isn't any code to do it yet - I'm just trying to determine
Dave> where it fits logically.

If I understand your question (of which I'm still not convinced), the
master agent (not anything in the helper chain) will eventually
resolve this error handling.

Basically, if a handler returns (note, not a complete list):

  For GET:
    nothing (doesn't change the varbind)
      the agent translates to NoSuchObject (or instance?)
    NoSuchObject/other-exception
      returns that error.  Possibly translating into a SMNPv1
      compliant return.

  For GETNEXT:
    nothing (doesn't change the varbind)
      the agent continues the search into the next subtree
    END_OF_MIB
      bad handler, it shouldn't touch it but did.  We should probably
      check for this.

Does this direction make sense now?
-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@...

Dave> I notice that the example scalar handler registers {1,2,3,6,1}
Dave> Is this an instance (presumably within a table), or an object (with
Dave> the implicit instance {1,2,3,6,1,0} )  ?

Wes> I was waiting for you to bring this up (and am surprised it took so
Wes> long).  Currently, .1.2.3.6.1 directly.  No .0 at the end.

That's fine.
It fits in with earlier discussions about protecting MIB module writers
from some of the nitty-gritty of OID handling.


Wes> Note that I wrote the file before making that decision, so the file
Wes> (and api) needs to be renamed away frow scalar to probably "instance"
Wes> or something instead.

Wes> The reasoning is that the helper could be used to register anything,
Wes> not just scalars, which I think is important.

By "anything", I presume you mean "any single instance" ?


Wes>                                                    If someone really
Wes> wanted to register just the scalar, there is certainly nothing wrong
Wes> with supporting both a scalar helper and a instance helper

I think this is vital!

If anything, having a "true" scalar handler is probably more important
than having a general instance handler.   Simply because that's what
a reasonable number of MIB objects will require.

The reason for picking up on this is that I couldn't see anywhere that
dealt with the .0 instamce subidentifier.

  (I'm getting a little concerned about the efficiency of long chains
of "trivial" handlers - both in terms of run-time, and maintainability.
But whether this is significant is probably something we'll only discover
when we start using this in anger).




Wes> If I understand your question (of which I'm still not convinced),
Wes> the master agent (not anything in the helper chain) will eventually
Wes> resolve this error handling.

Wes> Basically, if a handler returns (note, not a complete list):
Wes> 
Wes>   For GET:
Wes>     nothing (doesn't change the varbind)
Wes>       the agent translates to NoSuchObject (or instance?)
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^

Aha!   That's *exactly* my point.

How does the agent distinguish between noSuchObject, and noSuchInstance.
The scalar handler you sent seemed to ignore the possibility of nSI
altogether - but that was where I'd expect this to have been dealt with.

In addition, neither of the handlers seemed to look at the results after
the 'call_next_handler' processing.   Where would this be done - in the
main varbind-processing loop?


Dave

Wes> Yes, [table_build_result] sets the OID from the index values

Wes> snmp_table_update_varbinds_oid_from_indexes
Wes>                 _and_value_from_passed_in_arguments(),
Wes> would be one recommendation).


Dave> 	   table_set_result_name( reginfo, var, table_info);
Dave> 	   snmp_set_var_typed_value(var, ASN_INTEGER, &result, 4);
Dave> would be another :-)


Wes> <heh> So you argued earlier for a single api for registering the mib,
Wes> but 2 for setting answers


Yes - because from the point of view of the MIB programmer, registration
involves a single action, while answering a GetNext request involves two.

    "I want a registration structure that looks like this"
    "I want to set the name and value"
                            ^^^

The fact that the registration call involves allocating memory and then
filling it in, is something that the MIB implementer doesn't really need
to know.  We could use a pool of pre-malloced buffers, and it would look
just the same.

  But the fact that GetNext handling involved setting both name and value
*is* something that affects the MIB programmer (since it's one of the
main differences between Get and GetNext).
  Splitting this into two steps, and using the same routine for setting
the value in both cases,  has the effect of making crystal clear the
similarities (and differences) between the Get and GetNext handling.

  And I note that this is precisely the approach you took in the
'my_test_handler' routine (with 'snmp_set_var_objid()').

I'm simply suggesting that you apply this to the example table handler
as well.


Dave


P.S:  I'd also quote the great American philosopher, Ralph Waldo Emerson:
      "A foolish consistency is the hobgoblin of little minds"
:-)

>>>>> On Thu, 17 May 2001 10:42:07 +0100, Dave Shield <D.T.Shield@...> said:

Wes> The reasoning is that the helper could be used to register anything,
Wes> not just scalars, which I think is important.

Dave> By "anything", I presume you mean "any single instance" ?

Yes.

Wes> If someone really wanted to register just the scalar, there is
Wes> certainly nothing wrong with supporting both a scalar helper and
Wes> a instance helper

Dave> I think this is vital!

Easily handled.

Dave> (I'm getting a little concerned about the efficiency of long
Dave> chains of "trivial" handlers - both in terms of run-time, and
Dave> maintainability.  But whether this is significant is probably
Dave> something we'll only discover when we start using this in
Dave> anger).

I've had similar concerns myself, but agree that I think
testing/fielding is needed to help us determine how much will be
problematic.  Half of my thought is that if the efficiency is bad, its
more likely because you're using helpers you don't need, which is
something we need to think about when creating generic register_simple
type API wrappers.

However, modularizing everything I think is a benefit to this as we
can eliminate the unneeded pieces easily for modules that don't need
the extra functionality (as opposed to, say, always processing the oid
for the end handler who may not need it).

[...nsObject vs nsInstance debate...]
Dave> Aha!   That's *exactly* my point.

Dave> How does the agent distinguish between noSuchObject, and
Dave> noSuchInstance.  The scalar handler you sent seemed to ignore
Dave> the possibility of nSI altogether - but that was where I'd
Dave> expect this to have been dealt with.

Dave> In addition, neither of the handlers seemed to look at the
Dave> results after the 'call_next_handler' processing.  Where would
Dave> this be done - in the main varbind-processing loop?

Undecided.  Possibly in yet-another-helper, since end handlers that
properly deal with this probably shouldn't require the over-head of
checking the varbindlist again if its not needed?

Open to debate.

As far as picking one or the other to return, it'll greatly depend on
what is being registered and thus the module performing the handler
registration is the *only* place that will know what the proper
non-existent object should return with respect to error codes.  Some
handlers, like the scalar handler and table handlers, can probably "do
the right thing themselves".  The subtree handler doesn't have proper
knowledge to make that decision and will have to pick something.
-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@...

Sorry, I did not attache the patch file,

--- ucd-snmp-4.2.1/snmplib/snmpv3.c.orig	Thu May 10 11:39:31 2001
+++ ucd-snmp-4.2.1/snmplib/snmpv3.c	Thu May 10 11:41:15 2001
@@ -104,7 +104,7 @@
   if (strcasecmp(cptr,"MD5") == 0)
     defaultAuthType = usmHMACMD5AuthProtocol;
   else if (strcasecmp(cptr,"SHA") == 0)
-    defaultAuthType = usmHMACMD5AuthProtocol;
+    defaultAuthType = usmHMACSHA1AuthProtocol;
   else
     config_perror("Unknown authentication type");
   defaultAuthTypeLen = USM_LENGTH_OID_TRANSFORM;

---
 Katsuhisa ABE <abekatsu@...>
Cyber Solutions Inc.

On Thu, May 17, 2001 at 11:03:28AM +0900, Katsuhisa ABE wrote:
>  Sorry, I did not attache the patch file,
> 
> --- ucd-snmp-4.2.1/snmplib/snmpv3.c.orig	Thu May 10 11:39:31 2001
> +++ ucd-snmp-4.2.1/snmplib/snmpv3.c	Thu May 10 11:41:15 2001
> @@ -104,7 +104,7 @@
>    if (strcasecmp(cptr,"MD5") == 0)
>      defaultAuthType = usmHMACMD5AuthProtocol;
>    else if (strcasecmp(cptr,"SHA") == 0)
> -    defaultAuthType = usmHMACMD5AuthProtocol;
> +    defaultAuthType = usmHMACSHA1AuthProtocol;
>    else
>      config_perror("Unknown authentication type");
>    defaultAuthTypeLen = USM_LENGTH_OID_TRANSFORM;
> 

Yuck! Thanks!

/Niels

-- 
Niels Baggesen  --  @home  --  Århus  --  Denmark
Email: niels@...

Philip> I would like to say that the ability to set the sysObjectID seperate
Philip> from the notification OID and the root of the management (NET-SNMP)
Philip> MIB tree would be much appreciated.  Right now they all use the same
Philip> #DEFINE.

Harrie> For branding issues it should then be 3 seperate defines.
Harrie> Although, the NET-SNMP is maybe better of being static
Harrie> the NET-SNMP oid.

Dave>	--with-enterprise-oid	(default "enterprise.net-snmp")

  This seems dangerous to me.  It's too easy to set it to an arbitrary
value where the MIB doesn't exist, or worse, there is a collision with
other objects.

  On the other hand setting the sysOID and notification OID sounds like
a great idea.

John
-- 
// Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd.
// The future of broadband wireless access  // http://www.cambridgebroadband.com

John Naylon wrote:
> 
> Philip> I would like to say that the ability to set the sysObjectID seperate
> Philip> from the notification OID and the root of the management (NET-SNMP)
> Philip> MIB tree would be much appreciated.  Right now they all use the same
> Philip> #DEFINE.
> 
> Harrie> For branding issues it should then be 3 seperate defines.
> Harrie> Although, the NET-SNMP is maybe better of being static
> Harrie> the NET-SNMP oid.
> 
> Dave>   --with-enterprise-oid   (default "enterprise.net-snmp")
> 
>   This seems dangerous to me.  It's too easy to set it to an arbitrary
> value where the MIB doesn't exist, or worse, there is a collision with
> other objects.

That is true, but people who will change this probably know what they
are
doing. If not, they create there own problem.

> 
>   On the other hand setting the sysOID and notification OID sounds like
> a great idea.

I believe that otherwise many people are jsut patching the source
to get this. The cofnigure which Dave proposes is what I like
and had in mind.

-- 
address: Covalent Technologies, 645 Howard St, San Francisco, CA - 94105
phone: +1-415-536-5221                               fax:+1-415-536-5210
personal website: http://www.lisanza.net/