[NETCONF-806] get-config/edit-config not working for netopeer2 devices Created: 16/Aug/21  Updated: 24/Jun/22

Status: Confirmed
Project: netconf
Component/s: netconf
Affects Version/s: 1.13.1
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: Vishal Varvate Assignee: Vishal Varvate
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File error.log     XML File get-cli-output.xml     XML File get-rpc-reply.xml     Text File get-sdnr-debug-logs.txt    

 Description   

Hi All,

We are using OpenDayLight Silicon SR1 release and we are trying to mount some netopeer2 based devices on it. We are able to mount the devices successfully but while performing get-config RPC call ( the device is using ietf-netconf@2013-09-29)

POST /rests/operations/network-topology:network-topology/topology=topology-netconf/node=test/yang-ext:mount/ietf-netconf:get-config 

with payload

 

{"ietf-netconf:input":{"source":{"candidate":null}}}

 

odl is failing with below exception

 

javax.servlet.ServletException: javax.servlet.ServletException: java.lang.IllegalArgumentException: Could not find schema for
         at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:90)
         at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) ~[bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.server.Server.handle(Server.java:516) ~[bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) ~[bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) ~[bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) [bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:279) [bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.38.v202
         at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:540) [bundleFile:9.4.38.v202
         at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:395) [bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:161) [bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) [bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) [bundleFile:9.4.38.v20210224]
         at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.38.v20210224 (edited) 

          
from netconf trace logs I am able to see that sdnc/odl is receiving rpc-reply from the device which is having complete payload. Once handle-data got completed below exception is coming                                                                                                                                             

2021-08-13T07:32:33,566 | TRACE | qtp1424210203-2104 | FutureCallbackTx                 | 334 - org.opendaylight.netconf.restconf-nb-rfc8040 - 1.13.2 |  -   | Transaction(POST) SUCCESSFUL
 2021-08-13T07:32:33,568 | TRACE | qtp1424210203-2104 | ServerRuntime$Responder          | 187 - org.glassfish.jersey.core.jersey-server - 2.27.0 |  -   | Starting mapping of the exception.
 org.glassfish.jersey.server.internal.process.MappableException: java.util.NoSuchElementException: No value present
         at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:91) ~[?:?]
         at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:163) ~[?:?]
         at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1135) ~[?:?]
         at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:662) ~[?:?]
         at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:395) ~[?:?]
         at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:385) ~[?:?]
         at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:280) ~[?:?]
         at org.glassfish.jersey.internal.Errors$1.call(Errors.java:272) ~[?:?]
         at org.glassfish.jersey.internal.Errors$1.call(Errors.java:268) ~[?:?]
         at org.glassfish.jersey.internal.Errors.process(Errors.java:316) ~[?:?]
         at org.glassfish.jersey.internal.Errors.process(Errors.java:298) ~[?:?]
         at org.glassfish.jersey.internal.Errors.process(Errors.java:268) ~[?:?]
         at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:289) ~[?:?]
         at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:256) ~[?:?]
         at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:703) ~[?:?]
         at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:416) ~[?:?]
         at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:370) ~[?:?]
         at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:389) ~[?:?]
         at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:342) ~[?:?]
         at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:229) ~[?:?]
         at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1443) ~[bundleFile:9.4.38.v

 

 Comments   
Comment by Michael Dürre [ 16/Aug/21 ]

confirmed issue also for aluminium-SR1. Somehow logic due the fact that both are implementing in ietf-netconf@2011-06-01

Comment by Robert Varga [ 16/Aug/21 ]

Please provide a complete stack trace, along with the causality chain.

Comment by Vishal Varvate [ 17/Aug/21 ]

Hi rovarga ,

Please find attached complete stack trace for your reference.

Comment by Vishal Varvate [ 26/Aug/21 ]

Hi rovarga,

 

Can you please provide any update on the above issue

Comment by Robert Varga [ 04/Nov/21 ]

So we have this XML:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-5">
    <data>
        <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">

And there we end up having:

Caused by: java.lang.IllegalArgumentException: Could not find schema for node (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2011-06-01)data in DeclaredOutputEffectiveStatement{path=AbsoluteSchemaPath{path=[(urn:ietf:params:xml:ns:netconf:base:1.0?revision=2013-09-29)get-config, (urn:ietf:params:xml:ns:netconf:base:1.0?revision=2013-09-29)output]}}
	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:441) ~[?:?]
	at org.opendaylight.yangtools.yang.data.impl.codec.SchemaTracker.getSchema(SchemaTracker.java:153) ~[?:?]
	at org.opendaylight.yangtools.yang.data.impl.codec.SchemaTracker.anyxmlNode(SchemaTracker.java:269) ~[?:?]
	at org.opendaylight.yangtools.yang.data.impl.codec.SchemaTracker.startAnyxmlNode(SchemaTracker.java:275) ~[?:?]
	at org.opendaylight.yangtools.yang.data.codec.xml.SchemaAwareXMLStreamNormalizedNodeStreamWriter.startAnyxmlNode(SchemaAwareXMLStreamNormalizedNodeStreamWriter.java:145) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.ParameterAwareNormalizedNodeWriter.wasProcessAsSimpleNode(ParameterAwareNormalizedNodeWriter.java:169) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.ParameterAwareNormalizedNodeWriter.write(ParameterAwareNormalizedNodeWriter.java:121) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.ParameterAwareNormalizedNodeWriter$OrderedParameterAwareNormalizedNodeWriter.write(ParameterAwareNormalizedNodeWriter.java:323) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.NormalizedNodeXmlBodyWriter.writeElements(NormalizedNodeXmlBodyWriter.java:171) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.NormalizedNodeXmlBodyWriter.writeNormalizedNode(NormalizedNodeXmlBodyWriter.java:127) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.NormalizedNodeXmlBodyWriter.writeTo(NormalizedNodeXmlBodyWriter.java:106) ~[?:?]
	at org.opendaylight.restconf.nb.rfc8040.jersey.providers.NormalizedNodeXmlBodyWriter.writeTo(NormalizedNodeXmlBodyWriter.java:48) ~[?:?]

So we have data bound to ietf-netconf@2011-06-01 and schema bound to ietf-netconf@2013-09-29, causing an obvious discrepancy. That revision comes from netopeer2's https://github.com/CESNET/Netopeer2/blob/master/modules/ietf-netconf@2013-09-29.yang – which I cannot find a standard for.

I suspect we are using baseline context to bind the data instead of a negotiated context somewhere in netconf.

Comment by Robert Varga [ 04/Nov/21 ]

The difference between the models boils down to:

--- ietf-netconf@2011-06-01.yang        2018-02-28 10:00:09.000000000 +0100
+++ ietf-netconf@2013-09-29.yang        2021-11-04 23:14:02.447263555 +0100
@@ -10,6 +10,8 @@
     prefix inet;
   }
 
+  import ietf-netconf-acm { prefix nacm; }
+
   organization
     "IETF NETCONF (Network Configuration) Working Group";
 
@@ -46,6 +48,14 @@
 
      This version of this YANG module is part of RFC 6241; see
      the RFC itself for full legal notices.";
+
+  revision 2013-09-29 {
+    description
+      "Updated to include NACM attributes";
+    reference
+      "RFC 6536: sec 3.2.5 and 3.2.8";
+  }
+
   revision 2011-06-01 {
     description
       "Initial revision";
@@ -618,6 +628,7 @@
   }
 
   rpc delete-config {
+    nacm:default-deny-all;
     description
       "Delete a configuration datastore.";
 
@@ -762,6 +773,7 @@
   }
 
   rpc kill-session {
+    nacm:default-deny-all;
     description
       "Force the termination of a NETCONF session.";

i.e. the good folks decided to spin their own rfc6241bis to manifest the language of RFC6536. I wonder if NETCONF WG was informed of this.

Comment by Robert Varga [ 04/Nov/21 ]

So this seems to go through special case handling, binding the result to the base NETCONF spec. I wonder why that is needed.

Comment by Robert Varga [ 04/Nov/21 ]

vvarvate can you capture the entire NETCONF conversation, please? We need to see what the session negotiation exchange when we established the connection looked like.

Comment by Tej Prakash [ 24/Jun/22 ]

Confirming this issue on Phosphorus release aswell.

Same issue is observed for the ietf-netconf:get RPC call aswell.
Device is using ietf-netconf@2013-09-29.yang.

We verified the RPC reply that ODL is receiving and it is syntactically correct and matches the response from netopeer2-cli. Both responses are attached with this issue (get-rpc-reply.xml and get-cli-output.xml).

Relevant stack trace is also attached with this issue get-sdnr-debug-logs.txt

Generated at Wed Feb 07 20:15:57 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.