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: mc36 <>
  • Cc:
  • Subject: Re: [rare-dev] netconf
  • Date: Tue, 14 Feb 2023 14:20:27 +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 Tue, 14 Feb 2023, mc36 wrote:

Date: Tue, 14 Feb 2023 10:13:26 +0100
From: mc36 <>
To: David Schmitz <>
Cc:
Subject: Re: [rare-dev] netconf

hi,

On 2/14/23 09:56, David Schmitz wrote:

unfortunately, normally the debug is quiet after the last line above, so the actual reply sent by freertr is normally not appearing in freertr's debug.
Somehow I managed to get it to be more talkative during the testing for my last e-mail.


so if you do "exec autocommand netconf format" in your "server telnet xxx" then it'll give you everything in the debug :)
That basically works.
When using yangcli as client, I can see all the nicely formatted XML
lines of the rpc-reply in the freertr debug.
Nevertheless yangcli has a problem to parse the output,
which is still not clear to me why.

But it seems the "format" option somehow breaks the communication with
ncclient library.
Somehow ncclient is not getting an answer back from freertr
and also freertr is showing in debug that it does not even receives an
rpc-request.




So, think you are right regarding the dynamic behavior.
Also, because nowhere in the current freertr code I can no longer find
the "xmlns:nc=" any more.

me neither, grep was my first try too :)


and if that's the case, could you please suggest something to have it done properly?
XML protocols can be quite tricky regarding such dynamic issues.

Maybe we would need a combination of both,

here we goo: https://github.com/rare-freertr/freeRtr/commit/fad8d14ac3a998da1e93f0dd7e00e9ed57539b40

for now it blindly appends the two versions you suggested... :)

could you please give it a try if it shuts the mouth of ncclient?
When trying freertr with out the "format" option for
"exec autocommand netconf ..." in "server telnet xxx",
an rpc reply is received, as it was before.

Unfortunately, ncclient library now complains
about double declaration of unprefixed namespace:

...
MainProcess[2538816] 2023-02-14 13:13:50,249 ncclient.transport.ssh ERROR: [host
10.0.3.212 session-id 249935048] error parsing dispatch message: Attribute xmlns:nc
redefined, line 2, column 172 (<string>, line 2)
...

Do you think it is somehow possible to check whether the namespace is already declared within
the <rpc ...> seen from the client
and in this case not to add it blindly?

Maybe, ideally the same applies to the unprefixed namespace
(not necessary now, but more in general for the future)?

Sorry, XML name space handling makes things more complicated.

Best Regards
David


thanks,
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