Sorry,
mistake in my last send.
Not sure where the problem is.
-----Original Message-----
From: Adam Bell
Sent: Friday, August 31, 2007 7:14 AM
To: 'ye_cl'; Adam Bell
Cc: net-snmp-users
Subject: RE: RE: table can't be get and set, var_***Table functin is not
invok ed anyway
If 1.3.6.1.4.1.19176.1.1.20.9.1 is the table OID
1.3.6.1.4.1.19176.1.1.20.9.1.1 is the Entry OID
1.3.6.1.4.1.19176.1.1.20.9.1.1.1 is the first item in the table.
I can't see where 1.1.2.1 is coming from.
Adam
-----Original Message-----
From: ye_cl [mailto:[EMAIL PROTECTED]
Sent: Friday, August 31, 2007 2:31 AM
To: Adam Bell
Cc: net-snmp-users
Subject: Re:RE: table can't be get and set, var_***Table functin is not
invok ed anyway
hi,Adam Bell,
My columnar node39param1's oid is 1.3.6.1.4.1.19176.1.1.20.9.1.1.2.
In command "snmptable -v2c -c public 200.162.162.190 .1.3.6.1.4.1.19176.1.1.
20.9.1.1.2.1", the last ".1" is the index of row. When I use GUI tool
"MG-SOFT MIB Browser"to select Instance for getting, the tool prompt "0
indexes found.".
node39index is the index of the table.
Is there any fault in my MIB module? How can I implememnt it?
-- 1.3.6.1.4.1.19176.1.1.20.9.1
node39Table OBJECT-TYPE
SYNTAX SEQUENCE OF Node39Entry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Description."
::= { tabletst 1 }
-- 1.3.6.1.4.1.19176.1.1.20.9.1.1
node39Entry OBJECT-TYPE
SYNTAX Node39Entry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Description."
INDEX { node39index }
::= { node39Table 1 }
-- 1.3.6.1.4.1.19176.1.1.20.9.1.1.1
node39index OBJECT-TYPE
SYNTAX INTEGER (1..1000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Description."
::= { node39Entry 1 }
-- 1.3.6.1.4.1.19176.1.1.20.9.1.1.2
node39param1 OBJECT-TYPE
SYNTAX INTEGER (0..1000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Description."
::= { node39Entry 2 }
在2007-08-30，"Adam Bell" <[EMAIL PROTECTED]> 写道：
Looks like you may be indexing it wrong.
to access an item
table.entry.index the index can be the column number or whatever
the index is defines as for that table.
So it may be
SNMPv2-SMI::enterprises.19176.1.1.20.9.1.1.2.1.1.x to get it to
work.
Adam
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ye_cl
Sent: Thursday, August 30, 2007 2:16 AM
To: net-snmp-users
Subject: table can't be get and set, var_***Table functin is not
invoked anyway
Hi,
I have a question to ask you.
In my mib2c-produced skeleton source files which are style of
ucd-snmp, I can't get or set the node of Simple table. It always responds
"1: node39param1.1 (nosuchobject) no such object". I find the table's get
function "var_node39Table" is not invoked anyway
When I run "snmptable -v2c -c public 200.162.162.190
.1.3.6.1.4.1.19176.1.1.20.9.1.1.2.1", the agent always responds "Was that a
table? SNMPv2-SMI::enterprises.19176.1.1.20.9.1.1.2.1".
How can I resolve it?
My source code as follows:
static long table_1 = 123;
static long table_2 = 223;
static long table_3 = 323;
struct variable13 scomcenter_variables[] = {
......
#define NODE39INDEX 11
{NODE39INDEX, ASN_INTEGER, RWRITE, var_node39Table, 7, {1, 1,
20, 9, 1, 1, 1}},
#define NODE39PARAM1 12
{NODE39PARAM1, ASN_INTEGER, RWRITE, var_node39Table, 7, {1, 1,
20, 9, 1, 1, 2}},
#define NODE39PARAM2 13
{NODE39PARAM2, ASN_INTEGER, RWRITE, var_node39Table, 7, {1, 1,
20, 9, 1, 1, 3}},
};
unsigned char *
var_node39Table(struct variable *vp,
oid * name,
size_t *length,
int exact, size_t *var_len, WriteMethod **
write_method)
{
static long long_ret;
static u_long ulong_ret;
static unsigned char string[SPRINT_MAX_LEN];
static oid objid[MAX_OID_LEN];
static struct counter64 c64;
printf("var_node39Table\n");
if (header_simple_table
(vp, name, length, exact, var_len, write_method, TABLE_SIZE)
== MATCH_FAILED){
printf("header_simple_table failed\n");
return NULL;
}
printf("header_simple_table ok\n");
switch (vp->magic) {
case NODE39INDEX:
*write_method = write_node39index;
return (u_char *) &table_1;
case NODE39PARAM1:
*write_method = write_node39param1;
return (u_char *)table_2;
case NODE39PARAM2:
*write_method = write_node39param2;
return (u_char *) &table_3;
default:
ERROR_MSG("");
}
return NULL;
}
________________________________
2007 年 最 受 期 待 大 型 网 游 《大 话 西 游 3》震 撼 公 测！ 点 此
抢 先 免 费 体 验 >>
<http://event.mail.163.com/chanel/click.htm?from=NO_17&domain=163>
The information contained in this electronic mail transmission may
be privileged and confidential, and therefore, protected from disclosure. If
you have received this communication in error, please notify us immediately
by replying to this message and deleting it from your computer without
copying or disclosing it.
The information contained in this electronic mail transmission may be
privileged and confidential, and therefore, protected from disclosure. If you
have received this communication in error, please notify us immediately by
replying to this message and deleting it from your computer without copying or
disclosing it.-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
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
