# Get\_object callback support for SNMP MIB yang

**URL:** <https://dmap-community.ductus.global/t/get-object-callback-support-for-snmp-mib-yang/1950>\
**Category:** Other Northbound Interfaces\
**Created:** [June 21, 2018, 4:49am UTC](https://dmap-community.ductus.global/t/get-object-callback-support-for-snmp-mib-yang/1950 "2018-06-21T04:49:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![key](https://avatars.discourse-cdn.com/v4/letter/k/a183cd/32.png) [@key](https://dmap-community.ductus.global/u/key)\
**Post date:** [June 21, 2018, 4:49am UTC](https://dmap-community.ductus.global/t/get-object-callback-support-for-snmp-mib-yang/1950/1 "2018-06-21T04:49:07Z")

</div>

For SNMP MIB yang(non-configuration), I implemented both get\_elem() and get\_object() callbacks.  
Only get\_elem() is invoked by ConfD.  
Even if get\_elem() callback is not present, get\_object() is not invoked and the following error is seen in the confd log.

21-Jun-2018::04:39:48.880 fujitsu confd[2730]: devel-c get\_elem error {proto\_usage, “No get\_elem() callback installed”} for callpoint ‘GeneralGroup-snmp’ path /PROTOCOL\_MIB:PROTOCOL-MIB/GeneralGroup/GroupId  
 21-Jun-2018::04:39:48.880 fujitsu confd[2730]: devel-snmpa error: variable get: GroupId [http://tail-f.com/ns/mibs/PROTOCOL-MIB/200611100000Z](http://tail-f.com/ns/mibs/PROTOCOL-MIB/200611100000Z) /PROTOCOL-MIB/GeneralGroup/GroupId

Please let us know if there is any restriction in ConfD not to invoke get\_object() callback if callpoint is from SNMP MIB yang.

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [July 12, 2018, 10:45pm UTC](https://dmap-community.ductus.global/t/get-object-callback-support-for-snmp-mib-yang/1950/2 "2018-07-12T22:45:36Z")

</div>

> [@key](#):
>
> Please let us know if there is any restriction in ConfD not to invoke get\_object() callback if callpoint is from SNMP MIB yang.

There is no such restriction, ConfD will always invoke get\_object() if it is registered and get\_elem() is not (if both are registered, I believe the logic for SNMP will indeed always choose get\_elem() since it’s actually preferable due to the way SNMP managers typically traverse tables).

But the error you see is very strange - it indicates that at the point of registration, you had a non-NULL value for `confd_data_cbs.get_elem`, but at invocation, it is actually NULL. Is it possible that your application code modifies the struct after registration? `confd_register_data_cb()` saves a _copy_ of the struct you pass in, but the copy it’s actually accessible for the application via `confd_daemon_ctx.data_cbs` if it disregards the “ConfD internal fields” comment in the declaration…