Netopeer-server "]]>]]>" delimiter question

[mroz...@gmail.com]

Hey Guys,

1) I'm trying to use netopeer-server with java client (netconf4j library). The only problem is that for some reason my client library doesn't receive "]]>]]>" delimiter at the end of message. Is it somehow configurable? Everything looks fine in the netopeer-server logs, there is a confirmation that session was established:

"netopeer-server[13426]: Some message received
netopeer-server[13426]: Sending capabilities to agent.
netopeer-server[13426]: Some message received
netopeer-server[13426]: Created dummy session 13840 for user 'damian' (UID 1000) - recovery session
netopeer-server[13426]: New agent ID set to :1.134."

Below is a dump of rpc messages that I'm sending:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
]]>]]>

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config><source><running/></source></get-config></rpc>
]]>]]>

I found following statement int the RFC6242:"
"RFC 4742 assumes that the end-of-message (EOM) sequence, ]]>]]>,
cannot appear in any well-formed XML document, which turned out to be
mistaken. The EOM sequence can cause operational problems and open
space for attacks if sent deliberately in RPC messages. It is
however believed that the associated threat is not very high. This
document still uses the EOM sequence for the initial <hello> message
to avoid incompatibility with existing implementations. When both
peers implement base:1.1 capability, a proper framing protocol
(chunked framing mechanism; see Section 4.2) is used for the rest of
the NETCONF session, to avoid injection attacks."

2) I found information that you are going to release vm image with netopeer-gui. It would be awesome :)

Thanks for help!
Best Regards,
Damian

[Damian Mrozowicz]

Please forget about question number 1. It was caused by the bug in the netconf4j library - it reads response via java BufferedReader readLine() method whereas the message delimiter "]]>]]>" send by netopeer-server is not ended with '\n' so readLine() method was waiting for newline character that newer came :)

Thanks,
Damian

[Radek Krejčí]

Hi Damian,

Dne 27.8.2014 14:28, mroz...@gmail.com napsal(a):

> Hey Guys,
>
> 1) I'm trying to use netopeer-server with java client (netconf4j library). The only problem is that for some reason my client library doesn't receive "]]>]]>" delimiter at the end of message. Is it somehow configurable? Everything looks fine in the netopeer-server logs, there is a confirmation that session was established:
>
> "netopeer-server[13426]: Some message received
> netopeer-server[13426]: Sending capabilities to agent.
> netopeer-server[13426]: Some message received
> netopeer-server[13426]: Created dummy session 13840 for user 'damian' (UID 1000) - recovery session
> netopeer-server[13426]: New agent ID set to :1.134."
>
> Below is a dump of rpc messages that I'm sending:
> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> <capabilities>
> <capability>urn:ietf:params:netconf:base:1.0</capability>
> </capabilities>
> </hello>
> ]]>]]>
>
> <rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config><source><running/></source></get-config></rpc>
> ]]>]]>

it's not configurable. The "]]>]]>" sequence must always placed at the
end of the <hello> message. Framing mechanism of the following messages
depends on the common NETCONF protocol version. In your case, the
communication should continue with old framing, i.e. "]]>]]>" should
follow each message from the both, client and server (agent in case of
the Netopeer server).

You can try the following steps for debugging.

1) run the netopeer-server:
# netopeer-server -v 5

2) on the same host, run the netopeer-agent, which is actually
communicating with a client over SSH. In this case, it will communicate
with you in terminal and you will see what it sends to the client. In my
case, I saw these lines (note, that I delimited output from input by an
empty line starting with the agent's output, but it is just for formating):

$ netopeer-agent
<?xml version="1.0" encoding="UTF-8"?>

<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>
...
</capabilities>
<session-id>15896</session-id>
</hello>
]]>]]>

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>
]]>]]>

<rpc message-id="1"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><get-config><source><running/></source></get-config></rpc>
]]>]]>

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<data>
<netopeer xmlns="urn:cesnet:tmc:netopeer:1.0">
<modules>
<module>
<name>ietf-system</name>
<enabled>false</enabled>
</module>
</modules>
</netopeer>
<nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm">
<enable-nacm>true</enable-nacm>
<read-default>permit</read-default>
<write-default>deny</write-default>
<exec-default>permit</exec-default>
<enable-external-groups>true</enable-external-groups>
<rule-list>
<name>permit-all</name>
<group>users</group>
<rule>
<name>permit-all-rule</name>
<module-name>*</module-name>
<access-operations>*</access-operations>
<action>permit</action>
</rule>
</rule-list>
</nacm>
</data>
</rpc-reply>
]]>]]>

<rpc message-id="2"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><close-session/></rpc>
]]>]]>

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

]]>]]>


>
> I found following statement int the RFC6242:"
> "RFC 4742 assumes that the end-of-message (EOM) sequence, ]]>]]>,
> cannot appear in any well-formed XML document, which turned out to be
> mistaken. The EOM sequence can cause operational problems and open
> space for attacks if sent deliberately in RPC messages. It is
> however believed that the associated threat is not very high. This
> document still uses the EOM sequence for the initial <hello> message
> to avoid incompatibility with existing implementations. When both
> peers implement base:1.1 capability, a proper framing protocol
> (chunked framing mechanism; see Section 4.2) is used for the rest of
> the NETCONF session, to avoid injection attacks."
>
>
> 2) I found information that you are going to release vm image with netopeer-gui. It would be awesome :)

we would like to have it too, but currently it is not so close as you
would wish :) It's in our TODO list, but there is no specific deadline,
I prefer to make some changes in the GUI before providing this.

Best regards,
Radek

[Radek Krejčí]

ah, ok, so maybe my previous advice can you (or anybody else) help with debugging the communication :)

Regards,
Radek

Dne 27.8.2014 15:31, Damian Mrozowicz napsal(a):

--
You received this message because you are subscribed to the Google Groups "Netopeer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netopeer+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/netopeer.
For more options, visit https://groups.google.com/d/optout.

[Damian Mrozowicz]

Thank you for help and clarification :)

[hel...@ufersa.edu.br]

Hi, Damian.

Just for curiosity, have you overcome this bug - I mean, are you still using netconf4j despite its bug? I'm asking you because I'm using the API provided by Juniper and I can't even get the server capabilities...

Bye.

Helcio.