Hello. I'm hoping someone can shed light on this problem and that I'm
just missing something way too obvious to notice.
I have a backup server which was running NetBSD-3, then NetBSD-4, and
finally NetBSD-5. I noticed that my backups began taking 2 to 3 times
longer when I switched to NetBSD-5, but only for certain backup clients.
Investigation revealed that the problem appears to be that regardless of
what net.inet.tcp.sendspace is set to, and regardless of whether I have
net.inet.tcp.recvbuf_auto turned on or not, the window size on all
connections get set to 4K or less once the connection is established.
This behavior exactly explains what I'm seeing and why clients which are
further away from my backup server are more adversely affected than those
which are close by and have only short delays between them and the backup
server.
The tcpdump log segment below demonstrates the problem I'm seeing.
10.23.230.125 is a 4.x host, which doesn't demonstrate the problem, while
10.23.230.8 is a 5.x host which does demonstrate the problem. Notice how
the initial sin/ack packet does show the correct window size of 32K, but
subsequent packets coming back from 230.8 to 230.125 always show a window
size of 4K or less.
I'm runing 5.x sources of June 2009, but I believe this problem still
exists in 5.1, though I haven't checked.
To check the issue against a given machine, just capture a tcpdump
trace of a tcp session to an open port on that machine. I used port 22,
but any port will do. You don't need to pass much traffic, because the
window size immediately gets set at this very low value.
If anyone can explain this behavior, or can show how it can be fixed,
or can show what I've done wrong, I'm all ears. I'm tempted to file a bug,
but am curious to know if anyone else can reproduce this problem on this
list.
-thanks
-Brian
12:43:51.889823 IP 10.23.230.125.63866 > 10.23.230.8.22: S
2296327294:2296327294(0) win 32768 <mss 1460,nop,wscale
0,sackOK,nop,nop,nop,nop,timestamp 0 0>
12:43:51.889914 IP 10.23.230.8.22 > 10.23.230.125.63866: S
3672018915:3672018915(0) ack 2296327295 win 32768 <mss 1460,nop,wscale
3,nop,nop,timestamp 1 0,sackOK,nop,nop>
12:43:51.890003 IP 10.23.230.125.63866 > 10.23.230.8.22: . ack 1 win 33580
<nop,nop,timestamp 0 1>
12:43:51.911381 IP 10.23.230.8.22 > 10.23.230.125.63866: P 1:58(57) ack 1 win
4197 <nop,nop,timestamp 1 0>
12:43:52.110481 IP 10.23.230.125.63866 > 10.23.230.8.22: . ack 58 win 33580
<nop,nop,timestamp 0 1>
12:43:53.239693 IP 10.23.230.125.63866 > 10.23.230.8.22: P 1:3(2) ack 58 win
33580 <nop,nop,timestamp 2 1>
12:43:53.239872 IP 10.23.230.8.22 > 10.23.230.125.63866: P 58:77(19) ack 3 win
4197 <nop,nop,timestamp 3 2>
12:43:53.239903 IP 10.23.230.8.22 > 10.23.230.125.63866: F 77:77(0) ack 3 win
4197 <nop,nop,timestamp 3 2>
12:43:53.239988 IP 10.23.230.125.63866 > 10.23.230.8.22: . ack 78 win 33580
<nop,nop,timestamp 2 3>
12:43:53.240057 IP 10.23.230.125.63866 > 10.23.230.8.22: F 3:3(0) ack 78 win
33580 <nop,nop,timestamp 2 3>
12:43:53.240083 IP 10.23.230.8.22 > 10.23.230.125.63866: . ack 4 win 4197
<nop,nop,timestamp 3 2>
