Subject: OPEN_FAILURE reason codes

From: der Mouse <[email-masked]>
Date: Tue, 7 Jun 2005 03:30:28 -0400 (EDT)

I'm working on my ssh implementation (big surprise) and have run into a
problem (even bigger surprise).

Specifically, I'm working on connection sharing.  In the circumstance
where the server has sent a CHANNEL_OPEN (eg, for a forwarded TCP
connection) and we've sent it on to the client, but our own connection
to the client drops before we get either success or failure back, I
more or less have to synthesize a failure to send back to the server.
But the problem is, what reason code should I use?  Only four are
defined

	SSH_OPEN_ADMINISTRATIVELY_PROHIBITED
	SSH_OPEN_CONNECT_FAILED
	SSH_OPEN_UNKNOWN_CHANNEL_TYPE
	SSH_OPEN_RESOURCE_SHORTAGE

and none of them really fit.  CONNECT_FAILED is perhaps the closest,
but gives the wrong impression, especially for forwarded TCP
connections.

What do you people think is best?  Should I just use CONNECT_FAILED, or
should I use one of the 0xf[ef]* codes and put something explanatory in
the reason string, or campaign to get a new reason code assigned from
the standardized space, or what?  I can see arguments for each, and am
interested in any thoughts any of you may have on the matter.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: [email-masked] (Niels Möller)
Date: 07 Jun 2005 22:04:04 +0200

> but gives the wrong impression, especially for forwarded TCP

I'd say use CONNECT_FAILED, and put some reasonable message in the
explanation string. Feel free to propose additional standard error
codes (perhaps we should have a kitchen sink code for failures not
matching any other?), but I don't think these numeric codes are
terribly important.

In your scenario, no matter which code you use, the only reasonable
action on the server's side is to close the connection it tried to
forward, with no error message of any kind propagated.

Regards,
/Niels