SET-REQUEST, rowStatus, row_activated and agent++v3.4o

[Frank Fock]

Hello Robert,

Thanks a lot for your detailed bug report. You can find
a fixed version of AGENT++ at
http://fock.de/agent++/agent++v3.4p.tar.gz

Please see my comments inline:

"Story, Robert" wrote:

> I'm trying to figure out it the behavior I'm seeing with agent++v3.4o
> is a bug or a limitation, or if I misunderstand the SNMP spec. I was
> under the impression that the order of varbinds in a SET-REQUEST did
> not matter. This isn't what I see with agent++.
>

This SHOULD work with AGENT++. Where the RowStatus is set within
the PDU should not matter, except for destroy operations.

>
> Say I have a table X, with an integer index (column 1), one integer
> value (column 2), and a rowStatus object (column 3). I expect that
> these set requests would produce the same results:
>
> A) set X.1.99.3 = createAndGo, X.1.99.2 = 11
> B) set X.1.99.2 = 11, X.1.99.3 = createAndGo
>

Both should produce the same results. I have tested this with
the v3.4p and another table and it works. Please email me
again if this problem persists with your table.

>
> With agent++, the first set succeeds, the second fails with a
> noSuchName error on the first varbind. However,
>
> C) set X.1.99.3 = createAndWait, X.1.99.2 = 11, X.1.99.3 = createAndGo
>
> does work.

OK, the result for this are unpredictable...

>
> The reason I care is that I want to do some work in the
> row_activated() method. In example (A), the row_activated() method is
> called before the set_value() for column two occurs, so I can't get
> the new value [via  row->get_nth(2)->get_value(i) ]. Since the example
> (B) doesn't work, I have to use example (C), which results in a
> row_deactivated() call immediately followed by a row_activated() call.
> I'd like to avoid the row_deactivated() method, if possible.
>

I will check the RowStatus transitions again within the next days.
(A) seems to be a problem. I will see if I can find a solution.

>
> Also, I think there is a bug in MibTable::commit_set_request()
> [mib.cpp, around line 1963].  I think this code:
>

Yes, there was a bug. Corrected it is:

>
> ---->                     if ((status = set_value(req, ind)) !=
>                               SNMP_ERROR_SUCCESS) {
>                                         // don't answer request, wait
> for undo
>                                         Mib::requestList->
>
> error(req->get_transaction_id(),
>                                                 ind,
>                                                 SNMP_ERROR_COMITFAIL);
>
>                                         return SNMP_ERROR_COMITFAIL;
>                                 }

Best regards,
Frank

--
Frank Fock - AGENT++
Email: frank____fock.de
Fax: +49 7195 177108