On Dec 15 05:39, Dave Korn wrote:
> 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.
Alternatively we could only set the send/recv buffer sizes if we're
running under pre-Vista. However, I have no idea what implications
this has in terms of network performance. "Somebody" would have to
test it.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
