A question about netconf connection error mentioned in #1411

[satomhxl]

Hello, I also encountered the problem described in this issue. And I have solved it depending on the conversations in the link.

But I'm curious about why this problem happens when we try to login from netconf client, rather than installing yang models on netconf server. Does the netconf client compare the version of yang model from netconf server with the local yang models?

Any information would be appreciated, thank you.

[jktjkt]

The NETCONF client needs access to the YANG models which are installed on the server, otherwise it won't understand the structure (and meaning) of the data. For that, the client retrieves the YANG models from the server (or it uses a local cache), and when there's an error in these YANG models, the client won't connect successfully. Fix the YANG models and install the fixed version on the NETCONF server.

[satomhxl]

So when there are multiple versions of YANG models installed in NETCONF server, it is necessary for us to specify a specific version when importing them, otherwise errors will inevitably occur, right?

Actually, this problem does not occur everytime, which makes me confused.

[michalvasko]

So when there are multiple versions of YANG models installed in NETCONF server, it is necessary for us to specify a specific version when importing them, otherwise errors will inevitably occur, right?

No, in that case the latest revision is always imported. That may be a problem for modules that expect the older revision to be imported and those are the ones that must import by revision.

[satomhxl]

Thank you for your quick reply.

By the way, where is the local cache used by NETCONF client? In this link you said delete ~/.netopeer2-cli/modules/, but I only have two files "config.xml" and "history" under ~/.netopeer2-cli. I'm using netopeer2-2.1.36

[michalvasko]

The default search directory used is a cmake variable called YANG_MODULE_DIR and it is /usr/local/share/yang/modules/netopeer2 by default. So if all the modules are found there or in the explicit search directory, no modules need to be additionally cached.

[satomhxl]

Well, based on your response, when we have two versions of ietf-crypto-types.yang exist in NETCONF server, ietf-keystore.yang should pick the newer one, so everything should be OK. But this problem happens, which means there are other possible reasons😂.

I'm just curious, any guess from you is enough.

[michalvasko]

There is another scenario possible when the first time the import is being resolved a module is imported by revision. Then, other imports without revision will use the previously imported module. The idea is for all the modules to import a single module revision, if possible.

[satomhxl]

OK, that makes sense.

Thank you for your patience.