Netconf 1.1 chunk framing decoder is sensitive to extra LFs between Hello message and first chunk header

Recently, our Netconf server implemented support for Netconf 1.1, which means that when using the Netconf 1.1-capable ODL to connect to the server, the Netconf chunk framing protocol is used after the inital Hello message.

After the Hello message exchange, ODL queries the server for he supported Yang schemas under the /schema subtree.

Earlier, when using Netconf 1.0, the rpc-reply sent by the server looked like the snippet in attachment "get_base10.txt". It can be seen that there is one LF between the Hello message separator and the beginning of the following rpc-reply message. This works fine.

When using Netconf 1.1, the the data sent by the server looks like the snippet in attachment "get_base11.txt". It can be seen that there is now two LFs between the Hello message separator and the chunk header for the following rpc-reply message.

The extra LF in our server's response message comes from the fact that the chunk header begins with a LF, which comes after the LF that trails the Hello message separator. It can be argued if this is correct or not. RFC 6242 is not clear whether it is allowed to have extra LFs between Hello message delimiter and the following chunk header.

In any case, ODL doesn't like this extra LF, the NetconfChunkAggregor.java class complains about finding an LF instead of an # as the second byte in the header. An exception is thrown and the whole Netconf session setup fails and terminates.

This ticket is a suggestion to make the ODL Netconf chunk framing protocol parser more robust, by being able to ignore extra LFs when looking for the beginning of the first chunk header after the Hello message. RFC 6242 is not clear whether it is allowed to have extra LFs between Hello message delimiter and the following chunk header, so it would be good to make ODL tolerant here.