Issue in receiving the notification in netconf browser

Hi,
i wrote one yang module which have notification container as alarms, in that 3 alarms are mentioned. I have written an erlang application where it registered to the
notification stream. When i generate the alarm from application, notification is sent succesfully but it is not displayed in the netconf browser. what can be the mistake iam doing here? Any one can help me to solve this?

Below is my yang file:

notification alarms {
leaf wss_communication_error {
  type leafref{
  	path "/performance/wss_communication_error";
  }
   mandatory true;
}
leaf high_input_channel_power_alarm {
  type leafref{
  	path "/performance/high_input_channel_power_alarm";
  }
}
leaf low_input_channel_power_alarm {
  type leafref{
  	path "/performance/low_input_channel_power_alarm";
  }
 }
}

and Source code is below:

start() ->

 application:start(econfd),
 timer:sleep(1000),
 proc_lib:spawn(fun go/0).

go() ->
 process_flag(trap_exit, true),
 NCbs = #confd_notification_stream_cbs{
  	 	streamname = alarms
 },
 application:start(econfd),

  {ok,Daemon} = econfd:init_daemon(common_daemon, ?CONFD_TRACE, user, none,
                                 {127,0,0,1}, ?CONFD_PORT),

   {ok, Register_notify_stream} = econfd:register_notification_stream(Daemon, NCbs),

   ok = econfd:register_done(Daemon),
  
  application:set_env(common_daemon, register_notify_stream ,Register_notify_stream),

   ok.

  generate_wss_communication_error( Present_or_absent ) ->

  Notify_path = [{[?NAMESPACE|alarms],start},
 	    	        	{[?NAMESPACE|wss_communication_error], Present_or_absent },
		             {[?NAMESPACE|alarms],stop}],
   send_notification( Notify_path ).	
 send_notification( Notify_path ) ->
    {ok, Register_notify_stream} = 
       application:get_env(common_daemon,register_notify_stream),
      case econfd:notification_send(Register_notify_stream, atime(), Notify_path) of
          ok ->  io:format("Sent notification ~n"),
               ok;
         Error -> io:format("Failed to send notification: ~p~n", [Error])
      end.

Does the netconf.trace log show that the notification was sent by ConfD?
(The netconf.trace log is enabled in the confd.conf file)

Hi cohult,

netconf.log is enabled in confd.conf file. Below is log i am getting.

<INFO> 9-Mar-2020::10:21:24.330 shiva confd[7656]: netconf id=28 got rpc: {urn:ietf:params:xml:ns:netconf:notification:1.0}create-subscription attrs: message-id="19"
<INFO> 9-Mar-2020::10:21:24.330 shiva confd[7656]: netconf id=28 create-subscription stream=alarms attrs: message-id="19"
<INFO> 9-Mar-2020::10:21:24.332 shiva confd[7656]: netconf id=28 sending rpc-reply, attrs: message-id="19"
<INFO> 9-Mar-2020::10:22:24.333 shiva confd[7656]: netconf id=28 resource-denied 
<INFO> 9-Mar-2020::10:22:24.333 shiva confd[7656]: netconf id=28 sending rpc-reply, attrs: message-id="20"

Hi,
I was asking for the netconf.trace log, which is enabled in confd.conf for example like this:

$ cat confd.conf | grep -B 2 -A 2 netconf.trace
    <netconfTraceLog>
      <enabled>true</enabled>
      <filename>./netconf.trace</filename>
      <format>pretty</format>
    </netconfTraceLog>

The log looks something like this:

You can also get the stream stats:

$ netconf-console --get -x /netconf-state
or
$ confd_load -dd -Fp -p /netconf-state

Hi,

Notifications are not traced in netconf.trace log.
Below is trace log.

#207
<rpc message-id="7" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <stream>alarms</stream>
  </create-subscription>
</rpc>

9-Mar-2020::11:12:15.266 **< sess: write:
<rpc-reply message-id="7" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>


##

#115
<rpc message-id="8" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
   <filter/>
 </get>
</rpc>

9-Mar-2020::11:13:15.273 **< sess: write:
 <rpc-reply message-id="8" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <rpc-error>
    <error-type>protocol</error-type>
     <error-tag>resource-denied</error-tag>
    <error-severity>error</error-severity>
   <error-message xml:lang="en">:interleave not supported</error-message>
 </rpc-error>

Hi @cohult

I checked the source code, yang file and confd.conf file but i couldnot find the issue.
Could you please help me to slove this.

ConfD implements the urn:ietf:params:netconf:capability:interleave:1.0 capability, which allows the client to get send RPCs while a notification subscription is active.

Your trace log show that you get an error as you send a <get> request on a NETCONF session where you haven’t enabled the interleave capability in confd.conf:

<netconf>
...
  <notification>
    <enabled>true</enabled>
    <interleave>
      <enabled>true</enabled>
    </interleave>
  </notification>
</netconf>

See the confd.conf(5) man page under /confdConfig/netconf/capabilities/notification/interleave/enabled

@cohult I have added that in confd.conf file but still it is not working.

Below is netconf trace log

#117
<rpc message-id="322" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter/>
  </get>
</rpc>

10-Mar-2020::15:12:36.361 **< sess: write:
<rpc-reply message-id="322" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data/>
</rpc-reply>

There is no subscription notification or error in the log you provided, just a <get> with an empty reply. I thought we were discussing NETCONF notifications?

Yeah…Iam getting below trace when iam sending NETCONF notifications using API econfd:notification_send/3. Even iam confused why am i getting <get> log while sending netconf notification.

#209
<rpc message-id="320" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <stream>alarms</stream>
 </create-subscription>
</rpc>

10-Mar-2020::15:10:36.334 **< sess: write:
<rpc-reply message-id="320" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>


##

#117
<rpc message-id="321" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <get>
    <filter/>
  </get>
</rpc>

10-Mar-2020::15:11:36.339 **< sess: write:
<rpc-reply message-id="321" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data/>
 </rpc-reply>

Hi @cohult,

Is there any way to find what went wrong in the code?

And what is the issue? That you don’t see a notification sent in the log?
What does your stream stats say?

Also note that the get operation you are sending to the ConfD NETCONF server in your log is an “empty filter” which will get an “empty reply”. https://tools.ietf.org/html/rfc6241#section-6.4.2

Hi @cohult,
stream stats log is below using command netconf-console --get -x /netconf-state

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <data>
     <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
     <capabilities>
      <capability>urn:ietf:params:netconf:base:1.0</capability>
     <capability>urn:ietf:params:netconf:base:1.1</capability>
     <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.1</capability>
     <capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
     <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:interleave:1.0</capability>
     <capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic- 
 mode=explicit&amp;also-supported=report-all-tagged</capability>
     <capability>urn:ietf:params:netconf:capability:yang-library:1.0?revision=2016-06- 
 21&amp;module-set-id=4ebf331d8c027d95a2433c3347ed996f</capability>
     <capability>http://tail-f.com/ns/netconf/actions/1.0</capability>
     <capability>http://tail-f.com/ns/netconf/extensions</capability>
     <capability>http://tail-f.com/ns/aaa/1.1?module=tailf-aaa&amp;revision=2015-06- 
16</capability>
     <capability>http://tail-f.com/ns/common/query?module=tailf-common- 
query&amp;revision=2017-12-15</capability>
     <capability>http://tail-f.com/ns/example/notif/set_get_notify_common_yang? 
 module=set_get_notify_common_yang</capability>
     <capability>http://tail-f.com/ns/kicker?module=tailf-kicker&amp;revision=2017-09- 
28</capability>
     <capability>http://tail-f.com/yang/acm?module=tailf-acm&amp;revision=2013-03- 
07</capability>
      <capability>http://tail-f.com/yang/common?module=tailf-common&amp;revision=2018- 
03-01</capability>
      <capability>http://tail-f.com/yang/common-monitoring?module=tailf-common- 
monitoring&amp;revision=2013-06-14</capability>
     <capability>http://tail-f.com/yang/confd-monitoring?module=tailf-confd- 
monitoring&amp;revision=2013-06-14</capability>
     <capability>http://tail-f.com/yang/netconf-monitoring?module=tailf-netconf- 
monitoring&amp;revision=2016-11-24</capability>
     <capability>http://tail-f.com/yang/xsd-types?module=tailf-xsd-types&amp;revision=2017- 
11-20</capability>
     <capability>urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt- 
hash&amp;revision=2014-08-06&amp;features=crypt-hash-sha-512,crypt-hash-sha- 
256,crypt-hash-md5</capability>
     <capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet- 
 types&amp;revision=2013-07-15</capability>
      <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf- 
 acm&amp;revision=2012-02-22</capability>
     <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf- 
monitoring&amp;revision=2010-10-04</capability>
    <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf- 
 notifications&amp;revision=2012-02-06</capability>
    <capability>urn:ietf:params:xml:ns:yang:ietf-yang-library?module=ietf-yang- 
   library&amp;revision=2016-06-21</capability>
    <capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang- 
   types&amp;revision=2013-07-15</capability>
    <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=ietf- 
 netconf&amp;revision=2011-06-01</capability>
    <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf- 
 with-defaults&amp;revision=2011-06-01</capability>
  </capabilities>
  <datastores>
    <datastore>
      <name>running</name>
      <transaction-id xmlns="http://tail-f.com/yang/netconf-monitoring">1583-987727- 
184138</transaction-id>
    </datastore>
    <datastore>
      <name>candidate</name>
    </datastore>
  </datastores>
  <schemas>
    <schema>
      <identifier>iana-crypt-hash</identifier>
      <version>2014-08-06</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:iana-crypt-hash</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-inet-types</identifier>
      <version>2013-07-15</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:ietf-inet-types</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-netconf</identifier>
      <version>2011-06-01</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:netconf:base:1.0</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-netconf-acm</identifier>
      <version>2012-02-22</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:ietf-netconf-acm</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-netconf-monitoring</identifier>
      <version>2010-10-04</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-netconf-notifications</identifier>
      <version>2012-02-06</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:ietf-netconf-notifications</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-netconf-with-defaults</identifier>
      <version>2011-06-01</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-yang-library</identifier>
      <version>2016-06-21</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:ietf-yang-library</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>ietf-yang-types</identifier>
      <version>2013-07-15</version>
      <format>yang</format>
      <namespace>urn:ietf:params:xml:ns:yang:ietf-yang-types</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>set_get_notify_common_yang</identifier>
      <version/>
      <format>yang</format>
      <namespace>http://tail-f.com/ns/example/notif/set_get_notify_common_yang</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-aaa</identifier>
      <version>2015-06-16</version>
      <format>yang</format>
      <namespace>http://tail-f.com/ns/aaa/1.1</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-acm</identifier>
      <version>2013-03-07</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/acm</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-cli-extensions</identifier>
      <version>2017-08-23</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/common</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-common</identifier>
      <version>2018-03-01</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/common</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-common-monitoring</identifier>
      <version>2013-06-14</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/common-monitoring</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-common-query</identifier>
      <version>2017-12-15</version>
      <format>yang</format>
      <namespace>http://tail-f.com/ns/common/query</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-confd-monitoring</identifier>
      <version>2013-06-14</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/confd-monitoring</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-kicker</identifier>
      <version>2017-09-28</version>
      <format>yang</format>
      <namespace>http://tail-f.com/ns/kicker</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-meta-extensions</identifier>
      <version>2017-03-08</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/common</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-netconf-monitoring</identifier>
      <version>2016-11-24</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/netconf-monitoring</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-rollback</identifier>
      <version>2018-01-12</version>
      <format>yang</format>
      <namespace>http://tail-f.com/ns/rollback</namespace>
      <location>NETCONF</location>
    </schema>
    <schema>
      <identifier>tailf-xsd-types</identifier>
      <version>2017-11-20</version>
      <format>yang</format>
      <namespace>http://tail-f.com/yang/xsd-types</namespace>
      <location>NETCONF</location>
    </schema>
  </schemas>
  <sessions>
    <session>
      <session-id>28</session-id>
      <transport>netconf-ssh</transport>
      <username>admin</username>
      <source-host>127.0.0.1</source-host>
      <login-time>2020-03-12T10:07:20+05:30</login-time>
      <in-rpcs>4</in-rpcs>
      <in-bad-rpcs>0</in-bad-rpcs>
      <out-rpc-errors>0</out-rpc-errors>
      <out-notifications>0</out-notifications>
    </session>
    <session>
      <session-id>29</session-id>
      <transport>netconf-ssh</transport>
      <username>admin</username>
      <source-host>127.0.0.1</source-host>
      <login-time>2020-03-12T10:10:04+05:30</login-time>
      <in-rpcs>1</in-rpcs>
      <in-bad-rpcs>0</in-bad-rpcs>
      <out-rpc-errors>0</out-rpc-errors>
      <out-notifications>0</out-notifications>
    </session>
  </sessions>
  <statistics>
    <netconf-start-time>2020-03-12T10:05:27+05:30</netconf-start-time>
    <in-bad-hellos>0</in-bad-hellos>
    <in-sessions>2</in-sessions>
    <dropped-sessions>0</dropped-sessions>
    <in-rpcs>5</in-rpcs>
    <in-bad-rpcs>0</in-bad-rpcs>
    <out-rpc-errors>0</out-rpc-errors>
    <out-notifications>0</out-notifications>
  </statistics>
  <streams xmlns="http://tail-f.com/yang/netconf-monitoring">
    <stream>
      <name>NETCONF</name>
      <description>default NETCONF event stream</description>
      <replay-support>false</replay-support>
    </stream>
    <stream>
      <name>alarms</name>
      <description>notifications</description>
      <replay-support>true</replay-support>
      <subscriber>
        <session-id>1</session-id>
        <start-time>2020-03-12T10:07:52.252325+05:30</start-time>
      </subscriber>
    </stream>
  </streams>
</netconf-state>

The stats show nothing was sent, but you say you did call the API successfully.
If a econfd:notification_send() made it to the ConfD daemon from your application it will be logged in the developer log when using these settings:

What does the devel.log say with those settings?

Sloved. Thank you @cohult.