libnetconf2
libnetconf2 copied to clipboard
CESNET
JSON printing of <get-data> replies is broken
Hi, I have this kind of program:
#include <iostream>
#include <libyang/libyang.h>
#include <nc_client.h>
#include <string>
int main(int argc, char* argv[])
{
auto sess = nc_connect_unix("/opt/cesnet/Netopeer2/netopeer2-server.sock", nullptr);
auto rpc = nc_rpc_getdata("ietf-datastores:running", nullptr, nullptr, nullptr, 0, 0, 0, 0, NC_WD_ALL, NC_PARAMTYPE_CONST);
uint64_t id;
nc_send_rpc(sess, rpc, 10000, &id);
lyd_node* envp;
lyd_node* reply;
nc_recv_reply(sess, rpc, id, 10000, &envp, &reply);
char* str;
lyd_print_mem(&str, reply, LYD_JSON, LYD_PRINT_WITHSIBLINGS);
std::cerr << "str" << " = " << str << "\n";
free(str);
lyd_free_all(envp);
lyd_free_all(reply);
nc_rpc_free(rpc);
nc_session_free(sess, nullptr);
}
The output of the program looks something like this:
"ietf-netconf-nmda:get-data": {
"data": {
"keystore": [
{
"asymmetric-keys": [
{
"asymmetric-key": [
{
"name": [
{}
],
"algorithm": [
{}
],
"public-key": [
{}
]
}
]
}
]
}
],
"netconf-server": [
{
"listen": [
{
"idle-timeout": [
{}
],
"endpoint": [
{
"name": [
{}
],
"ssh": [
{
"tcp-server-parameters": [
{
"local-address": [
{}
],
"local-port": [
{}
],
"keepalives": [
{
"idle-time": [
{}
],
"max-probes": [
{}
],
"probe-interval": [
{}
]
}
]
}
],
"ssh-server-parameters": [
{
"server-identity": [
{
"host-key": [
{
"name": [
{}
],
"public-key": [
{
"keystore-reference": [
{}
]
}
]
}
]
}
],
"client-authentication": [
{
"supported-authentication-methods": [
{
"publickey": [
{}
],
"passsword": [
{}
],
"other": [
{}
]
}
],
"users": [
{
"user": [
{
"name": [
{}
],
"authorized-key": [
{
"name": [
{}
],
"algorithm": [
{}
],
"key-data": [
{}
]
}
]
}
]
}
]
}
]
}
]
}
]
}
]
}
]
}
]
}
}
}
If I use LYD_XML, the output is normal.
str = <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
<data>
<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
<asymmetric-keys>
<asymmetric-key>
<name>genkey</name>
<algorithm>rsa2048</algorithm>
<public-key>...</public-key>
</asymmetric-key>
</asymmetric-keys>
</keystore>
<netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
<listen>
<idle-timeout>3600</idle-timeout>
<endpoint>
<name>default-ssh</name>
<ssh>
<tcp-server-parameters>
<local-address>0.0.0.0</local-address>
<local-port>9999</local-port>
<keepalives>
<idle-time>1</idle-time>
<max-probes>10</max-probes>
<probe-interval>5</probe-interval>
</keepalives>
</tcp-server-parameters>
<ssh-server-parameters>
<server-identity>
<host-key>
<name>default-key</name>
<public-key>
<keystore-reference>genkey</keystore-reference>
</public-key>
</host-key>
</server-identity>
<client-authentication>
<supported-authentication-methods>
<publickey/>
<passsword/>
<other>interactive</other>
</supported-authentication-methods>
<users>
<user>
<name>vk</name>
<authorized-key>
<name>key1</name>
<algorithm>ssh-rsa</algorithm>
<key-data>...</key-data>
</authorized-key>
</user>
</users>
</client-authentication>
</ssh-server-parameters>
</ssh>
</endpoint>
</listen>
</netconf-server>
</data>
</get-data>
Tried your example with the current devel of all the projects, output
str = {
"ietf-netconf-nmda:get-data": {
"data": {
"ietf-keystore:keystore": {
"asymmetric-keys": {
"asymmetric-key": [
{
"name": "genkey",
"algorithm": "rsa2048",
"public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3rHNa1YmXkWVyt5XgFObJal/3Kws1F9HvButVKHzOR0OafFDumwkF+ANYNFXzlcC2NlKBZ87SWfDlHWRu0UCTjO2cBVlO5bwTCNP0X05KKwuOA61rofvEhmCLokh8OIF05VBO42pYvuLue/x2kQxjc0oXtTsRaTjGVnRs0OJ+3cIJdeYgfZxH7IR3TAoAPx8PPiIfWvUHV1STJ0MMSGJFanHkJgwwcCX6e9vEhK6IF+z/dprPBvOQFrjKcZiBSjRTPy17sHeqmTB5rYj4/lf4JpJs7eLHAgeCNr+P0rEDMZHQTbQKgqoY7OMhzJWIe/HTEhpPpfjYUzp8VlcN+3ZUwIDAQAB"
}
]
}
},
"ietf-netconf-server:netconf-server": {
"listen": {
"idle-timeout": 3600,
"endpoint": [
{
"name": "default-ssh",
"ssh": {
"tcp-server-parameters": {
"local-address": "0.0.0.0",
"local-port": 830,
"keepalives": {
"idle-time": 1,
"max-probes": 10,
"probe-interval": 5
}
},
"ssh-server-parameters": {
"server-identity": {
"host-key": [
{
"name": "default-key",
"public-key": {
"keystore-reference": "genkey"
}
}
]
},
"client-authentication": {
"supported-authentication-methods": {
"publickey": [null],
"passsword": [null],
"other": [
"interactive"
]
}
}
}
}
}
]
}
}
}
}
}
c7d50dcc6295200d899849d5293531335d5758bb Netopeer2 (v2.0.0-116-gc7d50dc) 217bac6c212b157d6d8dd819f3f655270a035bab libnetconf2 (v2.0.1-61-g217bac6) 11e4d1a20052d7a75ea57f728a024bccdb2e2e57 libyang (v2.0.7-390-g11e4d1a2 cf8fb22cd2b1abbad16357f9b3ebd85128da3bca sysrepo (v2.0.1-185-gcf8fb22c)
These are the versions I'm using. Btw the same thing happens when using netopeer2-cli (when using outputformat json). It doesn't happen with $ sysrepocfg -X -f json.
Anyway, I have one more question: I'm not able to use the filter argument with get-data.
> get-data --datastore running --filter-xpath /ietf-netconf-server:netconf-server
ly ERROR: Failed to resolve prefix "ietf-netconf-server".
cli_send_recv: Failed to send the RPC.
Using a similar thing with sysrepocfg works fine $ sysrepocfg -f json -X -x "/ietf-netconf-server:netconf-server".
Okay, it seems that this has something to do with timeouts? I tried using <get> to see if the bug would happen there too. At first the <get> failed, because there's too much data and the netopeer2 callback timed out. So I increase the timeout. Now I run netopeer2 like this:
$ netopeer2-server -d -v2 -U -t 10000
<get> was then able to return data without timing out. However, this actually fixed the <get-data> issue too!
This is the log from the server without the increased timeout: https://gist.github.com/syyyr/461b42fd8d40142a19643bf1f6b2901e
You can see some calback times out, I don't know which one that is. Further <get-data> requests just print this:
[INF]: SR: Published event "rpc" "/ietf-netconf-nmda:get-data" with ID 4 priority 0 for 1 subscribers.
[INF]: SR: Processing "/ietf-netconf-nmda:get-data" "rpc" event with ID 4 priority 0 (remaining 1 subscribers).
[INF]: SR: Successful processing of "rpc" event with ID 4 priority 0 (remaining 0 subscribers).
[INF]: SR: Event "rpc" with ID 4 priority 0 succeeded.
[INF]: NP: Session 1: thread 4 event new RPC.
So, as it seems, the bug only happens if the first request for <get-data> times out. I'm not sure what the default timeout is, for Netopeer2. But it seems weird to me, that it would be so small that it would time out on a local machine (so no internet connection involved). I feel like everything is kinda slow with Netopeer2, I'm not sure if I'm doing something incorrectly? Even connecting is pretty slow, I don't know the reason (yet):
$ time netopeer2-cli <<< "connect --unix --socket /opt/cesnet/Netopeer2/netopeer2-server.sock"
real 0m3.078s
user 0m0.309s
sys 0m0.048s
Three seconds just for connecting is pretty slow. I'm also running Netopeer2 without superuser rights. I recall there being some problems with that, so maybe that's the reason? I'm not sure how far has Netopeer2 come with this. I'll probably try in a VM, to test this.
Well, it all depends on what exactly you have installed in the server. If there are lots of YANG modules, they are all being sent to the client and parsed when connecting so it may take a long time. Perhaps the default timeouts should be adjusted but I am not sure there is more we can do.
I have made some more testing and it seems that the culprit is NACM. If I disable it, everything is faster and there are no timeouts. Anyway, I have found out that the reason my issue is happening: when netopeer2-cli connects, one can see what it does by looking at the output of netopeer2:
[INF]: LN: Accepted a connection on /opt/cesnet/Netopeer2/netopeer2-server.sock.
[WRN]: NP: Session 1 uses a transport protocol not supported by ietf-netconf-monitoring, will not be monitored.
[INF]: SR: Session 1335 (user "vk", CID 98) created.
[INF]: SR: There are no subscribers for "ietf-netconf-notifications" notifications.
[INF]: NP: Generated new event (netconf-session-start).
[INF]: LN: Session 1: Schema "ietf-netconf@2013-09-29" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-inet-types@2013-07-15" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-acm@2018-02-14" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-types@2013-07-15" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-metadata@2016-08-05" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-types@2013-07-15" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-library@2019-01-04" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-types@2013-07-15" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-inet-types@2013-07-15" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-datastores@<any>" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-datastores@<any>" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-nmda@<any>" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-types@2013-07-15" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-inet-types@2013-07-15" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-origin@<any>" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-metadata@2016-08-05" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-with-defaults@2011-06-01" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-yang-metadata@2016-08-05" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: SR: Published event "rpc" "/ietf-netconf-nmda:get-data" with ID 1 priority 0 for 1 subscribers.
[INF]: SR: Processing "/ietf-netconf-nmda:get-data" "rpc" event with ID 1 priority 0 (remaining 1 subscribers).
[ERR]: SR: Callback event "rpc" with ID 1 processing timed out.
[WRN]: SR: Event "rpc" with ID 1 priority 0 failed (Timeout expired).
[ERR]: SR: User callback failed.
[ERR]: NP: Failed to send an RPC (User callback failed).
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: NP: Session 1: thread 3 event reply error.
[INF]: LN: Session 1: Schema "sysrepo-plugind@2020-12-10" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "ietf-netconf-notifications@2012-02-06" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "nc-notifications@2008-07-14" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: LN: Session 1: Schema "notifications@2008-07-14" was requested.
[INF]: NP: Session 1: thread 3 event new RPC.
[INF]: LN: Session 1: Schema "ietf-x509-cert-to-name@2014-12-10" was requested.
[INF]: NP: Session 1: thread 0 event new RPC.
[INF]: LN: Session 1: Schema "iana-crypt-hash@2014-08-06" was requested.
[INF]: NP: Session 1: thread 2 event new RPC.
[INF]: SR: Successful processing of "rpc" event with ID 1 priority 0 (after timeout or earlier error).
[INF]: SR: Processing "/ietf-netconf-nmda:get-data" "abort" event with ID 1 priority 0 (self-generated).
What's happening here is that netopeer2-cli is retrieving schemas for its libyang context:
- first it retrieves the ones that it requires
- then it uses a get-data request to retrieve the YANG library
- then it retrieves all the other schemas
The problem is that Netopeer2 for some reason (probably NACM) takes too long to process the yang library get-data request and so it times out. netopeer2-cli silently ignores that and continues. So the problem is that the schemas couldn't be retrieved and therefore JSON printing is corrupted. We (I and @jktjkt) have found three issues with what is happening here:
- netopeer2-cli/libnetconf2 does not generate an error when the get-data for the yang library fails. This is the biggest one - if the schemas can't be retrieved then libnetconf2 can't work with anything.
- Looking at the log from netopeer2 it seems that cli is requesting the same schemas multiple times. For example:
[INF]: LN: Session 1: Schema "ietf-yang-types@2013-07-15" was requested.
this line appears more than five times. I would think that the client (netopeer2-cli) would not retrieve the same schema multiple times. 3) The last issue is about the NACM being slow. I don't know the exact reason, but it seems like it is stuck on some IO or a mutex. Or actually, the mutex is the main thread waiting for the callback to finish, but it does not finish in time. I have some backtrace of the NACM code, but I'm not sure it is relevant:
Thread 2 (Thread 0x7ffff6f5a640 (LWP 44195) "netopeer2-serve"):
#0 0x00007ffff7b5792e in epoll_wait () from /usr/lib/libc.so.6
#1 0x00007ffff47165a1 in ?? () from /usr/lib/libnss_systemd.so.2
#2 0x00007ffff470b412 in ?? () from /usr/lib/libnss_systemd.so.2
#3 0x00007ffff46ead8c in _nss_systemd_getgrgid_r () from /usr/lib/libnss_systemd.so.2
#4 0x00007ffff7b22587 in getgrgid_r@@GLIBC_2.2.5 () from /usr/lib/libc.so.6
#5 0x000055555556e27d in ncac_collect_groups (ly_ctx=0x55555558ae10, user=0x7fffd80013e0 "vk", groups=0x7ffff6f59790, group_count=0x7ffff6f5978c) at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_acm.c:1069
#6 0x000055555556da69 in ncac_allowed_node (node=0x7fffd801d920, node_path=0x0, node_schema=0x555555694680, user=0x7fffd80013e0 "vk", oper=2 '\002') at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_acm.c:1217
#7 0x000055555556eda6 in ncac_check_data_read_filter_r (first=0x7fffd801d668, user=0x7fffd80013e0 "vk") at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_acm.c:1468
#8 0x000055555556ee2a in ncac_check_data_read_filter_r (first=0x7fffd8010588, user=0x7fffd80013e0 "vk") at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_acm.c:1483
#9 0x000055555556ee2a in ncac_check_data_read_filter_r (first=0x7fffd8001f08, user=0x7fffd80013e0 "vk") at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_acm.c:1483
#10 0x000055555556ee2a in ncac_check_data_read_filter_r (first=0x7ffff6f59988, user=0x7fffd80013e0 "vk") at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_acm.c:1483
#11 0x000055555556ed17 in ncac_check_data_read_filter (data=0x7ffff6f59988, user=0x7fffd80013e0 "vk") at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_acm.c:1515
#12 0x000055555556fbd1 in np2srv_rpc_getdata_cb (session=0x7fffd8000bf0, UNUSED_sub_id=2253, UNUSED_op_path=0x55555568e9f0 "/ietf-netconf-nmda:get-data", input=0x7fffd80025f0, event=SR_EV_RPC, UNUSED_request_id=1, output=0x7fffd8001810, UNUSED_private_data=0x0) at /home/vk/git/lol/submodules/dependencies/Netopeer2/src/netconf_nmda.c:227
#13 0x00007ffff7c7c5f2 in sr_shmsub_rpc_listen_call_callback (rpc_sub=0x5555555b50c0, ev_sess=0x7fffd8000bf0, input_op=0x7fffd80025f0, event=SR_SUB_EV_RPC, request_id=1, output_op=0x7ffff6f59bc0, err_code=0x7ffff6f59bb4) at /home/vk/git/lol/submodules/dependencies/sysrepo/src/shm_sub.c:2897
#14 0x00007ffff7c7be7e in sr_shmsub_rpc_listen_process_rpc_events (rpc_subs=0x5555556b4680, conn=0x55555558ac00) at /home/vk/git/lol/submodules/dependencies/sysrepo/src/shm_sub.c:3182
#15 0x00007ffff7c35cef in sr_subscription_process_events (subscription=0x5555556a7220, session=0x0, stop_time_in=0x7ffff6f59c98) at /home/vk/git/lol/submodules/dependencies/sysrepo/src/sysrepo.c:3136
#16 0x00007ffff7c35ed8 in sr_process_events (subscription=0x5555556a7220, session=0x0, stop_time_in=0x7ffff6f59d28) at /home/vk/git/lol/submodules/dependencies/sysrepo/src/sysrepo.c:3190
#17 0x00007ffff7c7d9e4 in sr_shmsub_listen_thread (arg=0x5555556a7220) at /home/vk/git/lol/submodules/dependencies/sysrepo/src/shm_sub.c:3575
#18 0x00007ffff7e1a259 in start_thread () from /usr/lib/libpthread.so.0
#19 0x00007ffff7b575e3 in clone () from /usr/lib/libc.so.6
Some more info: the call to getgrgid_r takes around 10ms, which is fine I suppose. However, just for connecting from netopeer2-cli, the function is called 5000 (five thousand) times, which results in the coding taking around half a second just figuring out group IDs.
- If you enable more messages in netopeer2-cli, it should warn about this being the case.
- This could perhaps be optimized and I will take a look but should not really matter that much.
- An interesting observation and it is exactly what we need for optimizations, we do not use NACM for general testing. Should not be too difficult to write a cache for these groups, should help with this problem.
Update after looking at this more:
2. The code seems to handle these cases and not retrieve the same schemas repeatedly. Actually, it always first checks that a schema is in the context so I am not sure what the problem is on your end, it is not happening for me. Moreover, only the initial schemas are being requested from the server in my case because all the rest is loaded locally (from /usr/local/share/yang/modules/netopeer2/, where the internal modules are installed by default). You can easily adjust the searchpath of netopeer2-cli yourself to speed up the loading of schemas if you want.
3. This is actually not that simple because I do not think there is a way of knowing when to invalidate the cache in case the system groups are changed. But what you could do is disable enable-external-groups in NACM config instead when the system groups will not be used at all.
Finally, your original printing problem is valid and will be fixed even though it is not actually the real problem you are having.
This is the log I got from the netopeer2-cli. I suppose it does give me some info, but I think the console should just error out, if the error makes it basically unusable:
> verb 2
> connect --unix --socket /opt/cesnet/Netopeer2/netopeer2-server.sock
nc VERBOSE: Capability for <get-schema> support found.
nc VERBOSE: Capability for yang-library support found.
ly VERBOSE: Newer revision than "ietf-yang-types@2013-07-15" not found, using this as the latest revision.
ly VERBOSE: Newer revision than "ietf-inet-types@2013-07-15" not found, using this as the latest revision.
nc VERBOSE: Retrieving data for schema "ietf-netconf", revision "2013-09-29".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-inet-types", revision "2013-07-15".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-netconf-acm", revision "2018-02-14".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-types", revision "2013-07-15".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-metadata", revision "2016-08-05".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-types", revision "2013-07-15".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-library", revision "2019-01-04".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-types", revision "2013-07-15".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-inet-types", revision "2013-07-15".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Unable to identify revision of the schema "ietf-datastores" from the available server side information.
nc VERBOSE: Retrieving data for schema "ietf-datastores", revision "<latest>".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Unable to identify revision of the schema "ietf-datastores" from the available server side information.
nc VERBOSE: Retrieving data for schema "ietf-datastores", revision "<latest>".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Unable to identify revision of the schema "ietf-netconf-nmda" from the available server side information.
nc VERBOSE: Retrieving data for schema "ietf-netconf-nmda", revision "<latest>".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-types", revision "2013-07-15".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-inet-types", revision "2013-07-15".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Unable to identify revision of the schema "ietf-origin" from the available server side information.
nc VERBOSE: Retrieving data for schema "ietf-origin", revision "<latest>".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-metadata", revision "2016-08-05".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-netconf-with-defaults", revision "2011-06-01".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "ietf-yang-metadata", revision "2016-08-05".
nc VERBOSE: Reading schema from server via get-schema.
nc WARNING: Unexpected reply without data to a yang-library <get-data> RPC.
nc VERBOSE: Trying to use capabilities instead of ietf-yang-library data.
ly VERBOSE: Implemented module "ietf-yang-metadata@2016-08-05" was not and will not be imported if the revision-date is missing in the import statement. Instead, the revision "2016-08-05" is imported.
ly VERBOSE: Implemented module "ietf-inet-types@2013-07-15" was not and will not be imported if the revision-date is missing in the import statement. Instead, the revision "2013-07-15" is imported.
ly VERBOSE: Implemented module "ietf-yang-types@2013-07-15" was not and will not be imported if the revision-date is missing in the import statement. Instead, the revision "2013-07-15" is imported.
nc VERBOSE: Retrieving data for schema "sysrepo-plugind", revision "2020-12-10".
nc VERBOSE: Reading schema from server via get-schema.
ly VERBOSE: Implemented module "ietf-netconf-acm@2018-02-14" was not and will not be imported if the revision-date is missing in the import statement. Instead, the revision "2018-02-14" is imported.
ly VERBOSE: Implemented module "ietf-netconf-with-defaults@2011-06-01" was not and will not be imported if the revision-date is missing in the import statement. Instead, the revision "2011-06-01" is imported.
nc VERBOSE: Retrieving data for schema "ietf-netconf-notifications", revision "2012-02-06".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "nc-notifications", revision "2008-07-14".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "notifications", revision "2008-07-14".
nc VERBOSE: Reading schema from server via get-schema.
ly VERBOSE: Implemented module "notifications@2008-07-14" was not and will not be imported if the revision-date is missing in the import statement. Instead, the revision "2008-07-14" is imported.
nc VERBOSE: Retrieving data for schema "ietf-x509-cert-to-name", revision "2014-12-10".
nc VERBOSE: Reading schema from server via get-schema.
nc VERBOSE: Retrieving data for schema "iana-crypt-hash", revision "2014-08-06".
nc VERBOSE: Reading schema from server via get-schema.
>
Your patch did fix the formatting a little bit, but I still don't get any data - now it looks like this.
Anyway, I do have some more info, so I'll create separate issues for the bugs.
What libyang version have you used exactly when you got that output? Please try the latest devel, you should not get the empty {} prints anymore at least I have fixed cases I encountered when it happened.