netopeer2-cli doesn't work with Server implementations where yang-library & ietf-netconf modules are not supported

[anukulverma]

nc VERBOSE: Capability for <get-schema> support found.
nc VERBOSE: Capability for yang-library support not found.
nc ERROR: Base NETCONF schema not supported by the server.
nc WARNING: Missing ietf-netconf schema in context,
cmd_listen: Receiving SSH Call Home on port 4334 as user "root" failed.

Is there anyway available to disable these modules

[michalvasko]

Support for ietf-yang-library is not required but for ietf-netconf is. I have never really considered the situation but I suppose it could work somehow. Although you will not even be able to properly terminate the session, <close-session> RPC would not be available. So I do not really see the point of trying to support this, not sure if such a server can even be considered compliant with NETCONF.

[anukulverma]

We are basically using OpenYuma based netconf server. That has its own modules supported Note that the same server works fine with other Netconf client implementations like mg-soft, ODL, Netconf-C and others

========= Close session ===============

<?xml version="1.0" encoding="UTF-8"?>
<rpc message-id="1"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <close-session xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"/>
</rpc>

============================ Modules supported ========================

<capability>urn:ietf:params:xml:ns:yang:iana-crypt-hash?module=iana-crypt-hash&amp;revision=2014-04-04</capability>
 <capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?module=ietf-inet-types&amp;revision=2013-07-15</capability>
 <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-acm?module=ietf-netconf-acm&amp;revision=2012-02-22</capability>
 <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&amp;revision=2010-10-04</capability>
 <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-notifications?module=ietf-netconf-notifications&amp;revision=2012-02-06</capability>
 <capability>urn:ietf:params:xml:ns:netconf:partial-lock:1.0?module=ietf-netconf-partial-lock&amp;revision=2009-10-19</capability>
 <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults?module=ietf-netconf-with-defaults&amp;revision=2011-06-01</capability>
 <capability>urn:ietf:params:xml:ns:yang:ietf-system?module=ietf-system&amp;revision=2014-08-06</capability>
 <capability>urn:ietf:params:xml:ns:yang:ietf-yang-types?module=ietf-yang-types&amp;revision=2013-07-15</capability>
<capability>urn:ietf:params:xml:ns:netmod:notification?module=nc-notifications&amp;revision=2008-07-14</capability>
 <capability>urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&amp;revision=2008-07-14</capability>
 <capability>http://netconfcentral.org/ns/yuma-app-common?module=yuma-app-common&amp;revision=2012-08-16</capability>
 <capability>http://netconfcentral.org/ns/yuma-mysession?module=yuma-mysession&amp;revision=2010-05-10</capability>
 <capability>http://netconfcentral.org/ns/yuma-ncx?module=yuma-ncx&amp;revision=2012-01-13</capability>
 <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=yuma-netconf&amp;revision=2012-10-05&amp;features=writable-running,candidate,confirmed-commit,rollback-on-error,validate,startup,url,xpath</capability>
 <capability>http://netconfcentral.org/ns/yuma-proc?module=yuma-proc&amp;revision=2012-10-10</capability>
 <capability>http://netconfcentral.org/ns/yuma-system?module=yuma-system&amp;revision=2014-11-27</capability>
 <capability>http://netconfcentral.org/ns/yuma-time-filter?module=yuma-time-filter&amp;revision=2011-08-13</capability>
 <capability>http://netconfcentral.org/ns/yuma-types?module=yuma-types&amp;revision=2012-06-01</capability>

[michalvasko]

This capability

 <capability>urn:ietf:params:xml:ns:netconf:base:1.0?module=yuma-netconf&amp;revision=2012-10-05&amp;features=writable-running,candidate,confirmed-commit,rollback-on-error,validate,startup,url,xpath</capability>

shows how hacked it all is, the namespace is the same as a standard module (ietf-netconf) which is definitely not allowed. Now I am even less willing to support this because this use-case is simply invalid and the other clients are just fooled into supporting this or perhaps intentionally do.