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: fenner@gmail.comTo: dirkjurjen@hotmail.comCC: 
net-snmp-users@lists.sourceforge.net
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: michael.shcwa...@compass-eos.com
To: da...@oliver-solutions.com; dirkjur...@hotmail.com; 
net-snmp-users@lists.sourceforge.net
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:da...@oliver-solutions.com]


Sent: Wednesday, December 11, 2013 10:19 AM

To: Dirk Buijsman; net-snmp-users@lists.sourceforge.net

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
Net-snmp-users@lists.sourceforge.net
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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to