Using net-snmp 5.1.1, I have generated code for
ifxTable with mib2c. Specifically, I'm dealing with
IF-MIB::ifLinkUpDownTrapEnable
(.1.3.6.1.2.1.31.1.1.1.14.port). If I use snmpset to
set a single instance (e.g.,
IF-MIB::ifLinkUpDownTrapEnable.5), all is well.
However, the code below in a client does not work. The
trap enable for the _first_ port gets set over and over
again and ends up with the value from the links[NUM_IF-1].
What I see when I add printf()s to the
ifXTable_handler() generated by mib2c is that the
MODE_SET_RESERVE1 clause shows unique data_context
values (1..NUM_IF) but in the MODE_SET_ACTION clause
for COLUMN_IFLINKUPDOWNTRAPENABLE, ci->data_context is
always 1. I suspect something earlier in the table
handler failed to store unique context information for
each request.
(When I change my client code to send one request per
port, all is well.)
// IF-MIB::ifLinkUpDownTrapEnable
(.1.3.6.1.2.1.31.1.1.1.14).
// 0 replaced by port number below.
static oid link_OID[] = { SNMP_OID_MIB2, 31, 1, 1, 1,
14, 0 };
static size_t link_OID_len = OID_LENGTH(link_OID);
int SetTrapsEnabled(int links[])
{
struct snmp_pdu *pdu;
struct snmp_pdu *response;
size\_t port;
int status;
int retval;
char value\[32\];
/\*
\* Create the PDU for the data for our request.
\*/
pdu = snmp\_pdu\_create\(SNMP\_MSG\_SET\);
for \(port = 0; port < NUM\_IF; ++port\) \{
link\_OID\[link\_OID\_len-1\] = port+1;
sprintf\(value, "%d", links\[port\]\);
snmp\_add\_var\(pdu, link\_OID, link\_OID\_len, 'i',
value);
}
/\*
\* Send the Request out.
\*/
status = snmp\_synch\_response\(ss, pdu, &response\);
if \(status == STAT\_SUCCESS\) \{
retval = SXSNMP\_SUCCESS;
\} else \{
snmp\_log\(LOG\_ERR, "Unable to set trap enable
values\n");
retval = SXSNMP_FAILURE;
}
if \(response\)
snmp\_free\_pdu\(response\);
return retval;
}
Logged In: YES
user_id=76148
which config file did you use with mib2c?
have you tried to reproduce the problem with 5.1.2?
Logged In: YES
user_id=107514
config file? Damifino. The file starts:
/*
* Note: this file originally auto-generated by mib2c using
* : mib2c.iterate_access.conf,v 1.6 2003/09/29
22:30:36 hardaker Exp $
*/
Does that answer your question?
No, I haven't tried with 5.1.2. I don't have it installed.
I did review CVS histories of likely suspects and didn't
find anything that seemed to address this problem.
Logged In: YES
user_id=76148
This looks like a likely suspect...
2004-04-01 12:19 hardaker
* agent/helpers/table_iterator.c:
- Various patches to fix iterator problems with multiple
varbinds.
Here is a diff between the current code and 5.1.1. You might
want to try this patch, though I can't gurantee it doesn't
depend on other changes...
Logged In: YES
user_id=107514
I'd already downloaded that file and rebuilt. I can't
guarantee that I did the build and install correctly -- I
was in a hurry on other matters -- but it didn't seem to
help.
Logged In: YES
user_id=76148
have you tried any of the 5.2 pre-releases?
Logged In: YES
user_id=107514
I just tried with 5.2.rc1. I DL'd the tarball, configured,
build, and installed. I rebuilt my SNMP-related libraries
and applications with the new net-snmp libraries. And my
programs all seg fault. I'll try for a little while longer
but I can't spend too much more time on this right now.
Logged In: YES
user_id=107514
I tried this with 5.2.1 and found that it still fails.
NOTE: I did _not_ regenerate template code for ifxTable with
5.2.1's mib2c, I just recompiled and linked against the
5.2.1 agent source.
Logged In: YES
user_id=107514
The submitter of this bug has failed to respond to questions from
the maintainers about it, so this bug has been marked as closed
due to lack of a response within a reasonable period of time.
Logged In: YES
user_id=107514
This works for me in v5.2.2 with no changes to user code.
Apparently the table iterator is fixed.
Logged In: YES
user_id=107514
WFM with v5.2.2 and no changes in my code. I guess the
table iterator in the library got fixed along the way.