On Thu, 10 Feb 2005 10:16:54 -0500 Jeff wrote: JO> > > I have an embedded Linux system with some interfaces that are not JO> > > "standard", i.e. the default ifTable implementation isn't getting part JO> > > or all of the information. From looking at the code, it appears that I JO> > > willneed to directly modify the source that comes with net-snmp. JO> JO> This is basically the approach I was thinking. Disable the automatic build JO> of the IF-MIB, copy the IF-MIB code and modify it for our system and build JO> it as a dynamically loadable module. I was hoping I'd be able to write a JO> separate module that would fix some ifType entries and add some interfaces. JO> That way I would have less worry about my custom ifTable getting out of JO> sync with the Net-SNMP ifTable as new versions of Net-SNMP are released.
Ok, since the two of your seem gung-ho on mixing in extra interfaces, here's the scoop. The problem with mixing interfaces is the ifIndex. By definition, the index to a table for a particular row must remain constant for the lifetime of the agent process. [Note that this is not true for the existing mibII/interfaces.c implementation for some platforms. Bringing interfaces up and down can re-order the table, which is bad new for someone trying to monitor a particular interface.] So the trend is to try and use the ifIndex from the kernel, wherever possible. The new IF-MIB implementation (in if-mib/*) does this. So, if you want to mix in proprietary interfaces that the kernel doesn't know about, how do we ensure that the ifIndex values don't clash? The easiest way is probably to define an offset for ifIndexes for the proprietary interface types. For an embedded system, this is probably pretty easy, as the interfaces will likely remain constant. But it isn't too hard to imagine a scenario where a conflict could occur. So, if you've evaluated the risk and found it acceptable, select an offset you are comfortable with. Now, how to integrate with the existing code? I recommend using the new IF-MIB implementation, because I think that is the direction that the code base is moving. The old implementation will probably be phased out (off by default) over the next few releases. If you platform is Linux, then the bulk of the work is already done. [If it is some other platform, then the old style code needs to be ported to the new style.] You will have to patch the agent, but it should be a one line patch to call your code to add the additional interfaces. There are two places where you could put the call. The key function is netsnmp_arch_interface_container_load(). This function is called from netsnmp_access_interface_container_load() in if-mib/data_access/interface_common.c. It's purpose is to populate a container with interface entries. The Linux implementation is in if-mib/data_access/interface_linux.c, which should serve as your example of how to create and add entries. You can add a call to your function before, after or inside the *_arch_* call. You will need to configure with --enable-mfd-rewrites (recommended) or explicitly exclude the mibII/interfaces module and include the if-mib modules. -- Robert Story; NET-SNMP Junkie Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-users> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ 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
