ly ERR: Invalid identityref "ct:rsa2048" value - identity found in non-implemented module "ietf-crypto-types".(/o-ran-file-management:file-upload/server/keys/algorithm)
Using latest devel for both libyang and libnetconf2 I face following errors:
`ly ERR: Invalid identityref "ct:rsa2048" value - identity found in non-implemented module "ietf-crypto-types".(/o-ran-file-management:file-upload/server/keys/algorithm)
nc ERR: Failed to create RPC, perhaps a required feature is disabled.`
When this rpc is being constructed:
<file-upload
xmlns="urn:o-ran:file-management:1.0">
<local-logical-file-path>O-RAN/transceiver/sfp_0.sffcap</local-logical-file-path>
<remote-file-path>sftp://#####################@172.21.0.2/sfp_0.sffcap
</remote-file-path>
<password>
<password>p1</password>
</password>
<server>
<keys>
<algorithm
xmlns:ct="urn:ietf:params:xml:ns:yang:ietf-crypto-types">ct:rsa2048
</algorithm>
<public-key>AAAAB
</public-key>
</keys>
</server>
</file-upload>
Why this error happens ? as it seems that the ietf-crypto-types yang module is implemented:
"nc VBS: Reading module "ietf-crypto-types@2019-04-29" from local file "/ram/yangmodel/ietf-crypto-types.yang".". - it even appears 2 times
Also from what comes from server side, conformance type is implement
<namespace>urn:ietf:params:xml:ns:yang:ietf-crypto-types</namespace><conformance-type>implement</conformance-type>
All rpc exchange concerning yang modules loading are contained by attached Logs.txt
Yang files for o-ran-file-management and ietf-crypto-types modules are in attached yang.tar.gz
Thank you!
The fault will most likely be in these errors:
ly ERR: Feature "keystore-supported" not found in module "ietf-keystore".()
nc WRN: Failed to load module "ietf-keystore@2019-04-29".
ly_print_clb(): ly ERR: Feature "local-client-auth-supported" not found in module "ietf-ssh-server".()
lnc2_print_clb(): [172.22.8.2] nc WRN: Failed to load module "ietf-ssh-server@2019-04-29".
And because these modules fail to load, ietf-crypto-types probably fails as well (although I would expect and explicit error for that, too, not sure why there is not). It seems you have not updated your libraries properly, there should be no errors like this. Try to fix this (currently used module revisions are 2023-...) and it should all then work.
Hi @michalvasko, thanks for your reply!
Indeed I don't use the modules provided by libnetconf2 but other ones with different revisions. So I will check with the yang modules using revisions that libnetconf2 provides by default. and see if that solves my issue.
Could you please let me know what is wrong in ietf-keystore.yang and ietf-ssh-server.yang that leads to those ly ERR yang_2.tar.gz
- are those valid errors based on RFC ? if yes I would like to fix those.
They are really old revisions of the modules, you must use those shipped with libnetconf2.
Hi,
I have to reopen the issue as I encounter the same issue with other server..
- ly ERR: Invalid identityref "ct:rsa2048" value - identity found in non-implemented module "ietf-crypto-types".(/o-ran-file-management:file-upload/server/keys/algorithm)
The initial one was indeed solved with those problematic files
Now the only issues from logs are :
Failed to load module "ietf-netconf-nmda@2019-01-07".
Failed to load module "ietf-netconf-partial-lock@2009-10-19".
Failed to load module "ietf-origin@2018-02-14".
Failed to load module "ietf-yang-patch@2017-02-22".
Failed to load module "yang-data-ext@2017-07-03".
Failed to load module "yumaworks-callhome@2020-10-17".
Failed to load module "yumaworks-config-change@2019-06-09".
Failed to load module "yumaworks-event-stream@2021-05-15".
Failed to load module "yumaworks-lock@2023-04-29".
All logs attached in analysis_2.txt
@michalvasko can you please help to find a solution for this ? I have no control over what will the server report.
I do not understand what exactly is happening, all I see in the logs is that again many of them fail to load, not sure why the reason is not printed. I should have asked before, but what libnetconf2 version are you using exactly? It seems like a really old one.
I am using libnetconf2 v3.0.17. I encounter all these issues during the upgrade from 2.0.24.
Why it looks like an old version is used ? I will try to add debug logs to see what happens.
Then perhaps some old files are causing the issues, you can try removing those. Mainly all the modules from (by default) /usr/local/share/yang/modules and then reinstall libnetconf2.
Hi @michalvasko
It indeed seems to be due to version of ietf-crypto-types.yang as it still appears also without those modules that couldn't be loaded.
I must keep ietf-crypto-types.yang at revision 2019-04-29 because o-ran-file-management.yang @2021-07-26 depends on it.
- I tried to update only ietf-crypto-types at 2023-12-28 and remove
revision-date "2019-04-29";in o-ran-file-management.yang:
import ietf-crypto-types {
prefix "ct";
revision-date "2019-04-29";
}
but I got other errrors like ly ERR: The list's key "algorithm" not found.()
-> I must use o-ran-file-management.yang at this revision as the server uses this one and If I update to a newer revision where dependency of crypto-types is removed the RPC message will be constructed differently and the server replies with error
The issue can be reproduced if all RPC exchanges from analysis_2.txt are added.
Could you reproduce it and help me find a solution please ? I really need to make the upgrade to latest versions and is long overdue.
I must keep ietf-crypto-types.yang at revision 2019-04-29 because o-ran-file-management.yang @2021-07-26 depends on it.
Okay, that makes sense and explains the error, another revision is implemented and so the other one cannot be. If you need both revisions implemented, such a YANG context cannot be created, a limitation of YANG. So I am unable to help, you need to make sure all the module in your context require only a single revision of a module implemented.
I don't need multiple revisions, only one, which is older than libnetconf2 provides by default for ietf-crypto-types: 2019-04-29.
Could libnetconf2 support that version too and avoid that issue that I face ?
If not then I only have 1 option, to add a WA to not have that validation in identityref.c for ct:rsa2048 identityref
You need one revision, libnetconf2 needs another = 2 revisions required. And since libnetconf2 requires a newer revision, it is reasonable to update dependencies of O-RAN modules, not libnetconf2.
thanks for your support, for now I thought to disable the verification for ct:rsa2048 in identityref_check_ident as I can't control the O-RAN modules dependency and neither libnetconf2 to support both revisions.