Re: Issues with TCP Window Scaling Factor and Cygwin Daemons

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 15/12/2011 05:23, Lee wrote:
> On 12/14/11, David Groves wrote:
>> I am having some issues with cygwin applications (specifically sshd)
>> and TCP Window Scaling Factors. I am using OpenSSH client on either a
>> Debian Linux or FreeBSD machine to connect to sshd on a Windows 2k8 R2
                                                           ^^^^^^^^^^^^^^
>> server.

> No pointers, but it does look like a Cygwin problem.
> 
> Start up wireshark on a Windows XP machine and ssh (from a cygwin
                          ^^^^^^^^^^^^^^^^^^
> window) to another machine - tcp syn packet has a window size of 65535
> and a widow scale of zero.  Use putty from the dos prompt to ssh to
> the same machine and that has a window size of 65535 and a window
> scale of 2

  1.  MS completely replaced the networking stack in Vista/2k8 with their
so-called "Next Generation TCP/IP stack", so you can't extrapolate from XP to 2k8.

  2.  On XP, window scaling is enabled by a registry setting, and when it is
in effect, Windows decides what scale setting to use by considering the
SO_RCVBUF size used when the connection is initiated.  In that light, the fact
that Cygwin applications show a scale of zero is probably not unrelated to
this snippet of code from net.cc#fdsock():

>   /* Raise default buffer sizes (instead of WinSock default 8K).
> 
>      64K appear to have the best size/performance ratio for a default
>      value.  Tested with ssh/scp on Vista over Gigabit LAN.
> 
>      NOTE.  If the SO_RCVBUF size exceeds 65535(*), and if the socket is
>      connected to a remote machine, then calling WSADuplicateSocket on
>      fork/exec fails with WinSock error 10022, WSAEINVAL.  Fortunately
>      we don't use WSADuplicateSocket anymore, rather we just utilize
>      handle inheritance.  An explanation for this weird behaviour would
>      be nice, though.
> 
>      (*) Maximum normal TCP window size.  Coincidence?  */
>   ((fhandler_socket *) fd)->rmem () = 65535;
>   ((fhandler_socket *) fd)->wmem () = 65535;
>   if (::setsockopt (soc, SOL_SOCKET, SO_RCVBUF,
> 		    (char *) &((fhandler_socket *) fd)->rmem (), sizeof (int)))
>     {
	[ ... snip error handling ... ]
>     }

  I would guess that a >65536 default would cause Windows to send a non-zero
scale in the SYN packet, but as the comment says, that created some other sort
of problem somehow.

  3.  On 2k8 (also Vista and 7), window scaling is no longer controlled by the
registry but enabled automatically, as part of a new feature called "Receive
Window Auto-Tuning".  I could not infer from any documentation that I could
find in ten minutes googling whether or not it still pays attention to the
initial SO_RCVBUF setting.  It might be worth trying a custom build of the
Cygwin DLL with a 64k or 128k setting in place of 65535.  Then again, it seems
there may yet be problems in this functionality, e.g. the known bug described
at http://support.microsoft.com/kb/983528; perhaps if the custom Cygwin DLL
doesn't help, that hot-fix might.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple