RE: mib2c.table_data.conf quastion/issue

Hi Dirk,

I guess you can file a bug-report, I just edited the mib2c.table_data.conf  file to suit my requirements.

BR,
Michael

From: Dirk Buijsman [mailto:[email protected]]
Sent: Thursday, December 12, 2013 1:04 AM
To: Michael Shcwarcz; David Ganor; [email protected]; Bill Fenner
Subject: RE: mib2c.table_data.conf quastion/issue

Thanks for the replies.
Michael, your solution works. Should I file a bug-report?

When I run mib2c on a standard the standard IF-MIB I get the same type of result, so I think that rules the MIB out:
"mib2c -c mib2c.table_data.conf ifTable"

    /* Typical data structure for a row entry */
struct ifTable_entry {
    /* Index values */
    long ifIndex;

    /* Column values */
    long ifIndex;
    char ifDescr[NNN];
    size_t ifDescr_len;
    long ifType;
    long ifMtu;
    u_long ifSpeed;
    char ifPhysAddress[NNN];
    size_t ifPhysAddress_len;
    long ifAdminStatus;
    long old_ifAdminStatus;
    long ifOperStatus;
    u_long ifLastChange;
    u_long ifInOctets;
    u_long ifInUcastPkts;
    u_long ifInNUcastPkts;
    u_long ifInDiscards;
    u_long ifInErrors;
    u_long ifInUnknownProtos;
    u_long ifOutOctets;
    u_long ifOutUcastPkts;
    u_long ifOutNUcastPkts;
    u_long ifOutDiscards;
    u_long ifOutErrors;
    u_long ifOutQLen;
    oid ifSpecific[NNN];
    size_t ifSpecific_len;

    int   valid;
};


Thanks!
Dirk


________________________________
Date: Wed, 11 Dec 2013 06:42:32 -0800
Subject: Re: mib2c.table_data.conf quastion/issue
From: [email protected]<mailto:[email protected]>
To: [email protected]<mailto:[email protected]>
CC: [email protected]<mailto:[email protected]>

It looks like the mib2c file was written assuming that MIBs follow the SMIv2 practice of making INDEX objects not-accessible.

   Objects which are both specified in the INDEX clause of a conceptual
   row and also columnar objects of the same conceptual row are termed
   auxiliary objects.  The MAX-ACCESS clause for auxiliary objects is
   "not-accessible"

  Bill

________________________________
From: [email protected]<mailto:[email protected]>
To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: RE: mib2c.table_data.conf quastion/issue
Date: Wed, 11 Dec 2013 10:57:10 +0000

Hi,



The duplicate fields are generated because of this line:

    @foreach $c column@



After the index values are generated it generates all the entry fields again (including the indexes).

Try replace the above line with this line:

   @foreach $c nonindex@



BR,

Michael Schwarcz



From: David Ganor [mailto:[email protected]]
Sent: Wednesday, December 11, 2013 10:19 AM
To: Dirk Buijsman; [email protected]<mailto:[email protected]>
Subject: Re: mib2c.table_data.conf quastion/issue



Hi,
Can you show how did you define the channelTable in the MIB file?
I suspect we might find something there...

BR,
David Ganor

On 11/12/2013 02:50, Dirk Buijsman wrote:

I generated a C-skeleton using mib2c -c mib2c.table_data.conf MY.MIB.

A part of the output is the structure:



struct channelTable_entry {

    /* Index values */

    char channelName[NNN];

    size_t channelName_len;



    /* Column values */

    char channelName[NNN];

    size_t channelName_len;

    long count;

    char message[NNN];

    size_t message_len;

    char lastMessageTime[NNN];

    size_t lastMessageTime_len;



    int   valid;

};



Obviously this gives a build error due to identical entries. What is the reason duplicate fields are generated? I looked a bit into the mib2c.table_data.conf file, but could not figure out where "index@" originates from.



What causes this?



Thanks,

Dirk



    /* Typical data structure for a row entry */

struct ${i}_entry {

    /* Index values */

    @foreach $idx index@

     @if $idx.needlength@

    $idx.decl $idx[NNN];

    size_t ${idx}_len;

     @else@

    $idx.decl $idx;

     @end@

    @end@



    /* Column values */

    @foreach $c column@

    @if $c.readable@

     @if $c.needlength@

    $c.decl $c[NNN];

    size_t ${c}_len;

     @else@

    $c.decl $c;

     @end@

     @if $c.settable@

      @if !$c.rowstatus@

       @if $c.needlength@

    $c.decl old_$c[NNN];

    size_t old_${c}_len;

       @else@

    $c.decl old_$c;

       @end@

      @end@

     @end@

    @end@

    @end@



    int   valid;

};



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

Rapidly troubleshoot problems before they affect your business. Most IT

organizations don't have a clear picture of how application performance

affects their revenue. With AppDynamics, you get 100% visibility into your

Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!

http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk



_______________________________________________

Net-snmp-users mailing list

[email protected]<mailto:[email protected]>

Please see the following page to unsubscribe or change other options:

https://lists.sourceforge.net/lists/listinfo/net-snmp-users



--

Best regards,

David Ganor



|||||||||||||||||||||||||||||||||||

Cell: +972-54-3090299

Tel: +972-74-7028642

Fax: +972-153-74-7028642



SW developer

www.oliver-solutions.com<http://www.oliver-solutions.com>

|||||||||||||||||||||||||||||||||||

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users