8000 Netopeer seems to cut off some NETCONF messages (chunked framing) · Issue #151 · CESNET/netopeer · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Netopeer seems to cut off some NETCONF messages (chunked framing) #151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
predi opened this issue May 10, 2017 · 0 comments
Open

Netopeer seems to cut off some NETCONF messages (chunked framing) #151

predi opened this issue May 10, 2017 · 0 comments

Comments

@predi
Copy link
predi commented May 10, 2017 •
edited
Loading

I have a verbatim netopeer server, which means that I have just compiled it and attempted to use it using our client after initial configuration.

Upon trying to issue a <get-schema> operation in order to retrieve a YIN file from the server, our client receives an incomplete chunked framing message. The chunk size promises 37218 bytes of data, yet we only receive 27005 bytes.

This seems to happen almost every time we attempt to issue the following :

<get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
  <identifier>ietf-netconf</identifier>
  <version>2011-06-01</version>
  <format>yin</format>
</get-schema>

I have attached the state of our buffers for the entire session (binary files) with the exact bytes we received on our side. You can see in the data that the server reports a <hello> (buff01.bin, buff02.bin), followed by the first chunked framing message that is cut off (buff03.bin - buff07.bin), then followed by another start of a chunked framing message (buff08.bin - buff10.bin). Our client has no choice but to terminate the session during the second reply, since it does not encounter the expected byte after 37218 bytes that were promised.

buffers.zip

Each buffer has at most 8192 bytes, since that is the max amount of bytes our client reads in a single blocking read.

An example of server's verbose output when the issue occurs: buffers.txt.

Our client is able to utilize several SSH library implementations, and this issue seems to affect just one of them, the ganymed-ssh2-build250 library. Note however, that netopeer is the only server implementation that has shown to be problematic to deal with by our client.

Netopeer should probably terminate the session if it cannot write data to the input stream (for any reason). You cannot ensure consistency of sent data otherwise, as my issue demonstrates.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@predi
0