I managed to implement a notification sending to the NetConf client. However, when I send the notification I sometimes see the following error in confd_devel.log: 4-May-2017::15:39:10.133 oschwar_Host2 confd[14175]: devel-c Internal error on API request

Need more input on the issue, e.g. a libconfd trace with timestamp. If you can have the libconfd trace set to CONFD_PROTO_TRACE debug level, you can match the notification and other API calls timestamps with the entry you see in the developer log on the ConfD side.

For example, here I am sending a NETCONF config change notification over the NETCONF stream,

I checked once again with the traces. When the “connect” is done from the netconf client, I see in the confd_netconf.trace print outs of the message (which is OK).When the application sends notification to the confd and the client, I see TRACE that a notification is sends. However, the clients receives nothing and on the netconf.trace log I see only

<transport>
<ssh>
<enabled>true</enabled>
<ip>0.0.0.0</ip>
<!-- Note that the standard port for NETCONF over SSH is 830 -->
<port>2022</port>
</ssh>
<!--
NETCONF over TCP is not standardized, but it can be useful
during development in order to use e.g. netcat for scripting.
-->
<tcp>
<enabled>true</enabled>
<ip>127.0.0.1</ip>
<port>2023</port>
</tcp>
</transport>
<capabilities>
<!-- enable only if /confdConfig/datastores/startup is enabled -->
<startup>
<enabled>false</enabled>
</startup>
<!-- enable only if /confdConfig/datastores/candidate is enabled -->
<candidate>
<enabled>false</enabled>
</candidate>
<confirmed-commit>
<enabled>false</enabled>
</confirmed-commit>
<!--
enable only if /confdConfig/datastores/running is read-write
-->
<writable-running>
<enabled>true</enabled>
</writable-running>
<rollback-on-error>
<enabled>true</enabled>
</rollback-on-error>
<!-- Turn on the URL capability options you want to support -->
<url>
<enabled>true</enabled>
<file>
<enabled>true</enabled>
<rootDir>/root/kvmpackage/Confd/var/confd/state</rootDir>
</file>
<ftp>
<enabled>true</enabled>
</ftp>
</url>
<xpath>
<enabled>true</enabled>
</xpath>
<!--
Enable this to turn on NETCONF Notifications support.
-->
<notification>
<enabled>true</enabled>
<!--
Enable this to make the agent handle RPCs while sending
notifications.
-->
<interleave>
<enabled>false</enabled>
</interleave>
</notification>
</capabilities>
<!--
If extendedSessions are enabled, all ConfD sessions can be
terminated using <kill-session>, i.e. not only can other
NETCONF session be terminated, but also CLI sessions, WebUI
sessions etc. If such a session holds a lock, its session
id will be returned in the <lock-denied>, instead of "0".
Strictly speaking, this extension is not covered by the
NETCONF specification; therefore it's false by default.
-->
<extendedSessions>false</extendedSessions>

Hi, Unless you can show this community exactly how to reproduce that error (I sent that same notification without any issues), we can't help other than recommend that you double check your code, the ConfD documentation and examples.

we are reviewing the entire code and the configuration, compare it to the examples and guidelines to see what is missing/wrong.I have few questions regarding diff that we found, that might give us a good hint...

I saw example that the reply wasn't NULL. as much as I understood from the guideline it is not a callback we need. Can you tell if that can cause such error?

I see the following prints :6-Jun-2017::12:08:58.701 22860/b30ffb40/23 SEND op=15 isrel=0 th=-1 {170,'NETCONF',undefined,{19,{2017,6,6,12,8,58,701083,0,0}},2,{hxml,[{[1244620176|2103098691],start},{[1244620176|737643097],start},{870658415,#Bin},{372565948,{12,0}},{1399987302,{160,160,160,160}},{[1244620176|737643097],stop},{449538578,{28,0}},{[1244620176|1716487530],start},{1914145912,{34,[1033149831,13885182,[1693656965|555337807]]}},{[1244620176|1716487530],stop},{[1244620176|2103098691],stop}]}}

Does it mean that the message was received OK in the confd code? the path is not printed as text but as numbers. Is it OK?

No, the debug output from libconfd just means that libconfd successfully sent the message. If the message was corrupt when ConfD received it, you may get the "API request" error that you see. Perhaps you should check that using for example wireshark or tcpdump comparing the packets sent by libconfd to the ones received by ConfD.Looking at your past posts, you seem to have had issues with your socket communication, perhaps that's something you should look into?

I guess that's what you suspect too, and therefore you cannot provide an example to enable us to reproduce the issue?

the path is not printed as text but as numbers. Is it OK?

It is printed in binary format, which is what libconfd converts it to, so that's ok.

Is there a way to see print outs from the confD itself? I am not sure what to suspect... the socket is used for the init registration in addition for the receive callbacks so I guess it is OK, but it worth to double check.Please see below the init an registration code, and the send notification code, to complete the picture. maybe you can see something that we miss here.

The implementation is that we send the notification from different thread than the thread that receive and answer the confd callbacks. However, I tried to send the notification from the callback thread, to be sure it is the only message that being sent at the same time. Still got the internal error message...

how do you see in the tcp dump I added that 2 message are sent at the same time?

Is there a way to see what is being received in the CONFD process? Any other idea of how to proceed?