net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Re: Future Plans I - MIB

[Dave S. <D.T...@cs...>]

Dave>     CPU statistics
Dave>         Do we wish to try and provide per-CPU statistics for multi-CPU
Dave>         systems?    As well as, or instead of the overall figure?

Didier> Net-Snmp host mib implementation provides real time load rate on a
Didier> single CPU whereas an average on 1 minute for all CPUs (see RFC1213) !

Well, in practise it hasn't, because no-one has done the work
(until your patch).   That's one of the reasons why the UCD-specific
data has been so valuable - there's been almost no way to get anything
comparable.

Didier> I think it should be improved.

Definitely.
One of the targets of the cleanup of existing modules would indeed be
the Host Resources group - including the CPU load reporting.
  I'd probably want to try and re-use the same CPU statistics routines
for both the private objects, and the base data for the hrProcLoad object.

But the basic concept of saving this information regularly, and comparing
it with subsequent values, is spot on.

Dave

Re: Future Plans I - MIB

[Dave S. <D.T...@cs...>]

Dave> This is the first of three 'kite-flying' messages, floating some
Dave> ideas regarding the future developments of the Net-SNMP suite.
 
Wes> Ack...  And here I thought I was going to get work done.

Well, I don't want you to get bored.....

There's no rush in starting work on any of this - as you said to
John, it's worth letting the 4.2 release settle a bit, before
tearing the guts out of the code.
  But we might as well start planning the assault now.


Dave> The UCD extensions MIB is still carried under the UC Davis
Dave> banner.
Dave> Do we wish to move this across to an new enterprise?

Wes> Glad you brought this up.  I'd been meaning to ask the same question.
Wes> I think we probably should.

That's a relief :-)  I was concerned that you might prefer to keep
everything under the old 'ucdavis' tree.
   Obviously, it's probably sensible to retain that for backwards
compatability (at least for a while), but if the intention is to
move over to a new MIB base location, then we can make the other
alterations at the same time.

 
Dave> Do we wish to [split up] the UCD MIB?

Wes> I've thought of this as well.  Sections of it should go together ...
Wes> .. [e.g.] NET-SNMP-MONITORING-MIB for the proc/disk/etc stuff.

We could either have "all the monitoring stuff" together, or divide
things by subject area (NET-SNMP-DISK-MIB, NET-SNMP-PROC-MIB, etc)
The first feels somewhat less fragmented - the second is easier to
update and develop.
   How confident are we about getting things right first time? :-)

	Strawman proposal 1:

		Monitoring	prTable, dskTable, fileTable
		Extensibility	extTable, (new) passTable
		System		memory, laTable, systemStats
		Disk		diskIOTable
		Internal	version, snmperrs, mrTable, dlmodTable

	Strawman proposal 2:

		Processes	prTable, memory
		Extensibility	extTable, (new) passTable
		CPU		laTable, systemStats
		Disk		diskIOTable, dskTable, fileTable
		Internal	version, snmperrs, mrTable, dlmodTable

Any other suggestions?


   Another point to consider:
     if we get a workable implementation of the DisMan Event MIB, how
much (if any) of the existing monitoring code is rendered redundant?


Wes> If we do change things, I want to restructure *all* the tables
Wes> mentioned above.  Almost all of them should be indexed by strings,
Wes> contain a RowStatus column, etc.

OK - do you wish to come up with a strawman proposal for this?



Dave

Re: Future Plans I - MIB

[Dave S. <D.T...@cs...>]

Dave> 	   Do we wish to try and provide per-CPU statistics for multi-CPU
Dave> 	systems?    As well as, or instead of the overall figure?

Ragnar> IMHO the overall figure should not be removed. It is far more practical
Ragnar> for the user to check a single number than having to consilidate
Ragnar> multiple.

Fair enough.
What should the meaning of the overall figure(s) be?

Should they be the average of the individual CPU figures, the sum
of them, or what?    I'll admit that I can't immediately see what
sensible overall values we can report for a multi-CPU system, but
I don't pretend to be an expert here.

>          And it makes configuration of the monitoring-software a lot
> easier when it is supposed to monitor both single- and multiple- CPU
> systems.

Well, a single-CPU system would still have an entry in the CPU stats
table, in the same way that a multi-CPU system would.  It's just that
there'd only be one row.

Dave

Re: Future Plans II - Library

[John N. <jb...@ca...>]

Okay here's my 2¢.

>     Modularisation
> 	The current code is not always particularly easy to understand
> 	and maintain (e.g. the monstrosity that is 'snmp_api.c'!)
> 	Do we wish to try and re-structure the internal organisation of
> 	the library in a more logical and modular manner?
> 		(leading question m'lud!)

  I think you know my views on this one!

>     Other packages
> 	It has been suggested that we might consider using externally
> 	provided packages for certain aspects of the library support
> 	(e.g. option handling, 'glib' portability routines, libsmi)
> 	   Is this worth pursuing?

  Hmm.  I would be a little reluctant to go down this track.  Isn't the 
danger in multiplying the dependencies that there is more scope for 
incompatibilities and version problems?  Recently I've been looking at 
running the agent on an embedded system and it lends itself nicely to this 
as it stands, without the need to worry about other (perhaps less portable) 
packages being available.  I guess this really varies from package to 
package though?

>     Programmer APIs
> 	Should we review the public APIs we provide for those wishing to
> 	write fairly simple SNMP applications - to facilitate the more
> 	common requirements?
> 	   (e.g. single-shot requests, hiding the 'session' handling;
> 	    setting up authenticated/encrypted requests, etc)

  Probably at a fairly low priority?  I would imagine that most people doing 
this kind of work would be using some kind of scripting language, and using 
the applications as primitives -- essentially allowing what you describe 
(single-shot requests, no knowledge of sessions etc).

>     I/O handling
> 	The handling of direct SNMP-related I/O is currently separate
> 	from the recent routines for "other" I/O handling.  Should these
> 	be consolidated?

  Well, we've discussed this before I think.  Actually though, I'm not sure 
there is all that much to be gained in doing this.  The addition of the 
register_{read,...}fd routines was the major step -- they're basically the 
logical inverse of the snmp_select_info type routines.  Isn't this 
agent-specific though?

>     conf handling
> 	Should we provide routines for more-consistent handling of
> 	configure directives?  (e.g. command options, conf file parsing
> 	utilities routines, standardised environmental variables)

  XML-based configuration would be very neat IMHO.  (I haven't fully thought 
this through however!)

>     Other APIs
> 	We've floated the idea of providing a WinSNMP wrapper to the
> 	UCD library.  Is this worth pursuing?   What other library
> 	interfaces could/should we look at?

  Mmm, probably a nice idea.

John.

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

Re: IPX support

[John N. <jb...@ca...>]

Wes> I'm not going to apply the patch just yet (I'm waiting for a bit
Wes> more settlement after the 4.2 release just to make sure there aren't
Wes> any serious issues that we missed).

Very sensible!  Of course, feedback from anyone crazy enough to patch a private tree and have a look at the way things have been re-structured would be more than welcome at this stage.

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

SOS dynamic libraries

[Jerome J. <Jer...@fe...>]

version  : ucd-snmp version 4.2
system   : SunOS 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-250
protocol : AgentX



   Hello,

first off, thanks very much.


Wes Hardaker wrote:
> 
> >>>>> On Wed, 06 Dec 2000 18:11:27 +0100, Jerome Jargot <Jer...@fe...> said:
> 
> Jerome> The ucd-snmp/agent/.libs/snmpd is a binary which seems to use
> Jerome> the dynamic libraries:
> 
> Jerome> - ucd-snmp/agent/.libs/libucdagent-0.4.2.so
> Jerome> - ucd-snmp/agent/.libs/libucdmibs-0.4.2.so
> Jerome> - ucd-snmp/snmplib/.libs/libsnmp-0.4.2.so
> 
> Jerome> Is it true ?
> 
> Jerome> So, could it be possible to remove all lib*.a, lib*.la,
> Jerome> lib*.lai ?  (will the master agent be working after that ?)
> 
> You should not delete anything from the build tree.  libtool makes use
> of these files when you run "make install".  (a binary will be
> installed, not the shell script)


I do not need to install the master agent and subagents onto the SUN I'm
using for compilation.
I produce a master agent and some subagents, that are standard for my
company (FERMA). But project workers will customize our products later
on, for clients, and they are going to produce additional subagents.
The main line is that I deliver a unix package (pkgadd command), for
already created agents, and the ucd-snmp directory that allows
additionnal subagents to be created by project workers.



???

What are the things done during 'make install' that need *.lai and *.la
and *.a to install the binary ?

???



> 
> Note that by default the package is built with both static and shared
> libraries.  To turn one or the other off, use --disable-static or
> --disable-shared when running configure.


OK, very usefull.


> Jerome> After compiling a subagent, does it use the same dynamic
> Jerome> libraries ?  i.e.: if I copy the 3 libraries into
> Jerome> /usr/stuff/lib, does the master agent AND subagents run well
> Jerome> using LD_LIBRARY_PATH=/usr/stuff/lib ?
> 
> In theory.  "make install" is the proper way to go to ensure that
> things work (and it'll tell you what you need to do if anything).
> 

I need to make my own install.


Thanks very much again for all.


    Jerome

SOS on dynamic libraries

[Jerome J. <Jer...@fe...>]

version  : ucd-snmp version 4.2
system   : SunOS gleipnir 5.7 Generic_106541-11 sun4u sparc
SUNW,Ultra-250
protocol : AgentX


    Hello,

Fisrt off, thanks very much !


ni...@ba... wrote:
> 
> Please, post to ONE mailing list only. It is counterproductive to wade through
> two, three or even four copies of the same mail!

no, problemo, sorry.


> Yes, the .a libraries are static version that, if used, is included at ld time

what are lib*.la and lib*.lai ???
When are they used ???


> >After compiling a subagent, does it use the same dynamic libraries ?
> >i.e.: if I copy the 3 libraries into /usr/stuff/lib, does the master
> >agent AND subagents run well using LD_LIBRARY_PATH=/usr/stuff/lib ?
> 
> Yes, dunamic libraries must be present at run-time. Your above should work, but
> if you intend to install under /usr/stuff, why don't you just configure with
> --prefix=/usr/stuff and do make install?
> 

Just to be sure ...

Thus, the 3 libraries (libucdagent - libucdmibs - libsnmp) are always
the same. 
i.e.: they can be used at run time, by a subagent 'B' even if they have
been produced by the Makefile during the compilation of a subagent 'A'.

I'm not using 'make install' because the master agent and the subagents
are not running on the SUN used for compilation. I'm making unix
packages to make an install using
unix command 'pkgadd'.


Thanks again for all,



   Jerome

Re: a simple question:if SNMP agent receive a GET command ,the agent will do somthing to "get " some data.The action that agent will take will be implemented by programme by me?

[Dave S. <D.T...@cs...>]

>                                     .if SNMP agent receive a GET command
> which posted by a SNMP manager,the agent      will do somthing to "get "
> some data.The action that agent should take should be implemented by
> programme by me?

Correct.

See the file 'AGENT.txt' for details of what you need to implement.

Dave

Re: Future Plans I - MIB

[Didier C. <did...@fe...>]

Dave Shield a écrit :

> This is the first of three 'kite-flying' messages, floating some ideas
> regarding the future developments of the Net-SNMP suite.   This message
> concerns issues relating to the UCD-SNMP-MIB local extensions.   The
> accompanying messages cover the library and agent respectively.
>
>    Please feel free to comment on any of these, or to add any other ideas
> that occur to you.   This is probably the best chance we'll ever have to
> regroup and plan for the future, and I'm keen that we make the most of it.
>
> MIB-related issues:
>
>    Naming
>         The UCD extensions MIB is still carried under the UC Davis banner.
>         Do we wish to move this across to an new enterprise?
>            (If not, then this may swing things against a lot of the
>         other proposed changes)
>
>    Modularity
>         Currently (almost) everything is in one, monolithic MIB module.
>         Practise with other, standard MIBs (e.g. RFC1213), has been to
>         move towards splitting them up into separate modules, so that
>         they can be developed independently of each other.
>            Do we wish to do the same with the UCD MIB?
>
>     Shell/exec handling
>         Currently, mapping between the output of the scripts and the
>         MIB objects depends on whereabouts in the overall MIB tree that
>         the extensible call is registered.
>            Do we wish to retain this mechanism, or consider possible
>         alternative mappings?
>
>     Pass-through handling
>         Do we wish a finer level of control over pass-through subagents?
>         (e.g. controlling if/how long results are cached,  whether to close
>         down a persistent subagent, etc).
>
>     CPU statistics
>         These are currently held for the system as a whole, and there's
>         been some confusion over absolute values oint
> Get_Next_HR_Proc (void)
> {
>   /*
>    * Silly question time:
>    *   How do you detect processors?
>    *   Assume we've just got one.
>    */
>
>     if ( HRP_index < 2 )
>         return ( HRDEV_PROC << HRDEV_TYPE_SHIFT ) + HRP_index++;
>     else
>         return -1;
> }

> r percentages.
>            Do we wish to try and provide per-CPU statistics for multi-CPU
>         systems?    As well as, or instead of the overall figure?

Net-Snmp host mib implementation provides real time load rate on a single CPU
whereas
an average on 1 minute for all CPUs (see RFC1213) ! I think it should be
improved.

hr_proc.c : line 186

int
Get_Next_HR_Proc (void)
{
  /*
   * Silly question time:
   *   How do you detect processors?
   *   Assume we've just got one.
   */

    if ( HRP_index < 2 )
        return ( HRDEV_PROC << HRDEV_TYPE_SHIFT ) + HRP_index++;
    else
        return -1;
}

-------------------------------------------------------------

void init_hr_proc(void)
{
    int period, ret;
    /* Add by Didier Chabanol for FERMA */
    V0_InitTab();

    /* First check whether shared kstat contol is NULL, if so, try to open our
own. */
    if (kstat_fd == NULL)
    {
      kstat_fd = kstat_open();
    }
    /* Then check whether either shared kstat was found or we succeeded in
opening our own. */
    if (kstat_fd == NULL)
    {
      snmp_log(LOG_ERR, "vmstat_solaris2 (init): kstat_open() failed and no
shared kstat control found.\n");
    }

    /*Init cpu number and V0_prevIdleCpuIdleTime array*/
    V0_GetLoadCpu(0, NULL);

    init_device[ HRDEV_PROC ] = Init_HR_Proc;
    next_device[ HRDEV_PROC ] = Get_Next_HR_Proc;
#ifdef HRPROC_MONOTONICALLY_INCREASING
    dev_idx_inc[ HRDEV_PROC ] = 1;
#endif

    period = 10;
    ret = snmp_alarm_register(period, SA_REPEAT, V0_GetLoadCpu, NULL);

    ......................................

int
Get_Next_HR_Proc (void)
{

    if ( V0_procIndex < V0_nbProc )
    {
        V0_procIndex++;
        return ( HRDEV_PROC << HRDEV_TYPE_SHIFT ) + V0_procIndex;
    }
    else
        return -1;
}

 /*********************
  *  Author: Didier Chabanol for FERMA
  *  Specific implementation functions
  *
  *********************/
void V0_InitTab(void)
{
    int i;

    for (i=0; i<C0_MAX_CPU ; i++)
    {
 V0_prevIdleCpuIdleTime[i] = NULL;
 V0_cpuLoadRate[i] = NULL;
    }
}



>
>
>     Traps
>         The current enterprise-specific traps don't conform to the
>         guidlines given in the Co-existance document (in particular with
>         regard to the penultimate '0' subidentifier and v1<->v2 mapping)
>             Do we wish to change this?
>
> Over to you....
>
> Dave
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders

RE: help required : *SNMP managers* and *indexing*

[Szaboky, G. (George) <sz...@lu...>]

I have just downloaded 4.2 today and installed it. I then read your post and
retested some code I had written doing index level registration. It appears
that the snmpwalk I just ran worked, so I not sure this is a problem
anymore. I am attaching a write up of what I am doing anyway. I would
appreciate comments on my approach. Meanwhile I'll keep testing. Thanks

Have reworked a previous post adding some additional information. Hope
some light can be shed on this.

I am having problems with an Agentx subagent registering for a single
row in a table

For example:

I am using mib2c to generate a module for every table in a private mib 
and we have a table named configTable in our private mib, the following 
oid was generated:

oid configTable_variables_oid[] = {
  1,    /* iso         */
  3,    /* org         */
  6,    /* dod         */
  1,    /* internet    */
  4,    /* private     */
  1,    /* enterprises */
  1751, /* lucent      */
  2,    /* mibs        */
  79,   /* uAdm        */
  1,    /* uAdm25GigMib */
  1,    /* uAdmConfigObjects */
  1     /* configTable */
};

The following variable table was also generated.

/* 
 * variable2 configTable_variables:
 *   this variable defines function callbacks and type return information 
 *   for the configTable mib section 
 */

struct variable2 configTable_variables[] = {
/*  magic number        , variable type , ro/rw , callback fn  , L,
oidsuffix */
#define   CONFIGINDEX           3
  { CONFIGINDEX         , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,1
} },
#define   CONFIGACTIVELOAD      4
  { CONFIGACTIVELOAD    , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,2
} },
#define   CONFIGSOFTWAREVERSION  5
  { CONFIGSOFTWAREVERSION, ASN_INTEGER   , RONLY , var_configTable, 2, { 1,3
} },
#define   CONFIGSOFTWARESIZE    6
  { CONFIGSOFTWARESIZE  , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,4
} },
#define   CONFIGSIGNATURE       7
  { CONFIGSIGNATURE     , ASN_OCTET_STR , RONLY , var_configTable, 2, { 1,5
} },
#define   CONFIGSOFTWARECRC     8
  { CONFIGSOFTWARECRC   , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,6
} },
#define   CONFIGCURRENTTIME     9
  { CONFIGCURRENTTIME   , ASN_OCTET_STR , RWRITE, var_configTable, 2, { 1,7
} },
#define   CONFIGDEVICECOUNT     10
  { CONFIGDEVICECOUNT   , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,8
} },
#define   CONFIGSONETIFCOUNT    11
  { CONFIGSONETIFCOUNT  , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,9
} },
#define   CONFIGHSIIFCOUNT      12
  { CONFIGHSIIFCOUNT    , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,10
} },
#define   CONFIGUTOPIACOUNT     13
  { CONFIGUTOPIACOUNT   , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,11
} },
#define   CONFIGPKTSRVCCOUNT    14
  { CONFIGPKTSRVCCOUNT  , ASN_INTEGER   , RONLY , var_configTable, 2, { 1,12
} },
#define   CONFIGPROTECTIONSWITCHGRPCOUNT  15
  { CONFIGPROTECTIONSWITCHGRPCOUNT, ASN_INTEGER   , RONLY , var_configTable,
2, { 1,13 } },

};
/*    (L = length of the oidsuffix) */

Now if the subagent were to register for the entire table we would use the  
macro:

  /* register ourselves with the agent to handle our mib tree */
  REGISTER_MIB("configTable", configTable_variables, variable2,
               configTable_variables_oid);

which is generated by mib2c. This works fine. 

In this case though, this table is indexed by a single integer. Each
subagent 
has a unique index and must register for a single row in the mib. For
example
if we assume that a subagent is responsible for the row associated with
index 2, 
we will register with the index using:

  configIndex = register_int_index(configTable_variables_oid, 12, 2);

BTW the table is indexed on the first variable, configIndex.
 
So now I have registered an index and would like to do an index level 
mib registration. I have tried  using several functions in agent_registry.c,

without any luck. 

As I stated before I would like to register for a row or every column for an

entry at a specific index. If we use an index of 2, I would like to register
for the following range of oids:

  1,3,6,1,4,1,1751,2,79,1,1,1,1,[1-13].2
  ^                         ^ ^   ^    ^
  |                         | |   |    |
  +-confTable_variables_oid-+ +---+    +----- index we just registered for
                                |
                                +--------The suffixes in
configTable_variables

The function I am currently working with register_mib_range(). For example:

  register_mib_range("configTable", 
                     (struct variable *)configTable_variables, /*vars in
table */
                     sizeof(struct variable2),  /* size each entry */
                     13,                        /* 13 vars in table */
                     configTable_variables_oid, /* oid of configTable */
                     12,                        /* size of oid */
                     DEFAULT_MIB_PRIORITY,
                     14,                  /* range across variables in table
*/
                     13,                  /* 13 variables in table */
                     NULL);               /* session */

This creates a enormous set of 13 subtrees that each have the all the 
configTable_variables and usually fails to register the mib.

I have tried playing around with mibloc and adjusting the oid I pass in, but
it 
usually fails to register the MIB. I have looked at several of the other 
interfaces in agent_registery.c and they all seem to go through 
register_mib_range which ultimately calls register_mib_context(). I am not 
sure how to use the interfaces provided and I cannot find any examples that 
might shed some light on the issue.
 
How do register for a row under these circumstances? Do you have any ideas.

Thanks in advance,

George 

-----Original Message-----
From: Dave Shield [mailto:D.T...@cs...]
Sent: Thursday, December 07, 2000 4:16 AM
To: Szaboky, George (George)
Cc: ucdavissnmpcoders
Subject: Re: help required : *SNMP managers* and *indexing* 



> I am having trouble doing an index level registration with a master agent.
I
> can register a table just fine. I use the REGISTER_MIB() macro. I have
tried
> using several functions in agent_registry.c without much luck.

This particular feature hasn't received much detailed testing - most
MIb implementations work at a higher level (e.g. full tables).
It wouldn't surprise me too much if this didn't work properly.

What sort of problems are you seeing?

Dave

_______________________________________________
Net-snmp-coders mailing list
Net...@li...
http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders

a simple question:if SNMP agent receive a GET command ,the agent will do somthing to "get " some data.The action that agent will take will be implemented by programme by me?

[<ji...@to...>]

Hello.
 I am a jackaroo.I have a question.if SNMP agent receive a GET command
which posted by a SNMP manager,the agent      will do somthing to "get "
some data.The action that agent should take should be implemented by
programme by me?
 Thanks.

Help with SNMP

[Rasoul H. <rha...@et...>]

Hi there,
I installed the net-snmp. I believe (?) every thing went correctly. I
make the snmpdemoapp using the Makefile that comes with the package but
when I try to execute it I get the following error:
./snmpdemoapp: error in loading shared libraries: libsnmp-0.4.2.so:
cannot open shared object file: No such file or directory

Help please...
-r

Help with snmp

[Rasoul H. <rha...@et...>]

Hi there,
I am new to snmp and I have down loaded the net-snmp and (?) succesfully
installed it. However, when I build the snmpdemoapp.c using the same
Makefile and try executing it I get this error message:
./snmpdemoapp: error in loading shared libraries: libsnmp-0.4.2.so:
cannot open shared object file: No such file or directory

Can any one tell me where I may have gone wrong? I am new to this so
please forgive me if this question sounds silly...
Thanks in advance
-r

Re: Future Plans I - MIB

[<uc...@ra...>]

On Thu, Dec 07, 2000 at 06:06:05PM +0000, Dave Shield wrote:
>     CPU statistics
> 	These are currently held for the system as a whole, and there's
> 	been some confusion over absolute values or percentages.
> 	   Do we wish to try and provide per-CPU statistics for multi-CPU
> 	systems?    As well as, or instead of the overall figure?

IMHO the overall figure should not be removed. It is far more practical
for the user to check a single number than having to consilidate
multiple. And it makes configuration of the monitoring-software a lot
easier when it is supposed to monitor both single- and multiple- CPU
systems. 



-- 
Ragnar Kjørstad

Re: Future Plans I - MIB

[Wes H. <har...@us...>]

>>>>> On Thu, 07 Dec 2000 18:06:05 +0000, Dave Shield <D.T...@cs...> said:

Dave> This is the first of three 'kite-flying' messages, floating some
Dave> ideas regarding the future developments of the Net-SNMP suite.

Ack...  And here I thought I was going to get work done.

Unfortunately, I probably won't respond personally to much of this
until after the IETF conference next week (or maybe on the plane
there, who knows, but its a short fligt).

Dave> The UCD extensions MIB is still carried under the UC Davis
Dave> banner.
Dave> Do we wish to move this across to an new enterprise?

Glad you brought this up.  I'd been meaning to ask the same question.
I think we probably should.

Dave> Currently (almost) everything is in one, monolithic MIB module.
Dave> Practise with other, standard MIBs (e.g. RFC1213), has been to
Dave> move towards splitting them up into separate modules, so that
Dave> they can be developed independently of each other.
Dave> Do we wish to do the same with the UCD MIB?

I've thought of this as well.  Sections of it should go together.  I
think the majority of it would fall under one lump, called something
like NET-SNMP-MONITORING-MIB for the proc/disk/etc stuff.  The
version/mrTable/? would probably fall into a agent specific support
mib.

Dave> Shell/exec handling
Dave> Currently, mapping between the output of the scripts and the
Dave> MIB objects depends on whereabouts in the overall MIB tree that
Dave> the extensible call is registered.
Dave> Do we wish to retain this mechanism, or consider possible
Dave> alternative mappings?

If we do change things, I want to restructure *all* the tables
mentioned above.  Almost all of them should be indexed by strings,
contain a RowStatus column, etc.

Dave> Pass-through handling
Dave> Do we wish a finer level of control over pass-through subagents?
Dave> (e.g. controlling if/how long results are cached,  whether to close
Dave> down a persistent subagent, etc).

Dave> CPU statistics
Dave> These are currently held for the system as a whole, and there's
Dave> been some confusion over absolute values or percentages.
Dave> Do we wish to try and provide per-CPU statistics for multi-CPU
Dave> systems?    As well as, or instead of the overall figure?

Dave> Traps
Dave> The current enterprise-specific traps don't conform to the
Dave> guidlines given in the Co-existance document (in particular with
Dave> regard to the penultimate '0' subidentifier and v1<->v2 mapping)
Dave> Do we wish to change this?

Yes.  You're going to write all of this over the weekend right?

-- 
Wes Hardaker
NAI Labs
Network Associates

Re: IPX support

[Wes H. <har...@us...>]

>>>>> On Thu, 07 Dec 2000 17:25:41 +0000, John Naylon <jb...@ca...> said:

John> I've just updated my pluggable transports patch on the
John> Sourceforge page so it now includes support for IPX on Linux.  I
John> don't really have much I can test it against, other than itself,
John> so I make no promises about it working.  I would expect this
John> code to be highly portable to any system providing IPX sockets.

Excellent!

I'm not going to apply the patch just yet (I'm waiting for a bit more
settlement after the 4.2 release just to make sure there aren't any
serious issues that we missed).

-- 
Wes Hardaker
NAI Labs
Network Associates

[Fwd: Re: Accessing details on triggering request message]

[Michael J. S. <msl...@is...>]

Frank,
Please forgive me for sharing a private posting.
I felt the information you gave was worth sharing.

Thanks for answering my query.
I'll leave the project page suggestion below to Wes.

Regards,
-Mike Slifcak

-------- Original Message --------
From: Frank Strauss <st...@ib...>
Subject: Re: Accessing details on triggering request message
To: "Michael J. Slifcak" <msl...@is...>

>> We are implementing the DISMAN-SCHEDULE-MIB (RFC 2591) as NET-SNMP 4.2
>> agent MIB module. To do this correctly, a registered MIB function
>> needs access to the security credentials of the SNMP message that
>> triggered this function [in detail: the action of a schedule is a Set
>> operation. If it is invoked, it has to use the security credentials
>> that were present when the corresponding row of the schedTable was
>> created.  An implementation must therefore record and maintain the
>> credentials for every scheduling entry.]
>> 
>> Do you have any suggestion how I could retrieve this information
>> information from within the agent module?

Michael> Hi, Frank.  My only comment is the credentials would need to be
Michael> considered for GET as well, right ?

The Schedule MIB's notion of `actions' are only Set operations (no
Get) that write a specific INTEGER value to a specific OID using a
specific context. These three attributes are coloumns of the
schedTable. The set operations (either by sending an SNMP message or
internally in the agent) have to be issued with the same credentials
that have been used to setup the entry in the schedTable that contains
this action.

Michael> Which functions in particular would you see requiring
credential
Michael> access ?  Would this be better implemented as a credential
check
Michael> in the library ?

I don't need an additional credentials *check*. I need *access* to
the credentials in order to use them when I have to issue subsequent
operations. So this cannot be done by the library.

There place where I need access to the credentials is a typical
var_XXXEntry() function that is registered with the agent for the
schedTable.

Michael> I'm shooting from the hip here ...
Michael> If you can get the handle to the SNMP session, you might be
able
Michael> to get the credentials.  But your case is valid, currently
there
Michael> appears no easy way to check the privilege of a given request.

That's what I have guessed. :-(


Michael> P.S.  Would you please re-tell me where your work in progress
is
Michael> located ?  Thanks !

Geographically we are located at the Technical University in
Braunschweig, Germany. We already did a DISMAN-SCRIPT-MIB
implementation (`Jasmin', a joint project with NEC Europe). I
personally, did the TUNNEL-MIB hack on my spare time a few weeks ago.

The status of the Schedule MIB implementation is still very immature.
(Maybe, you want to add an entry to the project page, anyway?)

Does this answer your question on `location'? Maybe, I misunderstood it.

Future Plans III - Agent

[Dave S. <D.T...@cs...>]

This is the third of three 'kite-flying' messages, floating some ideas
regarding the future developments of the Net-SNMP suite.   This message
concerns issues relating to the agent.   The accompanying messages cover
the UCD MIB and library respectively.

   Please feel free to comment on any of these, or to add any other ideas
that occur to you.   This is probably the best chance we'll ever have to
regroup and plan for the future, and I'm keen that we make the most of it.


   MIB module API
	The MIB module API was inherited from the original CMU
	suite, and is occasionally proving restrictive.  Do we
	wish to extend or replace it?

   Table handling
	There is a start at simple cached table handling.  Do we
	want to make more use of this?   One possible extension would
	be support for "persistently indexed" tables, which are commonly
	mentioned in MIBs, and conveniently ignored in implementations.
	Could/Should the "complex table" routines be used instead?

   Existing modules
	A start has been made at cleaning up these implementations,
	to make them easier to follow and maintain.  Do we wish to
	continue this, and start using these versions in earnest?
	Do we wish to extend and update these existing modules?
	(e.g. newer versions of the mib-2 routines)

    MIBs and "internal" features
	Certain "mib modules" actually implement internal features,
	necessary for the correct operation of the agent.  (e.g.
	VACM access control, notifications, AgentX).
	   How closely linked should the features and the corresponding
	MIBs be?

    Agent file organisation
	The organisation of the code files is somewhat arbitrary,
	and is not always optimal.  Should we consider how routines
	are grouped together - particularly with regard to embedded
	subagent use.

    Threading
	The agent currently assumes a simple, single-threaded model.
	Is it worth investigating a multi-threaded approach - e.g.
	processing varbinds in parallel?

    Subagent APIs
	The agent may need to co-exist with various other agents.
	Is it worth investigating providing "subagent" connectivity
	with (e.g.) Sun, Microsoft, SNMP Research, etc


Over to you....

Dave

Future Plans II - Library

[Dave S. <D.T...@cs...>]

This is the second of three 'kite-flying' messages, floating some ideas
regarding the future developments of the Net-SNMP suite.   This message
concerns issues relating to the programming library.   The accompanying
messages cover the UCD MIB and agent respectively.

   Please feel free to comment on any of these, or to add any other ideas
that occur to you.   This is probably the best chance we'll ever have to
regroup and plan for the future, and I'm keen that we make the most of it.



Library-related issues:

    Modularisation
	The current code is not always particularly easy to understand
	and maintain (e.g. the monstrosity that is 'snmp_api.c'!)
	Do we wish to try and re-structure the internal organisation of
	the library in a more logical and modular manner?
		(leading question m'lud!)

    Other packages
	It has been suggested that we might consider using externally
	provided packages for certain aspects of the library support
	(e.g. option handling, 'glib' portability routines, libsmi)
	   Is this worth pursuing?

    Programmer APIs
	Should we review the public APIs we provide for those wishing to
	write fairly simple SNMP applications - to facilitate the more
	common requirements?
	   (e.g. single-shot requests, hiding the 'session' handling;
	    setting up authenticated/encrypted requests, etc)

    I/O handling
	The handling of direct SNMP-related I/O is currently separate
	from the recent routines for "other" I/O handling.  Should these
	be consolidated?

    conf handling
	Should we provide routines for more-consistent handling of
	configure directives?  (e.g. command options, conf file parsing
	utilities routines, standardised environmental variables)

    Other APIs
	We've floated the idea of providing a WinSNMP wrapper to the
	UCD library.  Is this worth pursuing?   What other library
	interfaces could/should we look at?

Over to you....

Dave

Future Plans I - MIB

[Dave S. <D.T...@cs...>]

This is the first of three 'kite-flying' messages, floating some ideas
regarding the future developments of the Net-SNMP suite.   This message
concerns issues relating to the UCD-SNMP-MIB local extensions.   The
accompanying messages cover the library and agent respectively.

   Please feel free to comment on any of these, or to add any other ideas
that occur to you.   This is probably the best chance we'll ever have to
regroup and plan for the future, and I'm keen that we make the most of it.


MIB-related issues:

   Naming
	The UCD extensions MIB is still carried under the UC Davis banner.
	Do we wish to move this across to an new enterprise?
	   (If not, then this may swing things against a lot of the
	other proposed changes)

   Modularity
	Currently (almost) everything is in one, monolithic MIB module.
	Practise with other, standard MIBs (e.g. RFC1213), has been to
	move towards splitting them up into separate modules, so that
	they can be developed independently of each other.
	   Do we wish to do the same with the UCD MIB?

    Shell/exec handling
	Currently, mapping between the output of the scripts and the
	MIB objects depends on whereabouts in the overall MIB tree that
	the extensible call is registered.
	   Do we wish to retain this mechanism, or consider possible
	alternative mappings?

    Pass-through handling
	Do we wish a finer level of control over pass-through subagents?
	(e.g. controlling if/how long results are cached,  whether to close
	down a persistent subagent, etc).

    CPU statistics
	These are currently held for the system as a whole, and there's
	been some confusion over absolute values or percentages.
	   Do we wish to try and provide per-CPU statistics for multi-CPU
	systems?    As well as, or instead of the overall figure?

    Traps
	The current enterprise-specific traps don't conform to the
	guidlines given in the Co-existance document (in particular with
	regard to the penultimate '0' subidentifier and v1<->v2 mapping)
	    Do we wish to change this?


Over to you....

Dave

Re: ucd-snmp-4.2 is released

[<gm...@no...>]

congratulations!

btw see question below.

%% Regarding ucd-snmp-4.2 is released; you wrote:


  wh> Are there binaries available?
  wh> ----------------------------

  wh>   - There are binaries for some systems available in the binaries
  wh>     directory on the web/ftp sites.  Binaries can not legally include
  wh>     support for privacy (encryption) due to US exportation laws.  If
  wh>     you need privacy support, please get the source code and build it
  wh>     for yourself (requires OpenSSL).

Is this still true...I guess I should not build the win32 with OpenSSL
in still.

-GSM

-- 
G.S. Marzot                        email: gm...@no...
Nortel Networks                    voice: (978)288-3990
600 Tech Park  M/S E65-60-405      
Billerica, MA  01821                 fax: (978)670-8145

Re: Thinking about SNMP::Community extension

[<gm...@no...>]

%% Regarding Thinking about SNMP::Community extension; you wrote:

  tr> Hi, Joe.  I've taken on the task of getting all of the SNMP
  tr> community strings out of our sources so they aren't publicly
  tr> readable (I know, ouch, it was like that when I found it ;^/ ) The
  tr> hard part is figuring out how to make the community strings
  tr> accessible with minimal difficulty.

Hmmm..this is interesting. Removing them from script files is only part
of the problem as you may know. v1 community strings are transmitted as
clear text on the wire and it is very trivial to sniff them. Hopefully
no one is getting a false sense of security.

  tr> So I've been thinking of ways to do this -- the obvious one is to
  tr> pull the strings out into, say, /etc/communities (perhaps modeled
  tr> after the NetSNMP snmpd.conf file?), and then read and parse it in
  tr> each script.  Of course, this means I'd have to open-code this for
  tr> each script (or add it to a library).  So the obvious thing to do
  tr> is to add it to the SNMP.pm module.

there are a number of ways you could do this. You could put the
SNMP::CommunityDB package in a new module of your
definition(SNMP/CommunityDB.pm) and just use SNMP; and use
SNMP::CommunityDB; in your scripts to reuse it. I think we should think
a bit more if this is really a universally applicable feature. I have
tried to keep the 'SNMP.pm' module down to core type features. There is
a module out on CPAN called SNMP::Util - I could imagine this community
cache being in there, maybe something like
SNMP::Util::CommunityDB. (note the name change from what you
suggest...the class you are making isn't the community itself but a
repository database of host->community mappings no?)

  tr> I think it would make sense to implement an SNMP::Community object that
  tr> could be used to look up (in some database somewhere TBD) the SNMP
  tr> authentication data for a given host.  It would probably need to be
  tr> hierarchical, and handle distinct (multiple?) SNMP community strings for
  tr> any given host or set of hosts.

  tr> This is an area with which I'm very unfamiliar (community/v3 auth
  tr> strings in general).  In your opinion, is this a useful feature to
  tr> pursue?  Have you put any thought into solving this problem?  Is
  tr> there a mechanism already in place to handle the problem of
  tr> storing the SNMP secrets?  If we do implement such a beast, would
  tr> you be interested in pulling it into the distribution (assuming
  tr> it's not a complete piece of crap ;^) ?

The net-snmp library has a api's for manipulating V3 user entries in the
USM and we definitely need some way from within the 'SNMP.pm' module to
access that stuff I think(addUser,deleteUser,updateUser etc.). 

right now it is handled in a somewhat kludgey way at session creation
time (essetially a new user is created for you from the parameters
passed to session creation api). This leads to undefined behaviour when
the same user name is used in multiple sessions. Wes has talked about
possibly maintaining multiple user tables inside the library perhaps per
session (or I could imagine wanting share some users across sessions as
well, presuming the session is talking to the same target).

There is still the problem of populating these tables - the config file
mechanism supported in net-snmp today provides one way...but we have to
be very careful when mixing this with Perl/SNMP. the SNMP.pm module
today does not use any config file based initialization...

(I have copied the coders on this, I hope you don't mind)


-GSM

-- 
G.S. Marzot                        email: gm...@no...
Nortel Networks                    voice: (978)288-3990
600 Tech Park  M/S E65-60-405      
Billerica, MA  01821                 fax: (978)670-8145

IPX support

[John N. <jb...@ca...>]

Hi,

  I've just updated my pluggable transports patch on the Sourceforge page so 
it now includes support for IPX on Linux.  I don't really have much I can 
test it against, other than itself, so I make no promises about it working.  
I would expect this code to be highly portable to any system providing IPX 
sockets.

  To patch the current CVS code, do something like:

  % patch -p0 < plug-patch

from the top-level of the net-snmp hierarchy.  Run autoconf before 
configuring for the first time.  To include IPX support, you need to add 
--with-transports=IPX to your configure line.

  After patching and rebuilding the agent and applications, you can do 
things like:

  % snmpget -v2c ^:00D0B7AAE308 public sysDescr.0

where the hexadecimal string is an IPX node number.  The '^' is just a 
hackish way of indicating that this is an IPX-domain address.  The default 
network number and port (defined by RFC 1420 to be 36879) are assumed in 
this case, but they may be specified explicitly:

  % snmpget -v2c ^00000000:00D0B721C6C0/23456 public sysDescr.0

The syntax for the agent is slightly different (for compatibility reasons) 
-- to listen on IPX port 23456 as well as the standard UDP port, you would 
say:

  % snmpd -p ipx:/23456,udp:161

  I've attached the gzipped patch too.

John

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

Re: Accessing details on triggering request message

[Dave S. <D.T...@cs...>]

> We are implementing the DISMAN-SCHEDULE-MIB (RFC 2591) as NET-SNMP 4.2
> agent MIB module. To do this correctly, a registered MIB function
> needs access to the security credentials of the SNMP message that
> triggered this function

> Do you have any suggestion how I could retrieve this information
> information from within the agent module?

As things currently stand, I don't think this is possible (as I'm
sure you've realised).   I think what's really required is to
extend the MIB module API.  This is one of a number of issues that
I've been planning to raise recently - I've just been waiting until 4.2
was out of the door.

I'm putting together an initial list of issues that we might look
at.  I'll try and get them send out for discussion ASAP.

Dave

Re: Problems for OpenBSD 2.8 agent (4.2 release)

[<ni...@ba...>]

On Thu, 07 Dec 2000 08:37:28 -0500 "Michael J. Slifcak" <msl...@is...> wrote:
>ni...@ba... wrote:
>>
>> On Tue, 05 Dec 2000 15:59:19 -0500 "Michael J. Slifcak" <msl...@is...> wrote:

>> >nlist error for cnt or _cnt not found.
>>
>> Hmmm, you will probably have to find some sysctl to get the value on 2.8
>
>Good suggestion, Niels.  What does OpenBSD 2.6 or 2.7 return ?

I seem to remember that OpenBSD has changed to use the UVM vm system, so you
might look at the {vmstat,memory}_netbsd1.c files as NetBSD also uses that.

/Niels


-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su