On 09/04/2008, Johns Victor <[EMAIL PROTECTED]> wrote:
> I am trying to extend the net-snmp agent v5.4.1 of net-snmp using the
> mib2c.mfd.conf file and have run into some problems.
I have no experience of the MfD framework, so I'll leave that aspect
of things to someone else. You might want to pop over to the #net-snmp
IRC channel, and see if Robert can give you some advice. I'm not sure
how closely he follows the mailing lists.
> I have included the ENTABLE-MIB.txt file.
A few comments:
entable MODULE-IDENTITY
:
Author: Patrice Kadionik
ENSEIRB, School of Electrical Engineering
:
DESCRIPTION "MIB for remote control by SNMP"
::= { enterprises 9363 }
-- ::= { enterprises 9362 }
Enterprise number 9363 is assigned to "Spelio" (spelio.net.ru)
If you're working with ENSEIRB (as the MIB implies), you should
speak to Patrice to get a portion of the 9362 subtree set aside for
your use.
If you're working with Thomson.Net (as your email imples),
then you should speak with Tanguy Millet to get a portion of
the 28322 enterprise subtree assigned to you.
If you're working on your own, then feel free to use the
NET-SNMP-MIB::netSnmpPlaypen subtree, which has
been set aside for exactly this purpose.
But please do not simply grab enterprise numbers out of thin
air. There is a formal mechanism for assigning these numbers
(free!), and it's incredibly rude to muscle in on someone else's
patch.
ledIndex OBJECT-TYPE
SYNTAX INTEGER { 0..32768}
MAX-ACCESS read-write
Index objects should normally be "not-accessible".
The index value is included in the other OIDs, and there's
no point in revealing the index object itself.
DESCRIPTION
"defines the index into the LedEntry table object. How is
this settable ??"
::= { ledEntry 2 }
By creating/deleting rows in the table.
You need to say something about how this should be done.
(or even if it's possible at all). Given that all of your MIB
objects are "read-write" rather than "read-create", this implies
that rows cannot be created via SNMP - only via the underlying
subsystem.
In which case, it's worth saying so explicitly in the table
DESCRIPTION.
led0 OBJECT-TYPE
SYNTAX Integer32 {0..1}
What does the value 0 mean? What does 1 mean?
You would be better to define an enumeration such as
led0 OBJECT-TYPE
SYNTAX INTEGER {
off(0),
on(1)
}
DESCRIPTION "Led 0 connected to bit 0 of parallel port. Table
implementation"
DESCRIPTION "Led 1 connected to bit 1 of parallel port. Table
implementation"
etc
DESCRIPTION "Led 6 connected to bit 6 of parallel port.
Table implementation"
What happens when you need to support a slimmed down version, with only
four LEDs? Or a beefed up version with 32 LEDs? Not to mention the error
in the final description above. (Presumably you meant 7, not 6)
This is screaming out for a second-level table:
ledBit{Table,Entry}
DESCRIPTION
" Entry containing about an individual LED bit"
INDEX {ledIndex, ledBitIndex }
LedBITEntry ::=
SEQUENCE {
ledBitIndex Integer32,
ledBit INTEGER
}
That would allow you to support any size of LED interface
(even a mixture of sizes), without needing to change the MIB.
So your original ledTable would just contain the ledDesc object
(perhaps plus an ledStatus object, if you want to create/delete
rows using the standard machanism).
I'll leave Robert to advise how best to implement this using the
MfD framework.
Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
