Subject: [Netconf] SSH question

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 10:36:34 -0700

Hi,

You know about openssh, and the ClientAliveInterval messages
that it sends ([email-masked])?  The client is
supposed to send data on the channel before N of these
arrive.

It seems that libssh2 drops these messages.
But if the NETCONF manager wanted to answer,
what can it send to the agent?  whitespace?
an XML comment?

Is the agent supposed to handle (discard) non-PDU messages
received on its channel? What is the most interoperable
way to send data to the agent without actually issuing
an <rpc> and wasting resources?

thanks,
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 Jun 2009 20:09:58 +0200 (CEST)

> It seems that libssh2 drops these messages.

Are you sure?  It's supposed to reply with an error if it doesn't
understand the request, since WantReply is set.

> received on its channel? 

This is unclear.  At least the counter inBadRpcs will be incremented.
One school of thought says that if garbage is received, the session
should be dropped.

> What is the most interoperable

I think you have to send an rpc.  kill-session on your own session id
should be cheap (just hope the server is 4741 compliant :)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 11:51:58 -0700

> understand the request, since WantReply is set.

well, there's nothing for the channel to read (EAGAIN),
even though the select() says there is.  Not sure if
it is pilot error on my part or not.

> should be cheap (just hope the server is 4741 compliant :)

I agree that the RFC text does not offer much wiggle room here.

I don't want to increment counters, especially error counters.
I wish there was a no-op() command in NETCONF.

A <get> may not be that cheap:

      <get>
        <filter>bogus</filter>
      </get>

   returns

      <data></data>

   right away.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Jun 2009 22:27:42 +0200

> an <rpc> and wasting resources?

I think you are confusing protocol layers. The [email-masked]
messages are sent as part of the SSH Connection Protocol (see RFC
4254) and they should trigger an SSH Connection Protocol reply. They
should never show up in the data stream carried over an SSH channel.
If they do, then the SSH implementation needs to be fixed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Jun 2009 18:42:57 -0700

> If they do, then the SSH implementation needs to be fixed.

thanks.
you are right -- these are CHANNEL_REQUEST messages,
not CHANNEL_DATA messages. Not sure what libssh2 is
answering with, but it isn't working (yet).

Andy