Re: row_prep() returning MFD_SKIP results in error

#1 (**permalink**) 06-20-2007

--===============0763276256==
Content-Type: multipart/alternative; boundary="0-2034170350-1182369017=:16447"
Content-Transfer-Encoding: 8bit

--0-2034170350-1182369017=:16447
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

1) I verified the following code segment (which was added into the "_mfd_ocStbHostAnalogVideoTable_get_values()" routine) is never being executed (ie: never is true), so row3 still displays:

if (requests->processed)
continue;

I looked around the code a bit and noticed some things which might explain the reason for this occurring. In the "_mfd_ocStbHostAnalogVideoTable_object_lookup( )" routine the following code exists:

if (MFD_SUCCESS != rc)
netsnmp_request_set_error_all(requests, rc);
else {
rc = ocStbHostAnalogVideoTable_row_prep(rowreq_ctx);
if (rc == MFD_SKIP) {
netsnmp_request_info *req;
for (req=requests; req; req=req->next)
req->requestvb->type = SNMP_NOSUCHINSTANCE;
rc = SNMP_ERR_NOERROR;
}
}

You will notice when an error occurs then the "netsnmp_request_set_error_all()" routine is called. This routine will call the "_request_set_error()" routine which will set the "requests->processed" field to "1" as well as setting the "requestvb->type " field appropriately.

However, if no error occurred then the "ocStbHostAnalogVideoTable_row_prep()" routine is called. When a MFD_SKIP value is returned then we simply set the "requestvb->type" only and DO NOT set the "processed" field to "1" at all.

I believe this is the reason why our the check for "processed == 1" does not work.

2) As a result of (1) above, I decided to try the following code in the "_mfd_ocStbHostAnalogVideoTable_get_values()" routine which checks to check for the "requestvb->type" field instead:

if (requests->requestvb->type == SNMP_NOSUCHINSTANCE)
continue;

This code works correctly by skipping row3. When I perform a "snmpgetnext" on row2, then row4 is now displayed.

Is this the solution I should use or shall I set the "processed = 1" value in the "_mfd_ocStbHostAnalogVideoTable_object_lookup( )" routine along with the "requestvb->type" value. If so, then I could use your original code by checking whether the "processed" field is "1".

Here is the trace output for case (2) which worked (I removed my printf statements):

[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_ocStbHostA nalogVideoTable_pre_request: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_pre_request: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_object_lookup: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_row_prep: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode GET
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_get_values: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_post_request: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_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
sparse: retry for NOSUCHINSTANCE
handler:returned: handler table returned 0
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.3
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_ocStbHostA nalogVideoTable_pre_request: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_pre_request: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_object_lookup: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_row_prep: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode GET
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_get_values: called
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_get_column: called for 1
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoProtectionStatus_get: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_post_request: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_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.4 = INTEGER: fourLineSplitBurst(3)

Need Help <snmpnoob@yahoo.com> wrote: 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_ocStbHostA nalogVideoTable_pre_request: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_pre_request: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_object_lookup: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_row_prep: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode GET
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_get_values: called
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_get_column: called for 1
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoProtectionStatus_get: called
handler:returned: handler baby_steps_mux returned 0
handler:calling: calling handler baby_steps_mux for mode (null)
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_post_request: called
verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_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 <snmpnoob@yahoo.com> 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 <rstory@freesnmp.com> 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_ocStbHostA nalogVideoTable_object_lookup: called
NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_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_ocStbHostA nalogVideoTable_get_values: called
NH> internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_get_column: called for 1
NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoProtectionStatus_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_ocStbHostA nalogVideoTable_post_request: called
NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

---------------------------------
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
--0-2034170350-1182369017=:16447
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

1)  I verified the following code segment (which was added into the  "_mfd_ocStbHostAnalogVideoTable_get_values()" routine) is never being executed (ie: never is true), so row3 still displays:    if (requests->processed)       continue; I looked around the code a bit and noticed some things which might explain the reason for this occurring.  In the "_mfd_ocStbHostAnalogVideoTable_object_lookup( )" routine the following code exists:    if (MFD_SUCCESS != rc)        netsnmp_request_set_error_all(requests, rc);    else {      rc = ocStbHostAnalogVideoTable_row_prep(rowreq_ctx);      if (rc == MFD_SKIP) {         netsnmp_request_info *req;         for (req=requests; req;  req=req->next)            req->requestvb->type = SNMP_NOSUCHINSTANCE;         rc = SNMP_ERR_NOERROR;      }    } You will notice when an error occurs then the "netsnmp_request_set_error_all()" routine is called.  This routine will call the "_request_set_error()" routine which will set the "requests->processed" field to "1" as well as setting the "requestvb->type " field appropriately. However, if no error occurred then the "ocStbHostAnalogVideoTable_row_prep()" routine is called.  When a MFD_SKIP value is returned then we simply set the "requestvb->type" only and DO NOT set the "processed" field to "1" at all.   I believe this is the reason why our the check for "processed == 1" does not work. 2)  As a result of (1) above, I decided to try the following code in the "_mfd_ocStbHostAnalogVideoTable_get_values()" routine which checks to check for the "requestvb->type" field instead:    if
(requests->requestvb->type == SNMP_NOSUCHINSTANCE)       continue; This code works correctly by skipping row3.  When I perform a "snmpgetnext" on row2, then row4 is now displayed. Is this the solution I should use or shall I set the "processed = 1" value in the "_mfd_ocStbHostAnalogVideoTable_object_lookup( )" routine along with the "requestvb->type" value.  If so, then I could use your original code by checking whether the "processed" field is "1". Here is the trace output for case (2) which worked (I removed my printf statements): [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 han dler: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:ocStbH ostAnalogVideoTable_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:ocStbH ostAnalogVideoTable_row_prep: called handler:returned: handler baby_steps_mux returned 0 handler:calling: calling handler baby_steps_mux for mode GET internal:ocStbHostAnalogVideoTable:_mfd_ocS tbHostAnalogVideoTable_get_values: 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:ocStbH ostAnalogVideoTable_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 sparse: retry for NOSUCHINSTANCE handler:returned: handler table returned 0 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.3 han dler: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:ocStbH ostAnalogVideoTable_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:ocStbH ostAnalogVideoTable_row_prep: called handler:returned: handler baby_steps_mux returned 0 handler:calling: calling handler baby_steps_mux for mode GET internal:ocStbHostAnalogVideoTable:_mfd_ocS tbHostAnalogVideoTable_get_values: called internal:ocStbHostAnalogVideoTable:_mfd_ ocStbHostAnalogVideoTable_get_column: called for 1 verbose:ocStbHostAnalogVideoTable:ocStbHostAn alogVideoProtectionStatus_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:ocStbH ostAnalogVideoTable_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.4 = INTEGER: fourLineSplitBurst(3) Need Help <snmpnoob@yahoo.com> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> 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 han dler: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:ocStbH ostAnalogVideoTable_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:ocStbH ostAnalogVideoTable_row_prep: called handler:returned: handler baby_steps_mux returned 0 handler:calling: calling handler baby_steps_mux for mode GET internal:ocStbHostAnalogVideoTable:_mfd_ocS tbHostAnalogVideoTable_get_values: called internal:ocStbHostAnalogVideoTable:_mfd_ ocStbHostAnalogVideoTable_get_column: called for 1 verbose:ocStbHostAnalogVideoTable:ocStbHostAn alogVideoProtectionStatus_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:ocStbH ostAnalogVideoTable_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 <snmpnoob@yahoo.com> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> 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 <rstory@freesnmp.com> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> 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_ocStbHostA nalogVideoTable_object_lookup: called NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_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_ocStbHostA nalogVideoTable_get_values: called NH>
internal:ocStbHostAnalogVideoTable:_mfd_ocStbHostA nalogVideoTable_get_column: called for 1 NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoProtectionStatus_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_ocStbHostA nalogVideoTable_post_request: called NH> verbose:ocStbHostAnalogVideoTable:ocStbHostAnalogV ideoTable_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... </blockquote> <div> </div><hr size="1">Park yourself in front of a world of choices in alternative vehicles. <a href="http://us.rd.yahoo.com/evt=48246/*http://autos.yahoo.com/green_center/;_ylc=X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWls dGFncwRzbGsDZ3JlZW4tY2VudGVy">Visit the Yahoo! Auto Green Center.</a>------------------------------------------------------------------------- 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 Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders </blockquote> <div> </div><hr size="1">Sick sense of humor? Visit Yahoo! TV's <a
href="http://us.rd.yahoo.com/evt=47093/*http://tv.yahoo.com/collections/222">Comedy with an Edge </a>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 Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders </blockquote> 
<hr size=1><a href="http://us.rd.yahoo.com/evt=48226/*http://new.toolbar.yahoo.com/toolbar/features/norton/index.php">Get the free Yahoo! toolbar</a> and rest assured with the added security of spyware protection.

--0-2034170350-1182369017=:16447--

--===============0763276256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
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/
--===============0763276256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

--===============0763276256==--

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode