On 7 January 2013 19:58, pal snmp wrote:
> The agent seems to call GET for each column with the same instance ID even
> when the first call failed to return an instance.
Quite likely - each varbind is processed separately.
The old API doesn't attempt to try and merge related rows together.
(Remem
Thanks Dave. That really helped.
Observed another weird agent behavior.
The agent seems to call GET for each column with the same instance ID even
when the first call failed to return an instance.
For example, the SET request was sent for adding 4th row to the table,
which doesn't exist. So the age
On 31 December 2012 19:34, pal snmp wrote:
> I create a final row in the back-end when the ACTION method for
> exampleTableEntryRS is invoked. However, the ACTION method for exampleName
> is not getting invoked until after the ACTION method for entryRS is invoked.
That's quite possible.
The order
Thanks Dave. After using the proper security name, and debugging it
further, I could get my set operation work.
However, I noticed something that I would like to share and get your
opinion on.
I create a final row in the back-end when the ACTION method for
exampleTableEntryRS
is invoked. However, t
On 29 December 2012 01:48, pal snmp wrote:
> I created a simple table (one integer index) and got the agent
> implementation using old API handlers done.
> However, I am having tough time understanding how to add a row into the
> table.
> First of all, my write_* methods are never called for some
All,
I created a simple table (one integer index) and got the agent
implementation using old API handlers done.
However, I am having tough time understanding how to add a row into the
table.
First of all, my write_* methods are never called for some reason though I
set the write_* methods appropri
