RE: mib2c.table_data.conf quastion/issue

Dirk Buijsman <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>


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 -0800Subject: Re: mib2c.table_data.conf quastion/issueFrom: [email protected]: [email protected]: [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]
To: [email protected]; [email protected]; [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]

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]
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
|||||||||||||||||||||||||||||||||||

------------------------------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.