The information presented in this section must be taken as guidelines and not exact procedures. Your specific implementation will vary from the guidelines presented.
You can keep your existing DPI 1.1 subagent and communicate with a DPI capable agent that supports DPI 1.1 in addition to DPI 2.0. For example, the SystemView Agent provides support for multiple versions of DPI, namely Version 1.1 and Version 2.0.
Note: Although DPI Version 1.1 is supported, it is recommended that you migrate to Version 2.0.
Normally you would compile your DPI 1.1 subagent with the DPI 1.1 <dpi\snmp_dpi.h> include file and link-edit it with the DPI 1.1 level DPI32DLL.LIB. At run time, you then need access to the DPI32DLL.DLL. You can continue to do this until you are ready to migrate to DPI Version 2.0.
In the snmp_dpi.h include file for DPI 2.0, you may find references to DPI 1.1 compatibility mode under control of compiler flags, such as:
/DSNMP_DPI_VERSION=1 /DSNMP_DPI_RELEASE=0 /DSNMP_DPI_VERSION=1 /DSNMP_DPI_RELEASE=1
However, this compatibility mode is not provided with the SystemView Agent. If you want to convert to DPI 2.0, which prepares you also for SNMP Version 2, you must make changes to your code.
Name Changes
A number of field names in the snmp_dpi_xxxx_packet structures have changed so that the names are now more consistent throughout the DPI code.
The new names indicate if the value is a pointer (_p) or a union (_u). The
names that have changed and that affect the subagent code are listed in
the table below. ┌────────────────┬────────────────┬─────────────────────────┐
│ OLD NAME │ NEW NAME │ DATA STRUCTURE(XXXX) │
├────────────────┼────────────────┼─────────────────────────┤
│ group_id │ group_p │ getnext │
├────────────────┼────────────────┼─────────────────────────┤
│ object_id │ object_p │ get, getnext, set │
├────────────────┼────────────────┼─────────────────────────┤
│ value │ value_p │ set │
├────────────────┼────────────────┼─────────────────────────┤
│ type │ value_type │ set │
├────────────────┼────────────────┼─────────────────────────┤
│ next │ next_p │ set │
├────────────────┼────────────────┼─────────────────────────┤
│ enterprise │ enterprise_p │ trap │
├────────────────┼────────────────┼─────────────────────────┤
│ packet_body │ data_u │ dpi_hdr │
├────────────────┼────────────────┼─────────────────────────┤
│ dpi_get │ get_p │ hdr (packet_body) │
├────────────────┼────────────────┼─────────────────────────┤
│ dpi_getnext │ next_p │ hdr (packet_body) │
├────────────────┼────────────────┼─────────────────────────┤
│ dpi_set │ set_p │ hdr (packet_body) │
├────────────────┼────────────────┼─────────────────────────┤
│ dpi_trap │ trap_p │ hdr (packet_body) │
├────────────────┼────────────────┼─────────────────────────┤
│ │ │ │
└────────────────┴────────────────┴─────────────────────────┘
There is no clean approach to make this change transparent. You probably will have to change the names in your code. You may want to try a simple set of defines like:
#define packet_body data_u #define dpi_get get_p #define dpi_set set_p #define dpi_next next_p #define dpi_response resp_p #define dpi_trap trap_p #define group_id group_p #define object_id object_p #define value value_p #define type value_type #define next next_p #define enterprise enterprise_p
However, the names may conflict with other definitions that you have, in which case you must change your code.
Related Information