Getting "libnetconf ERROR: When condition is accessing its own conditional node children."
Hi,
We are trying to migrate our CLI infrastructure from libnetconf to libnetconf2. We are getting following error, which I think is coming from libyang. "libnetconf ERROR: When condition is accessing its own conditional node children."
the yang is looking like this, import ietf-interfaces { prefix "if"; } augment "/if:interfaces" {
list interface-range {
when "type = 'ianaift:l2vlan' or type = 'ianaift:l3ipvlan'";
description
...
...
leaf type {
type identityref {
base if:interface-type;
}
mandatory true;
description
"The type of interface range.";
}
...
...
This is existing yang for very long time and we use yumapro server. Now libyang is complaining about the 'when' statement. We cannot remove the when statement as to achieve the functionality we need to refer own child only.
We are using libnetconf2 only as client here. Is there any way we can completely avoid libyang validations? We just want libnetconf2 to just pass commands and data from application to server and server to application without any validations like this.
Thanks.
Is there any way we can completely avoid libyang validations?
Without modifying libnetconf2 no, I do not think you can.
Thanks for the response, Do you see any simple changes in libnetconf2 to achieve this?
I haven't realized the issue is not in data but in a YANG module, libyang does not allow loading invalid YANG modules. So I am sorry and I was wrong, I do not see a way of achieving what you want, except for changing libyang code to skip when validation or something similar.
Thanks for the feedback. In this particular case, the when statement in the yang seems to be causing issue in libyang2. But the server never complained about it. I shall check with libyang on why it is reporting error?
From client perspective, the netconf edit-config, get, get-config all seem to work normally even after the above error during nc_connect_ssh. Do you have idea on further implication of nc_ctx_load_module failure of the modules?
Based on the YANG 1.1 specs:
If the "when" statement is a child of any other data definition statement, the accessible tree is tentatively altered during the processing of the XPath expression by replacing all instances of the data node for which the "when" statement is defined with a single dummy node with the same name, but with no value and no children.
Meaning the type leaf will never exist when evaluating the when condition ("no children") so it will always be false.
From client perspective, the netconf edit-config, get, get-config all seem to work normally even after the above error during nc_connect_ssh. Do you have idea on further implication of nc_ctx_load_module failure of the modules?
Could you please shed some light on this?
The client will be unable to work with data of the YANG modules it failed to load. It should also print a warning with this meaning in this case.
Hi, I made changes in yangs to overcome the module load error. All modules are loaded without error now. At this point when I try to change untagged port from one vlan to another vlan, I am getting following error when the server sends a notification after the config change. "Received an invalid message (Invalid instance-identifier "/if:interfaces/if:interface[if:name="vlan3"]/dell-if:untagged-ports" value - semantic error.)." More details in the file as if I add those logs here its not getting displayed properly.
It seems there is no schema path for the instance-identifier meaning some node in the path cannot be found with the specified module prefix/node name. For example, has you client successfully loaded the module in the namespace prefix dell-if?
After doing session = nc_connect_ssh(...) with the help of code unsigned int mod_index = 0; struct lys_module* lys_module = NULL; while ((lys_module = ly_ctx_get_module_iter(nc_session_get_ctx(session), &mod_index)) != NULL) { printf("lys_module %s is %simplemented", lys_module->name, (lys_module->implemented) ? "" : "not "); }
I tried to confirm if everything is implemented. I see module corresponds to dell-if is implemented fine. I hope this is right way to confirm after not seeing any error in nc_connect_ssh.
Also dell-if:untagged-ports was referred in edit-config itself, we didnt observe any issue there. Only on notification which was received later we get the error.
Okay, then I have no more ideas. I would either need to reproduce it (so you would have to provide all the YANG modules and describe the exact steps to take) or, if you can, you could debug it yourself to some extent and provide the required information, with my help. Are you able to do that?
I am not sure if I can share all the yang modules, Let me figure it out. In the meantime, Can you guide me on how to debug this further?. Currently, I have replaced lyd_parse_op to lyd_parse_data in recv_notif to avoid validation. Can this be done as workaround?
Currently, I have replaced lyd_parse_op to lyd_parse_data in recv_notif to avoid validation. Can this be done as workaround?
Well, I suppose, but I would not think it will prevent the error.
Can you guide me on how to debug this further?
What my be enough is to stop with gdb on plugins_types.c:877 (which should be the line generating the error, in libyang devel) and then run ly_last_logmsg(), which should print the specific error, I am not sure why it is not part of the error message (but I would have to reproduce to find out).
@michalvasko , I'm from Deva's team and I'm having a basic query. Please share your inputs. Does libnetconf2 when operating as a Netconf client, expect all the configuration data that server maintains for validations or will simulate the data based on the yang and use it for validations especially for the leafref or instance-identifier like this case ? The Yumapro server that we use has advanced options like transaction hooks(https://www.yumaworks.com/pub/doxygen/latest/html/group__silsalib-hooks.html) that will help inject/modify additional configurations into the datastore other than the ones being edited through the edit-config message.So the client may not have the visibility to some of the configurations that get into the data store. Will libyang/libnetconf2 be able to work under this scenario ? Lastly is there any document that explains the typical libyang operation especially with respect to validations for different Netconf messages like get,get-config,edit-config, notification etc .That would help us evaluate, if we are doing something differently in our case. Thanks a lot for your support of this issue.
Does libnetconf2 when operating as a Netconf client, expect all the configuration data that server maintains for validations or will simulate the data based on the yang and use it for validations especially for the leafref or instance-identifier like this case ?
The client will not validate such references in the data at all, it is the responsibility of the server to send valid data.
Lastly is there any document that explains the typical libyang operation especially with respect to validations for different Netconf messages like get,get-config,edit-config, notification etc .
Well, no other than the standard YANG 1.1 RFC. Like I said, I think I will either have to reproduce it or you debug it yourself and provide some more information.
Hi We are using v2.1.30. After working with gdb, I found the reason for error not getting printed and fixed it our code. Now, I am able to see the errors. libnetconf ERROR: Positional predicate defined for configuration leaf-list "untagged-ports" in path. libnetconf ERROR: Invalid instance-identifier "/if:interfaces/if:interface[if:name="vlan1"]/dell-if:untagged-ports[1]" value - semantic error. libnetconf ERROR: Received an invalid message (Invalid instance-identifier "/if:interfaces/if:interface[if:name="vlan1"]/dell-if:untagged-ports[1]" value - semantic error.).
Hope this will be helpful to proceed further.
That is different from the previous error reported here
Received an invalid message (Invalid instance-identifier "/if:interfaces/if:interface[if:name="vlan3"]/dell-if:untagged-ports" value - semantic error.).
so I am not sure what happened. Yes, the [1] predicate at the end makes the value invalid.
Looks like we are seeing different error in different scenario!. Here is the first error reported.
libnetconf DEBUG: Received message:
I see, then yes, the error is clear and correct, a node must be uniquely identified and it is not without the leaf-list value, per the specs.
Thanks a lot for your assistance. Let me work with the yumapro server team further on this.