Skip to Content.

rare-dev - Re: [rare-dev] netconf

Subject: Rare project developers

List archive


Re: [rare-dev] netconf


Chronological Thread 
  • From: David Schmitz <>
  • To:
  • Subject: Re: [rare-dev] netconf
  • Date: Mon, 13 Feb 2023 16:52:05 +0100 (CET)
  • Authentication-results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=lrz.de

Hi,

On Mon, 13 Feb 2023, mc36 wrote:

Date: Mon, 13 Feb 2023 14:19:38 +0100
From: mc36 <>
Reply-To:
To: David Schmitz <>
Cc:
Subject: Re: [rare-dev] netconf

hi,

On 2/13/23 10:37, mc36 wrote:
A bit ugly to parse for humans in case any character is escaped,
but at least it could work.


well, agreeing that it's ugly, and in freerouter i would allow forever-temporary solutions so lemme do a proper escaping then...

fix: ---> in freerouter i would _not_ allow forever-temporary<---

change: https://github.com/rare-freertr/freeRtr/commit/1a837f47fc39b2bcad832c6c24530420a4baf049

so here we goo, with the below small change i arrived to this:

sid#show running-config interface loopback0 | xml
<config><interface><loopback0>
</loopback0></interface>
<interface><loopback0><description><management>
</management></description>
<vrf><forwarding><v1>
</v1></forwarding></vrf>
<ipv4><address><identifier-value>identifier-escape&#49;0&#46;10&#46;10&#46;227
<identifier-value>identifier-escape&#50;55&#46;255&#46;255&#46;255

</identifier-value></identifier-value></address></ipv4>
<ipv6><address><identifier-value>identifier-escape&#50;001&#58;db8&#58;1101&#58;&#58;227&#58;227
<identifier-value>identifier-escapeffff&#58;ffff&#58;ffff&#58;ffff&#58;ffff&#58;ffff&#58;ffff&#58;ffff

</identifier-value></identifier-value></address></ipv6>
<template><template1>
</template1></template>
<no><shutdown>
</shutdown></no>
</loopback0></interface></config>

sid#


maybe you were right and a brute-force would had been easier to have but heyy a least i tried to be user-readable :)
Yes, the more cleaner way!


can you please give a try to the latest jar if yangcli deserializes now everything properly?
This character encodings works as I can see it to be applied in the XML
response.


Unfortunately, FoD, i.e., ncclient library still has a problem with the XML RPC response.

The response currently fo me looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="urn:uuid:407d289f-567d-4130-a76c-82dca0612e09"><data><config><hostname><myr1></myr1></hostname><buggy></buggy><no><locale></locale></no><no><identifier-value>identifier-escapepassword&#45;encrypt</identifier-value></no><no><enable></enable></no><banner><encoded></encoded></banner><client><identifier-value>identifier-escapelabel&#45;range<identifier-value>identifier-escape&#51;2<identifier-value>identifier-escape&#49;048560</identifier-value></identifier-value></identifier-value></client><no><logging><milliseconds></milliseconds></logging></no><logging><buffered><debug><identifier-value>identifier-escape&#53;12</identifier-value></debug></buffered></logging><logging><monitor><debug></debug></monitor></logging><logging><format><normal></normal></format></logging><logging><file><debug><identifier-value>identifier-escape&#46;&#46;&#47;binTmp&#47;mycfg1&#45;log&#46;run</identifier-value></debug></file></logging><no>
<logging><rotate></rotate></logging></no><no><logging><proxy></proxy></logging></no><no><logging><syslog><debu
...

I assume that the source of the problem is due to the fact that all the XML elements in the reponse
(especially the top-most one, the <rpc-reply>)
have no explicit namespace prefix
and in <rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:407d289f-567d-4130-a76c-82dca0612e09"> no un-prefixed namespace is declared.


So, could you make the reponse look like this:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="urn:uuid:407d289f-567d-4130-a76c-82dca0612e09">

or maybe

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:407d289f-567d-4130-a76c-82dca0612e09"> if for some reason the "nc"-prefixed namespace is used for elements nested somewhere within the <rpc-reply>.


Compare this for example to the request sent by ncclient:
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="urn:uuid:407d289f-567d-4130-a76c-82dca0612e09"><nc:get-config><nc:source><nc:running/></nc:source></nc:get-config></nc:rpc>\

Unfortunately, XML parsers and code based on it (like ncclient)
can be very pedantic about namespaces and their prefixes, even for XML elements without a prefix.

Best Regards
David


thx,
cs


--

David Schmitz

Boltzmannstrasse 1, 85748 Garching
Telefon: +49 89 35831-8765
Leibniz-Rechenzentrum, Germany
Mail:





Archive powered by MHonArc 2.6.19.

Top of Page