If one was to implement the snmp-community-mib, would the following be a
reasonable approach?
- define formats for new snmpd.conf directives for each of the
implemented transports corrosponding to
the nonVolatile com2sec rows, e.g. comm2SecUdp, comm2SecUdp6,
comm2SecUnix, or a single
"commCommunity" with bits to specify the transport info (extensible?)
- in each snmplib/snmp{UDP,UDP6,Unix}Domain.c, add a call to
register_app_config_handler(),
e.g. "comm2SecUdp", comm_parse_com2secUdp
- for a given transport, whenever *either* config parser finsihes
succesfully, set a "changed" flag (see blow)
- add a new agent/mibgroup/mibII/comm.c that would
- have the requisite config_*() stuff
- call the various (new)
snmplib/snmp{UDP,UDP6,Unix}Domain.c:store_comm_{udp,udp6,unix}
- have the REGISTER_MIB("mibII/comm...",var_comm_) init stuff
- implement the mib access routines var_comm_..., write_comm* etc...
which check the above flag to see if the community list needs
to be rebuilt from the various
transport -specific com2sec lists. I think this is needed
since a read-config could have been
done without us knowing and we need to get the ordering of
our community list right
- snmplib/comm.c seems like the right place to put the list, i.e.
comm_{get,create,destroy}CommunityEntry...
This "layer" would in turn call the various
snmplib/snmp{UDP,UDP6,Unix}Domain.c routines as needed.
- add an apps/snmpcomm with create and delete functions and arguments
for communityname, secname,
source, transport (or merge the last two like the snmpd listening
address), and optional context and
context engineid
I'm still working out:
- is this impossible to do without changing snmplib, i.e. as a dlmod()
module? I would need to store
(persistently) any nonVolatile communities myself, yes?
- where the TargetAddrExtTable data goes and how it is accessed/mutated,
and if/how the targetTable
would interact.
Dana
From: Dave Shield <[EMAIL PROTECTED]> - 2006-08-25 11:31
On 25/08/06, Passera Pablo-APP015 <[EMAIL PROTECTED]> wrote:
> We are trying to generate the code for the COMMUNITY-MIB using
> mib2c MFD. There is an index there that has the following ASN
> specification
> INDEX { IMPLIED snmpCommunityIndex }
> Looking at the code mib2c generates we found....
> var_snmpCommunityIndex.type = ASN_OCTET_STR;
>
> The var_snmpCommunityIndex.type is ASN_OCTET_STR instead of
> ASN_PRIV_IMPLIED_OBJECT_ID.
Yes - you should correct this assignment.
> the existent code in the
> snmpNotifyFilterTable.c is the following:
> var_snmpNotifyFilterSubtree.type = ASN_PRIV_IMPLIED_OBJECT_ID;
>
> Where the var_snmpNotifyFilterSubtree.type has the correct type.
> We know that the notify filter table implementation was generated using
> the mib2c, but we are not able to generate the same code.
Note that the output of mib2c is intended as a *template* - not
necessarily a 100% correct framework, but something to get you
started. I don't know exactly the history of this particular module,
but I suspect that the IMPLIED handling was tweaked manually
afterwards.
> Is there any mib2c configuration that we are missing?
No - I don't think so.
A quick scan of the mib2c code seems to indicate that it ignores
IMPLIED completely.
Robert will doubtless correct me if I'm wrong here.
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
