Snmpset with multiple objects - wrong failed object


I am new to this discussion forum and new to confd. I searched this forum but could not find a similar problem to mine so apologies for creating a new topic.
I have a confd-based application with SNMP API and YANG model converted from MIBs. I am setting 2 or more attributes using snmpset. I am using an incorrect value and expecting to see an error saying why it failed and on which object. The problem is that it always says that the failed object was the first one from the list, even if the value provided to the first one is correct and actual problem was with another object from the list. In my code I am using confd_trans_seterr_extended to propagate the error to confd from my application and I am passing a tag that should point to the object on which I am failing the transaction but that does not seem to work.
This is how I call the function:
confd_trans_seterr_extended(ctx, CONFD_ERRCODE_INCONSISTENT_VALUE, 0, tag, “my message %s”, my_error_str);
In result I am getting good reason message:
Reason: inconsistentValue (The set value is illegal or unsupported in some way)
but wrong object in 'Failed object: ’ line.
Any idea what I am missing here? Is that the correct way to tell confd which object failed in the transaction?


Well, no. SNMP has very limited possibilities for reporting error information, basically it’s just the code parameter to confd_trans_seterr_extended(). Any text you provide will be discarded if the request comes from SNMP (but will of course be shown for other NB interfaces), and the apptag_tag parameter is not intended to give the name of the problematic object, but an “error tag” - this will only be used as the value of <error-app-tag> in a NETCONF <rpc-error> reply.

You don’t say in which context you do the confd_trans_seterr_extended() call - typical usage would be in the set_elem() callback of an external data provider, since that is where you discover that the value passed is “inconsistent”. Used this way, I believe (but haven’t personally verified) that an SNMP manager should be able to determine which object the error refers to based on the generated reply.

The call could of course also be done from a validation callback, when you detect that some combination of values is bad - “inconsistent” sort of implies that kind of problem, but as far as I know SNMP uses the inconsistentValue error also when a single object is bad “in itself”. For a validation callback I would expect that the SNMP reply indicates that the node that is annotated with tailf:validate is the problematic object.

Also, in most cases you should not need to call confd_trans_seterr_extended() with CONFD_ERRCODE_INCONSISTENT_VALUE, or even confd_trans_seterr(), at all, but instead rely on ConfD generating the proper error reply based on type restrictions (range, length etc) or must expressions in the YANG model.

Thanks for the response. I am reporting the error from commit callback. I will try to move my validation to set_elem callback and see if that helps. Will update you on this.
So trying to report the error in the set_callback does not help much, but I have moved my validation into the MIB file by adding a range there and that works fine.