openssh unix dev - May 2006 - Problems with proxy connections

Could someone explain to me how the proxy command regression test works? 
I'm having a problem as it relates to the HPN patch and could use a 
little insight into what is happening in the proxy connections.

The back story is that the HPN patch was failing the regression tests 
when it his the proxy connections. It would just hang because the tcp 
window size that we get when a channel is created was returning 0. That 
set the internal receive buffer to 0 which just hung up everything.

I was able to get around the problem by explicitly testing to see if the 
connection was on a socket with packet_connection_is_on_socket. If its 
false then I return an arbitrary value (in this case 128k). Otherwise I 
return the window size. I don't like this solution though because, even 
though I know it works, I don't know enough to know if its working in 
the right way.

So the question is, what is this connection type and are there any 
thoughts on what the correct value would be to return?

Chris Rapier wrote:
> Could someone explain to me how the proxy command regression test works? 
> I'm having a problem as it relates to the HPN patch and could use a 
> little insight into what is happening in the proxy connections.
Typically, the proxycommand is an external command that connects to the 
server somehow (eg directly, via a SOCKS server).  Usually (but not 
necessarily) this will be over a TCP connection.

In the case of the regress test, the proxycommand is actually a shell 
script that invokes sshd directly (in inetd mode, so it speaks the SSH 
protocol on its stdin/stdout) rather than making some kind of network 
connection.  In fact the shell script wrapper isn't necessary, but it's 
there to redirect sshd's stderr for debugging purposes.
> So the question is, what is this connection type and are there any 
> thoughts on what the correct value would be to return?
Good question, but I don't have any answer other than "it
depends".
Your arbitrary value of 128k or similar sounds as good as any.

A similar issue would also occur if a platform did not support the 
SO_RCVBUF socket option (dunno if such a platform exists, now or ever).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.