On Dec 10, 2011, at 7:50 AM, Frank Schuhmann wrote: > Because you wrote that the Win XP was not producing the problem, but Win 7 > should do it, it is perhaps the TCP window scaling, as declared in the RFC > 1323. > In some similar other cases it was sometimes fixing the problem (pfsense) and > in > sometimes also not, but to quick test it out the spended time will to be of > value. > On the BSD side perhaps you try to turn of the scaling, I´m not an OpenBSD > professional but it must be turn out by setting up a shell order likes <sysctl > -w net.inet.tcp.rfc1323=0> > If not or it must be typed in, in other direction it will be super that > perhaps > an OpenBSD familiar list member would correct this please.
RFC1323 affects the end to end TCP connection. Unless there is a proxy running on the 5501, its RFC1323 settings won't change things. But I agree with this, and the previous poster, that a likely "cause" is Win7 using RFC1323 and other TCP optimizations (e.g. SACK) for more efficient transfers, so the 5501 is working harder. However another thing occurs to me. I wonder how Path MTU is being dealt with in this scenario. I have far too much experience[1] with various tunneling methods (e.g. VPN) that do not correctly support Path MTU Discovery. We ended up with the ugly, but effective, kludge of artificially lowering the MTUs on the server and client network stacks to compensate. And about half the time when we deploy something new, it breaks until we remember to change the default MTU setting. Perhaps these new Windows 7 boxes don't have that applied, so you're getting a lot of fragmenting at the 5501, and possibly reassembly (although often this is left to the receiving host to do). Seems like a long shot as the usual symptoms for us is no bulk traffic, but YMMV. -Jed [1] The painful sort. _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
