Hi all,
I noticed that smidump creates the same method twice when it dumps jax
output for an entry in my MIB. I saw the same behaviour also with other
(surely correctly formatted MIBs).
For example, my MIB looks like this:
....
allOpsEntry OBJECT-TYPE
SYNTAX AllOpsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION ""
INDEX { identifier }
::= { allOpsTable 1 }
AllOpsEntry ::= SEQUENCE {
identifier Integer32,
sender DisplayString,
recipient DisplayString
}
....
No errors are reported by smidump, but the generated code for AllOpsEntry
goes like:
...
public int get_identifier()
{
return identifier;
}
public int get_identifier()
{
return identifier;
}
...
I would be happy if someone could help me,
Joerg.
--
!! This message is brought to you via the `libsmi' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>.
!! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi All,
I was trying to run the RFC1213 through smidump to create an XML file. I get
the following errors:
---------------------------------------------------------------
$ ./smidump -fxml -pRFC1155-SMI.txt -pRFC-1212.txt -oaaa rfc1213_new.txt
failed to locate MIB module `RFC-1212'
rfc1213_new.txt:262: index element `ifIndex' of row `ifEntry' must have a
range
restriction
rfc1213_new.txt:609: index element `atIfIndex' of row `atEntry' must have a
rang
e restriction
rfc1213_new.txt:1301: index element `ipNetToMediaIfIndex' of row
`ipNetToMediaEn
try' must have a range restriction
smidump: module `rfc1213_new.txt' contains errors, expect flawed output
-----------------------------------------------------------------
I used the RFC1213 located at:
http://www.ibr.cs.tu-bs.de/projects/libsmi/orig/RFC1213-MIB
The module files I used are attached!
Any help will be highly appreciated!
Thanks!
Yogini
Hi!
Time for a new release... 0.2.14 is on the FTP server.
o As always this release fixes a number of bugs.
o Some new and updated IETF standards track modules have been added.
o Some new checks have been added, concerned with the handling of
SEQUENCEs, the proper usage of some SMIv2 TCs, and with
node/group/compliance status constraints.
o A new (expierimental) smidump format has been added for Juergen's
stools project (http://www.ibr.cs.tu-bs.de/projects/stools/).
See the ChangeLog file for more details. As usual the current release
can be found at
http://www.ibr.cs.tu-bs.de/projects/libsmi/
ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/
Enjoy,
-frank
--
!! This message is brought to you via the `libsmi' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>.
!! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi,
Suppose you try to create a subagent using the output from "smidump -f
netsnmp".
In the header file you get definitions like
typedef struct yourMib {
uint32_t *foo;
void *_clientData;
uint32_t __foo;
} yourMib_t
Now take a look a the switch statement that takes care of returned the
correct value to the master agent (switch based on vp's magic number).
It looks like this:
static yourMib_t yourMib;
// ...
return (unsigned char *) &yourMib.foo;
However, what the master agent is actually expecting is a pointer to
the value, not a pointer to the pointer to the value. Looks nice in
those snmpwalk outputs, such memory addresses :-)
Is this a problem with libsmi or am I overlooking something?
On a sidenote, what I am supposed to use *_clientData and __foo in the
example above for?
Thanks,
Remco.
--
!! This message is brought to you via the `libsmi' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <libsmi-request(a)ibr.cs.tu-bs.de>.
!! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
