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_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
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
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_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.4 = INTEGER:
fourLineSplitBurst(3)
Need Help <[EMAIL PROTECTED]> 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_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
---------------------------------
Get the free Yahoo! toolbar and rest assured with the added security of spyware
protection. -------------------------------------------------------------------------
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
