[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

IPQoS not affecting TCP_NODELAY



I'm seeing a problem with the ssh IPQoS setting not causing TCP_NODELAY to be set.

There was Bug#643312 that looks similar, but has been fixed:
openssh-client: IPQoS option ignored for AF_INET since 5.9p1-1
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643312

I have openssh-client version 1:6.0p1-4, from wheezy.

I'm wondering whether I should file a bug report for this, or maybe it's a problem
on my end?

Here's what I'm seeing. 

I want to create an ssh tunnel to a machine to get mail from a Dovecot POP3
server, to minimize my attack surface by not exposing the POP3 port to the
Internet. (I just want the ssh port open.) But, the ssh tunnel takes 80 seconds
to start working. After that, it's fine. The change over happens when
TCP_NODELAY gets set. I'd like for this to be set from the start, to avoid the
80 second delay. I've changed IPQoS in ssh to do this, but still get the delay.

I've used nc to reproduce the problem. On the server I've put this in
/etc/ssh/sshd_config.  I don't think it's needed, but added it just to be sure:
IPQoS lowdelay lowdelay

nc is set to listen on server:
server> nc -l -p 1212

The tunnel from client is created with:
client> ssh -vvv -o IPQoS="lowdelay lowdelay" -o ExitOnForwardFailure=yes -fN -L1110:localhost:1212 server

The nc connection from the client, and an initial line to transmit, is made with:
client> nc localhost 1110
hello

The 80 second delay happens here. Then these log messages are seen, and everything
starts working fine:
debug1: Connection to port 1110 forwarding to localhost port 1212 requested.         
debug2: fd 6 setting TCP_NODELAY                                                     
debug2: fd 6 setting O_NONBLOCK                                                      
debug3: fd 6 is O_NONBLOCK                                                           
debug1: channel 2: new [direct-tcpip]                                                
debug2: channel 2: open confirm rwindow 2097152 rmax 32768

My understanding is that TCP_NODELAY should be set from the start, because of the
IPQoS="lowdelay lowdelay" setting. 

Any ideas why it may not be, or thoughts on whether I should file a bug?


Reply to: