Based on the changes I described I was going to make (see my last email below
this one), it seems row3 does not get skipped. It is still displayed when you
perform the "snmpgetnext" request on row2.
Here is the trace output:
[net-snmp]# /export/home/myname/snmp/usr/local/bin/snmpgetnext -v 1 -c
mycommunity_ro localhost ocStbHostAnalogVideoProtectionStatus.2
handler:calling: main handler bulk_to_next
handler:calling: calling handler bulk_to_next for mode GETNEXT
handler:returned: handler bulk_to_next returned 0
handler:calling: calling handler table for mode GETNEXT
handler:calling: calling handler cache_handler for mode GETNEXT
handler:returned: handler cache_handler returned 0
handler:calling: calling handler table_container for mode GETNEXT
table_container: Mode GETNEXT, Got request:
table_container: data_lookup
oid:OC-STB-HOST-MIB::ocStbHostAnalogVideoProtectionStatus.2
handler:calling: calling handler row_merge for mode GET
handler:calling: calling handler baby_steps for mode GET
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_pre_request:
called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogVideoTable_pre_request: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_object_lookup:
called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogVideoTable_row_prep: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode GET
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_get_values:
called
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_get_column:
called for 1
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogVideoProtectionStatus_get:
called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_post_request:
called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogVideoTable_post_request: called
handler:returned: handler baby_steps_mux returned 0
handler:returned: handler baby_steps returned 0
handler:returned: handler row_merge returned 0
handler:returned: handler table_container returned 0
handler:returned: handler table returned 0
OC-STB-HOST-MIB::ocStbHostAnalogVideoProtectionStatus.3 = INTEGER:
copyProtectionOff(0)
Need Help <[EMAIL PROTECTED]> wrote: I am confused with your "put back in the
prep SKIP" statement.
The row_prep() routine which returns MFD_SKIP was never removed, so I am
assuming you want me to put back in the "object_lookup" code which returns the
MFD_SKIP value.
I am planning on doing the following .... please confirm.
1) Put the following code back into the
"_mfd_ocStbHostAnalogVideoTable_object_lookup()":
if (rc == MFD_SKIP) {
netsnmp_request_info *req;
for (req=requests; req; req=req->next)
req->requestvb->type = SNMP_NOSUCHINSTANCE;
rc = SNMP_ERR_NOERROR;
}
2) Remove the code from "ocStbHostAnalogVideoProtectionStatus_get()" which
checks for ProtectionStatus = 0 (copyProtectionOff) value.
3) Update the "_mfd_ocStbHostAnalogVideoTable_get_values()" routine with your
suggested code.
Robert Story <[EMAIL PROTECTED]> wrote: On Wed, 20 Jun 2007 06:12:08 -0700
(PDT) Need wrote:
NH> Ok, I changed the analog table's interface handler back to how it use to be
(ie: no MFD_SKIP logic) and added the logic you recommended to return MFD_SKIP
to the analog table's "get" handler for the ProtectionStatus field.
NH>
NH> [...] Perhaps you are just having me add this logic to acquire some more
traces only?
Yes, exactly.
NH> Now, here is the trace output you requested:
NH>
NH>
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_object_lookup:
called
NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogVideoTable_row_prep: called
NH> SKIP ROW ocStbHostAnalogVideoTable_row_prep() row=3
NH> handler:returned: handler baby_steps_mux returned 0
NH> handler:calling: calling handler baby_steps_mux for mode GET
NH>
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_get_values:
called
NH>
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_get_column:
called for 1
NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogVideoProtectionStatus_get:
called
NH> SKIP STATUS row=3
NH> handler:returned: handler baby_steps_mux returned 0
NH> handler:calling: calling handler baby_steps_mux for mode (null)
NH>
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostAnalogVideoTable_post_request:
called
NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogVideoTable_post_request:
called
NH> handler:returned: handler baby_steps_mux returned 0
NH> handler:returned: handler baby_steps returned 0
NH> handler:returned: handler row_merge returned 0
NH> handler:returned: handler table_container returned 0
NH> sparse: retry for NOSUCHINSTANCE
Ok, this confirms what I thought... the baby steps handler only checks for
hard errors, and since NOSUCHINSTANCE is a soft error, it keeps on going. So,
options are:
1) set a hard error in addition to a soft one. This will break out of the
handler, but will result in an imbalance - pre_request was called, but
post_request won't be. (though it could be called manually from your interface
code.)
2) update the handler to check for soft errors on object lookup. But I'm
loathe to add extra checks for this special case.
3) let the processing continue, but update your interface code to skip
requests with soft errors.
Let's start with #3. So, put back in the prep SKIP, remove the status SKIP,
and update _mfd_XXX_get_values:
change
for (; requests; requests = requests->next) {
/*
* save old pointer, so we can free it if replaced
*/
to
for (; requests; requests = requests->next) {
if (requests->processed)
continue;
/*
* save old pointer, so we can free it if replaced
*/
and give that a whirl...
---------------------------------
Park yourself in front of a world of choices in alternative vehicles.
Visit the Yahoo! Auto Green
Center.-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
---------------------------------
Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on,
when. -------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
