Rare project developers

[David Schmitz <>]

Hi,

On Tue, 14 Feb 2023, mc36 wrote:

> Date: Tue, 14 Feb 2023 09:27:19 +0100
> From: mc36 <>
> To: David Schmitz <>
> Cc: 
> Subject: Re: [rare-dev] netconf
>
> hi,
>
> after asking my ide to "find usage" of "new encXmlEntry" i have a suspect:
> https://github.com/rare-freertr/freeRtr/blob/master/src/net/freertr/user/userNetconf.java#L338
> here the 2nd parameter called rpc is dynamic... asking to find usage of this 
> rpc variable seems
> to be set on the first valid occurance within the tree xml/rpc parameters of 
> the given tag...
> https://github.com/rare-freertr/freeRtr/blob/master/src/net/freertr/user/userNetconf.java#L227
>
> this is here to keep the message-id for example when replying...
>
> so hereby my expected beahviour according to the current code is that once 
> you ask <xml><rpc something anything><....
> then you'll have a reply with <rpc-reply something anything><....
I also has the impression that something like this could be going on.

> first, can you confirm this hypothesis with some debugs?

Here is the full debug from freertr (debug line netconf)
after restart of freertr 
during a NETCONF request from ncclient library:

myr1#info userLineHandler.doExec:userLine.java:783 netconf logged in from local:telnet 
<loop> 830 -> 10.0.3.1 40890
debug userNetconf.doSend:userNetconf.java:439 tx: <?xml version="1.0" 
encoding="UTF-8"?>
debug userNetconf.doSend:userNetconf.java:439 tx: <hello 
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:startup:1.0</capability><capability>http://www.freertr.org/yang/bgp4pe2e?module=bgp4pe2e</capability><capability>http://www.freertr.org/yang/freertr-bgp4peer?module=freertr-bgp4peer</capability><capability>http://www.freertr.org/yang/freertr-bgp4perf?module=freertr-bgp4perf</capability></capabilities><session-id>811936643</session-id></hello>
debug userNetconf.doRead:userNetconf.java:398 rx: <?xml version="1.0" encoding="UTF-8"?><nc:hello 
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"><nc:capabilities><nc:capability>urn:ietf:params:netconf:base:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:base:1.1</nc:capability><nc:capability>urn:ietf:params:netconf:capability:writable-running:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:candidate:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:startup:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file,https,sftp</nc:capability><nc:capability>urn:ietf:params:netconf:capability:validate:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:xpath:1.0</nc:capability><nc:capability>urn:ietf:params:ne
tconf:capability:notification:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:interleave:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:with-defaults:1.0</nc:capability></nc:capabilities></nc:hello>]]>]]>
debug userNetconf.doHello:userNetconf.java:200 ver: 11
debug userNetconf.doRead:userNetconf.java:422 rx: <?xml version="1.0" encoding="UTF-8"?><nc:rpc 
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" 
message-id="urn:uuid:e0f3f401-7421-44cb-8b10-92bfcbd069ac"><nc:get-config><nc:source><nc:running/></nc:source></nc:get-config></nc:rpc>
debug userNetconf.doSend:userNetconf.java:439 tx: <?xml version="1.0" 
encoding="UTF-8"?>

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.

But the log in ncclient library clearly shows:
MainProcess[1426470] 2023-02-14 08:45:02,615 ncclient.transport.ssh DEBUG: 
[host 10.0.3.219 session-id 161959775] Received:
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" 
message-id="urn:uuid:9de3a34c-576f-4f5c-9a2b-721d20dd953c"><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></forma

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.

> 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,
trying to reuse the XML attributes as
seen from a previous NETCONF message from the client
+
getting the namespace prefixes for the returned XML element tree right
as expected by the client.


At least, I think, the ncclient library either expects:

<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" ...
or
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" ...
or
maybe any other namespace prefix, e.g. "xxx" just as an example,
<xxx:rpc-reply xmlns:xxx="urn:ietf:params:xml:ns:netconf:base:1.0" ...

Of course, regarding the prefixes of 
nested elements inside the <rpc-reply>
we will have to try and see ...

Best Regards
David

> thanks,
> cs
>
>
>
>
> On 2/14/23 09:02, David Schmitz wrote:
> > Hi,
> >
> > On Tue, 14 Feb 2023, mc36 wrote:
> >
> > > Date: Tue, 14 Feb 2023 08:23:00 +0100
> > > From: mc36 <>
> > > To: , David Schmitz <>
> > > Subject: Re: [rare-dev] netconf
> > >
> > > hi,
> > >
> > > tbh i feel a bit lost now as i'm already sending in the first format 
> > > suggestion of yours,
> > > and i remember that it was not a week ago when we removed the nc: tag 
> > > because some other
> > > xml parser complained about it... surely i can revert it but now seeking 
> > > for your confirmation...
> > Sorry for the confusion.
> >
> > We might require both namespace declarations in the <rpc-reply> element,
> > i.e.,
> > the xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" for the un-prefixed 
> > elements including the <rpc-reply> itself
> > and maybe - if needed - the 
> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" for "nc:"-refixed XML 
> > elements
> > which maybe still appear somewhere within the response.
> >
> >
> > I tried the newest commit (4d404aab00ce76d93f57a6dec5aec9c18b29fb0d 
> > v23.2.14)
> > (
> > ...
> > myr1#show version freeRouter v23.2.14-cur, done by cs@nop.
> >
> > place on the web: http://www.freertr.org/
> > license: http://creativecommons.org/licenses/by-sa/4.0/
> > quote1: make the world better
> > quote2: if a machine can learn the value of human life, maybe we can too
> > quote4: let bloom all the flowers
> > quote5: keep it stupid simple
> > quote6: be liberal in what you accept, and conservative in what you send
> > quote7: the beer-ware license for selected group of people:
> > cs@nop wrote these files. as long as you retain this notice you
> > can do whatever you want with this stuff. if we meet some day, and
> > you think this stuff is worth it, you can buy me a beer in return
> > ...
> > )
> >
> > and in the rpc-replies from freertr the ncclient library still sees the 
> > following:
> >
> > ...
> > MainProcess[1171815] 2023-02-14 07:42:08,687 ncclient.transport.ssh DEBUG: 
> > [host 10.0.3.219 session-id 428984427] Received:
> > <?xml version="1.0" encoding="UTF-8"?>
> > <rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" 
> > message-id="urn:uuid:6177bac4-41fe-4948-9ea8-4ad6ad7f96dd"><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>
> > ....
> >
> > That is consistent with debug from freertr ("debug line netconf"):
> > debug userNetconf.doSend:userNetconf.java:439 tx: <rpc-reply 
> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" 
> > message-id="urn:uuid:cc0688e8-7844-4b1e-9e2a-5fb86e03d5f5"><ok></ok></rpc-reply>
> >
> > Other NETCONF messages from freertr do not use the xmlns:nc="...":
> > debug userNetconf.doSend:userNetconf.java:439 tx: <hello 
> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:startup:1.0</capability><capability>http://www.freertr.org/yang/bgp4pe2e?module=bgp4pe2e</capability><capability>http://www.freertr.org/yang/freertr-bgp4peer?module=freertr-bgp4peer</capability><capability>http://www.freertr.org/yang/freertr-bgp4perf?module=freertr-bgp4perf</capability></capabilities><session-id>428984427</session-id></hello>
> >
> > Furtermore, I can see that in
> > net/freertr/user/userNetconf.java:
> > ...
> > l.58:   public final static String namespace = 
> > "xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\"";
> > ...
> >
> > BTW, before bothering you last week with this namespace stuff,
> > I tried to fix the issue in the code myself, with same change in 
> > net/freertr/user/userNetconf.java
> > (in now line 58) from
> > ...
> > namespace = "xmlns:nc=\"urn:ietf:params:xml:ns:netconf:base:1.0\"";
> > ...
> > to
> > ...
> > namespace = "xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\"";
> > ...
> >
> > But this change alone did not work.
> > So, I assumed that maybe there is more tricky stuff going on in the code
> > and so to let you figure out how to accomplish it.
> >
> >
> > Am I using the right commit?
> >
> >
> > Best Regards
> > David
> >
> > > thanks,
> > > cs
> > >
> > >
> > > 2023-02-14 08:19:34.007 debug userNetconf.doSend:userNetconf.java:439 tx: 
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > 2023-02-14 08:19:34.024 debug userNetconf.doSend:userNetconf.java:439 tx: 
> > > <rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > 2023-02-14 08:19:34.025 debug userNetconf.doSend:userNetconf.java:439 tx: 
> > > <data><config><hostname><sid>
> > > 2023-02-14 08:19:34.025 debug userNetconf.doSend:userNetconf.java:439 tx: 
> > > </sid></hostname>
> > >
> > >
> > > On 2/13/23 16:52, David Schmitz wrote:
> > > > 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">

--

David Schmitz

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