netopeer server is getting killed when xml containing value out of range as per the yang is pushed

[saraaibak]

Hi @michalvasko,

I have observed that netopeer server is getting killed when I push a xml configuration which contains a parameter value which is out of the range mentioned in the corresponding yang model.

Recreation steps :
As per the yang model,

leaf max-call-home-attempts {                                               
      type uint8 {                                                              
        range "0 .. 20";                                                        
      } 

And I push xml which contains max-call-home-attempts value greater than 20.
Sometimes If I push the value for the first time, it is returning the below error.

> edit-config --target running --config --defop replace
ERROR
	type:     application
	tag:      bad-element
	severity: error
	message:  Unsatisfied range - value "21" is out of the allowed range.
	info:
<bad-element xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">/o-ran-operations:operational-info/max-call-home-attempts</bad-element>

Then after providing a value in the range it returns OK. But again pushing a value out of range kills the netopeer server. Observed same behaviour for other yangs also. Netopeer server side logs are given below.

netopeer2-server[858]: Session 1: thread 0 event new RPC.
netopeer2-server[858]: Published event "rpc" "/ietf-netconf:edit-config" with ID 1 priority 0 for 1 subscribers.
netopeer2-server[858]: Processing "/ietf-netconf:edit-config" "rpc" event with ID 1 priority 0 (remaining 1 subscribers).
netopeer2-server[858]: edit-config error-option "stop-on-error" not supported, rollback-on-error will be performed.

Version I am using is netopeer2 ([2.1.49]) libyang ([v2.1.30] libnetconf2 ([v2.1.28] and sysrepo ([v2.2.36]).

[michalvasko]

I could not reproduce it so either you have something wrong in your setup or you are simply using a version with a bug that has since been fixed. So you can try updating all the projects or at least provide gdb backtrace or valgrind output of the crash.