Hello. thank you for the response. Ok, so in looking at this
further, I find I have more questions regarding this connection and the way
NetBSD operates.
1. Tcpdump says there is an wscale value of 3. Yet, Michael suggests the
shift value is 8. How does one read the wscale value in the TCP options?
A value of 4197 shifted by 3 to the left gets me a window size that looks
right, so I'm a little confused here.
2. Did NetBSD change the way it sends window scaling packets between
NetBSD-4 and NetBSD-5? I have window scaling turned on on both the 4.x amd
5.x machines, both net.inet.tcp.rfc1323 and net.inet.tcp.win_scale are set
to 1 on both machines. Yet, the 4.x machine sends a scaling value of 0 on
initial packets, and the 5.x machine sends a scaling value of 3. Both ways
are correct, I suppose, but isn't the 4.x way more backward compatible with
older stacks, including NetBSD stacks? I thought you were only supposed to
use window scaling when you wanted to have window sizes of larger than 64K?
A little more poking is in order, I suppose.
-thanks
-Brian
On Dec 23, 3:24pm, "Michael L. Hitch" wrote:
} Subject: Re: Problems with TCP Window size under NetBSD-5???
} On Thu, 23 Dec 2010, Brian Buhrow wrote:
}
} > The trace shows that the initial window size is correct, but that when
} > subsequent packets are generated, the window size drops to the numbers shown
} > above. This makes me think that the calls to soreserve() in in
} > tcp_usrreq.c aren't working, or the buffers are being lost or unused,
} > somehow. Still poking.
}
} The window sizes look good to me - they are scaled by 8 in one
} direction, and tcpdump does not keep track of the scale factor, so it
} display the raw value in the packet.
}
}
} --
} Michael L. Hitch mhi...@montana.edu
} Computer Consultant
} Information Technology Center
} Montana State University Bozeman, MT USA
>-- End of excerpt from "Michael L. Hitch"
