This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Issues with TCP Window Scaling Factor and Cygwin Daemons
On 12/15/11, 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.
Arguh.. I don't know where I got WinXP from. Sorry for the noise.
Lee
> 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
>
>
--
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