* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-18 2:03 FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case Martin Pool
@ 2002-09-18 1:58 ` David S. Miller
2002-09-18 2:09 ` Martin Pool
2002-09-18 2:30 ` Martin Pool
0 siblings, 2 replies; 23+ messages in thread
From: David S. Miller @ 2002-09-18 1:58 UTC (permalink / raw)
To: mbp; +Cc: ak, kuznet, netdev, Alan.Cox
Which 2.2.x kernel exactly? You don't specify this.
If it's old, please try to reproduce with more recent 2.2.x
kernels, and even more importantly make sure 2.4.x does not
exhibit this behavior.
^ permalink raw reply [flat|nested] 23+ messages in thread
* FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
@ 2002-09-18 2:03 Martin Pool
2002-09-18 1:58 ` David S. Miller
0 siblings, 1 reply; 23+ messages in thread
From: Martin Pool @ 2002-09-18 2:03 UTC (permalink / raw)
To: davem, ak, kuznet, netdev, Alan.Cox
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
(Sorry for spamming people directly; my list message didn't get a
reply and it's a serious bug in some circumstances.)
I've discovered a bug in Linux 2.2 that allows TCP sockets to get
stuck in FIN_WAIT1 with no timeout or retransmissions. Code to
demonstrate the problem, plus a tcpdump of it happening, is
attached. There are more details about what's going on, as I
understand it, in the headers.
I suspect there is a mishandling of sk->nonagle==2 in tcp_send_test(),
but I have not yet puzzled out the code enough to say exactly what it
is. I think basically the handling of a closing socket that still has
corks set is broken.
You might argue that this is a security bug because it allows local
users to consume arbitrarily large (?) kernel resources, and in some
cases the resources cannot be released without a reboot. (Or perhaps
a spoofed RST packet would fix it too.)
--
Martin
[-- Attachment #2: corked_demo.c --]
[-- Type: text/x-csrc, Size: 5627 bytes --]
/* -*- c-file-style: "java"; indent-tabs-mode: nil -*-
*
* corked_demo.c -- Demonstrate Linux 2.2 bug relating to TCP_CORKED sockets.
*
* Written 2002 by Martin Pool <mbp@sourcefrog.net>
*
* Build this, run it as root with something like "sudo ./corked_demo
* SOMEHOST 9" to write to the discard port. (It needs root access to
* set SO_DEBUG.) The other machine must be running the discard
* service to accept the connection and data.
*
* Basically all it does is open a corked connection, and then drop it
* while there is (possibly) data in the SendQ. The socket gets
* "stuck" in FIN_WAIT1 and doesn't seem to be able to flush the last
* bit of data.
*
* If you have an affected version of the kernel, most times this is
* run run you will get a socket stuck in FIN_WAIT1 state. It looks
* like this:
*
* tcp 0 3201 maudlin:1048 maudlin:discard FIN_WAIT1 root 0 - off (0.00/0/0)
*
* This happens in 2.2.16, .18, and .21.
*
* It seems to me that this *has* to be incorrect, because there is
* data waiting to go out, but no timer running. The socket stays
* stuck, chewing up kernel memory forever.
*
* Running a hundred iterations gives 36 stuck in this state.
*
* On the server the situation is almost as bad: the sockets end up in
* ESTABLISHED state, but they'll never recieve more data. Presumably
* they'll hang around until the server gives up and terminates, or
* until the TCP 2-hour timeout elapses.
*
* Sometimes killing off the server makes the FIN_WAIT1 sockets go
* away on the client, but it is not reliable. However, neither side
* seems to time out of its own accord -- I left the two machines
* sitting overnight and all the sockets were still
* FIN_WAIT1/ESTABLISHED in the morning.
*
* tcpdump shows that the FIN is not sent when the client program
* closes the socket. However, when the server program is killed, its
* FIN gets things flowing again.
*
* I think that on the system where this was originally seen, both the
* client and the server used corks, and so killing the server program
* and closing its socket didn't send a FIN, and therefore things
* stayed jammed indefinitely.
*
* Since this can be provoked with local unprivileged access, and
* since the sockets apparently can't be cleared up without a reboot,
* it could be considered a kind of resource exhaustion attack. If it
* happens inadvertently, it can cause problems on the server by
* causing the remote machine to hang until it is killed off. */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <assert.h>
#include <string.h>
#include <fcntl.h>
#include <errno.h>
#include <signal.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <netdb.h>
/**
* Open a socket to a tcp remote host with the specified port.
*
* The socket is (if appropriate) corked on return, so that the third
* handshake should be sent containing useful data.
*
* Stolen from rsync via distcc.
*
* @todo Don't try for too long to connect.
**/
int open_socket_out(const char *host, int port, int *p_fd)
{
int type = SOCK_STREAM;
struct sockaddr_in sock_out;
int fd;
struct hostent *hp;
fd = socket(PF_INET, type, 0);
if (fd == -1) {
printf("failed to create socket: %s\n", strerror(errno));
exit(1);
}
hp = gethostbyname(host);
if (!hp) {
fprintf(stderr, "unknown host: \"%s\"\n", host);
(void) close(fd);
exit(1);
}
memcpy(&sock_out.sin_addr, hp->h_addr, (size_t) hp->h_length);
sock_out.sin_port = htons(port);
sock_out.sin_family = PF_INET;
if (connect(fd, (struct sockaddr *) &sock_out, (int) sizeof(sock_out))) {
fprintf(stderr, "failed to connect to %s port %d: %s\n", host, port,
strerror(errno));
(void) close(fd);
exit(1);
}
printf("client got connection to %s port %d on fd%d\n", host, port, fd);
*p_fd = fd;
return 0;
}
/**
* Stick a TCP cork in the socket.
**/
int tcp_cork_sock(int fd, int corked)
{
if (setsockopt(fd, SOL_TCP, TCP_CORK, &corked, sizeof corked) == -1) {
fprintf(stderr, "setsockopt(corked=%d) failed: %s\n",
corked, strerror(errno));
exit(1);
}
printf("%scorked fd%d\n", corked ? "" : "un", fd);
return 0;
}
int debug_sock(int fd, int debug_on)
{
if (setsockopt(fd, SOL_SOCKET, SO_DEBUG, &debug_on, sizeof debug_on) == -1) {
fprintf(stderr, "setsockopt(debug=%d) failed: %s\n",
debug_on, strerror(errno));
exit(1);
}
printf("%sdebug fd%d\n", debug_on ? "" : "un", fd);
return 0;
}
int dcc_writex(int fd, const void *buf, size_t len)
{
ssize_t r;
while (len > 0) {
r = write(fd, buf, len);
if (r == -1) {
fprintf(stderr, "failed to write: %s\n", strerror(errno));
return -1;
} else if (r == 0) {
fprintf(stderr, "unexpected eof on fd%d\n", fd);
return -1;
} else {
buf = &((char *) buf)[r];
len -= r;
}
}
return 0;
}
int send_junk(int fd)
{
static char trash[100000];
return dcc_writex(fd, trash, sizeof trash);
}
int main(int argc, char **argv)
{
int fd;
if (argc != 3) {
fprintf(stderr, "usage: corked_demo HOST NUMERICPORT\n");
return 1;
}
open_socket_out(argv[1], atoi(argv[2]), &fd);
debug_sock(fd, 1);
tcp_cork_sock(fd, 1);
send_junk(fd);
return 0;
}
[-- Attachment #3: corked_tcpdump.txt --]
[-- Type: text/plain, Size: 5257 bytes --]
tcpdump: listening on eth0
04:39:25.336746 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: S 2229455302:2229455302(0) win 16060 <mss 1460,sackOK,timestamp 5592391[|tcp]> (DF)
04:39:25.336913 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: S 3652179257:3652179257(0) ack 2229455303 win 5792 <mss 1460,sackOK,timestamp 352437103[|tcp]> (DF)
04:39:25.337134 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . ack 1 win 16060 <nop,nop,timestamp 5592391 352437103> (DF)
04:39:25.343813 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: P 1:1449(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.344057 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: P 1449:2897(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.344012 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 1449 win 8688 <nop,nop,timestamp 352437103 5592392> (DF)
04:39:25.344160 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 2897 win 11584 <nop,nop,timestamp 352437103 5592392> (DF)
04:39:25.344657 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 2897:4345(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.345093 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 4345:5793(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.345299 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 5793:7241(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.345407 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 7241:8689(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.345059 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 4345 win 14480 <nop,nop,timestamp 352437103 5592392> (DF)
04:39:25.345210 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 5793 win 17376 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.345389 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 7241 win 20272 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.345499 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 8689 win 23168 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.345686 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 8689:10137(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.345880 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 10137:11585(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437103> (DF)
04:39:25.346046 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 11585:13033(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437104> (DF)
04:39:25.346230 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 13033:14481(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437104> (DF)
04:39:25.346424 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 14481:15929(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437104> (DF)
04:39:25.346534 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 15929:17377(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437104> (DF)
04:39:25.346651 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 17377:18825(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437104> (DF)
04:39:25.346759 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . 18825:20273(1448) ack 1 win 16060 <nop,nop,timestamp 5592392 352437104> (DF)
04:39:25.345806 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 10137 win 26064 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.345970 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 11585 win 28960 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.346208 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 13033 win 31856 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.346323 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 14481 win 34752 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.346516 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 15929 win 37648 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.346624 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 17377 win 40544 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.346742 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 18825 win 43440 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.346849 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 20273 win 46336 <nop,nop,timestamp 352437104 5592392> (DF)
04:39:25.347261 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: . ack 21721 win 49232 <nop,nop,timestamp 352437104 5592392> (DF)
(now, kill the server)
04:39:43.795571 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: F 1:1(0) ack 99913 win 63712 <nop,nop,timestamp 352438965 5592393> (DF)
04:39:43.795643 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: . ack 2 win 16060 <nop,nop,timestamp 5594236 352438965> (DF)
04:39:43.795801 maudlin.ozlabs.hp.com.1884 > nevada.aus.hp.com.discard: FP 99913:100001(88) ack 2 win 16060 <nop,nop,timestamp 5594236 352438965> (DF)
04:39:43.795890 nevada.aus.hp.com.discard > maudlin.ozlabs.hp.com.1884: R 3652179259:3652179259(0) win 0 (DF)
36 packets received by filter
0 packets dropped by kernel
[-- Attachment #4: corked-out-20020917-2009 --]
[-- Type: text/plain, Size: 7668 bytes --]
ev: 1.0
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
scsi0: Target 0: Queue Depth 28, Asynchronous
scsi : detected 1 SCSI disk total.
SCSI device sda: hdwr sector= 512 bytes. Sectors= 2097152 [1024 MB] [1.0 GB]
pcnet32.c: PCI bios is present, checking for devices...
PCI Master Bit has not been set. Setting...
Found PCnet/PCI at 0x10a0, irq 10.
eth0: PCnet/PCI II 79C970A at 0x10a0, 00 50 56 40 00 52 assigned IRQ 10.
pcnet32.c:v1.25kf 26.9.1999 tsbogend@alpha.franken.de
Partition check:
sda: sda1 sda2 < sda5 >
IA-32 Microcode Update Driver: v1.08 <tigran@veritas.com>
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 60k freed
scsi0: Tagged Queuing now active for Target 0
Adding Swap: 268264k swap-space (priority -1)
tcp_snd_test sk=c7977740, skb=c7a72ac0, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87a40, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a877c0, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a877c0, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a877c0, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87680, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a875e0, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a875e0, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87540, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87540, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87540, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a874a0, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a874a0, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a874a0, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87400, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87400, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87400, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87180, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87180, tail=0
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87900, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87900, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a870e0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a870e0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87720, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87720, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87360, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87360, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a877c0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a877c0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a875e0, tail=1
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a875e0, tail=1
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a72ac0, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87360, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a870e0, tail=1
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a875e0, tail=1
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87860, tail=1
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87860, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87860, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a872c0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a872c0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87220, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87220, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87220, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87e00, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87e00, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87540, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87540, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a877c0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a877c0, tail=0
tcp_snd_test skb->flags=0x10, sk->nonagle=2, nagle_check=1
tcp_snd_test returns 1
tcp_snd_test sk=c7977740, skb=c7a87900, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=0
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87900, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=0
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87900, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=0
tcp_snd_test returns 0
tcp_snd_test sk=c7977740, skb=c7a87900, tail=1
tcp_snd_test skb->flags=0x18, sk->nonagle=2, nagle_check=0
tcp_snd_test returns 0
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-18 1:58 ` David S. Miller
@ 2002-09-18 2:09 ` Martin Pool
2002-09-18 23:38 ` Alexey Kuznetsov
2002-09-18 2:30 ` Martin Pool
1 sibling, 1 reply; 23+ messages in thread
From: Martin Pool @ 2002-09-18 2:09 UTC (permalink / raw)
To: David S. Miller; +Cc: ak, kuznet, netdev, Alan.Cox
On 17 Sep 2002, "David S. Miller" <davem@redhat.com> wrote:
>
> Which 2.2.x kernel exactly?
The person who originally reported the bug to me tried .16 and .18,
and I just reproduced it on .21, which was the most recent when I
started investigating.
I can try .22 or a .pre if you think it's already fixed somewhere.
> You don't specify this.
(Actually it was in the corked_demo.c comment header.)
> If it's old, please try to reproduce with more recent 2.2.x
> kernels, and even more importantly make sure 2.4.x does not
> exhibit this behavior.
I can't reproduce it on 2.4.18 or .19. It looked to me like
tcp_snd_test() and related stuff had been substantially rewritten.
--
Martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-18 1:58 ` David S. Miller
2002-09-18 2:09 ` Martin Pool
@ 2002-09-18 2:30 ` Martin Pool
1 sibling, 0 replies; 23+ messages in thread
From: Martin Pool @ 2002-09-18 2:30 UTC (permalink / raw)
To: David S. Miller; +Cc: ak, kuznet, netdev, Alan.Cox
For what it's worth, I can also reproduce the bug on 2.2.22rc3. It's
on a non-SMP machine with a very standard kernel config, no
firewalling, Debian 2.2.
I'm testing it under VMWare, but the same symptoms were observed by
other people on real hardware with Red Hat 6.2. It was originally
noticed in distcc, and this test case is basically just a
stripped-down version of the same code.
If the program uncorks the socket before closing it, then it cleans up
properly. However, if distcc is killed, then it can't do that and the
problem occurs. (The most recent version makes an effort to always
uncork, but obviously for e.g. SIGKILL it can't do much other than
avoid corks entirely.) Some people observed a couple of hundred (?)
sockets getting into this state.
--
Martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-18 2:09 ` Martin Pool
@ 2002-09-18 23:38 ` Alexey Kuznetsov
2002-09-26 5:47 ` Martin Pool
0 siblings, 1 reply; 23+ messages in thread
From: Alexey Kuznetsov @ 2002-09-18 23:38 UTC (permalink / raw)
To: Martin Pool; +Cc: davem, ak, netdev, Alan.Cox
Hello!
> I can't reproduce it on 2.4.18 or .19. It looked to me like
> tcp_snd_test() and related stuff had been substantially rewritten.
No, tcp_snd_test() in 2.2 is backport and it is accurate.
Apparently, the problem remained in another place, which was not backported.
I think this is tcp_send_fin(). It is obscure and apparently incorrect
at least on corked sockets. I would kill all the dubious "if" after
/* Special case to avoid Nagle bogosity....
and replaced it with straight tcp_push_pending_frames() like it was
made in 2.4. Please, try.
Alexey
BTW your tcpdump contains less than 25% of packets. And all the interesting
piece is absent completely. :-)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-18 23:38 ` Alexey Kuznetsov
@ 2002-09-26 5:47 ` Martin Pool
2002-09-26 13:09 ` kuznet
0 siblings, 1 reply; 23+ messages in thread
From: Martin Pool @ 2002-09-26 5:47 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: davem, ak, netdev, Alan.Cox
On 19 Sep 2002, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> wrote:
> Hello!
>
> > I can't reproduce it on 2.4.18 or .19. It looked to me like
> > tcp_snd_test() and related stuff had been substantially rewritten.
>
> No, tcp_snd_test() in 2.2 is backport and it is accurate.
> Apparently, the problem remained in another place, which was not backported.
>
> I think this is tcp_send_fin(). It is obscure and apparently incorrect
> at least on corked sockets. I would kill all the dubious "if" after
>
> /* Special case to avoid Nagle bogosity....
>
> and replaced it with straight tcp_push_pending_frames() like it was
> made in 2.4. Please, try.
Thanks for the hint! The change you suggested seems to reliably fix
the problem but I saw something else as well.
I was also a bit confused by the purpose of the (skb->len < mss_now)
term in tcp_send_fin(). As far as I can see, that if statement is to
do with deciding whether to make up a new FIN packet, or whether to
set the FIN bit on the final packet that is already queued.
It seems to me that in 2.2.21, if we ever have frames queued in
tp->send_head, and altogether they are more than the MSS, then it will
go through to the else branch, and make up and send a FIN packet
straight away. The FIN packet will be transmitted before the other
packets that are queued, even though they are earlier in sequence.
So, assuming no selective ACK, it will arrive out of order and just
have to be retransmitted later on.
I see that that test is gone in 2.4.18, and the expression is simply
(tp->send_head != NULL).
The patch is just below. It works with 2.2.22 too. If somebody could
let me know if it's OK I would appreciate it.
> BTW your tcpdump contains less than 25% of packets. And all the interesting
> piece is absent completely. :-)
I think the interesting bit is absent from the dump because it really
*is* absent -- the machine just never sends a FIN. (Or perhaps
tcpdump missed some packets?)
--- linux-2.2.21-cork/net/ipv4/tcp_output.c.orig Thu Sep 26 07:34:52 2002
+++ linux-2.2.21-cork/net/ipv4/tcp_output.c Thu Sep 26 07:59:52 2002
@@ -753,38 +753,23 @@ void tcp_send_fin(struct sock *sk)
{
struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
struct sk_buff *skb = skb_peek_tail(&sk->write_queue);
- unsigned int mss_now;
- /* Optimization, tack on the FIN if we have a queue of
- * unsent frames. But be careful about outgoing SACKS
- * and IP options.
- */
- mss_now = tcp_current_mss(sk);
+ if ((tp->send_head != NULL)) {
+ /* Optimization, tack on the FIN if we have a queue of
+ * unsent frames. But be careful about outgoing SACKS
+ * and IP options. Then send all outstanding frames,
+ * or turn on probe timer. */
- if((tp->send_head != NULL) && (skb->len < mss_now)) {
/* tcp_write_xmit() takes care of the rest. */
TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_FIN;
TCP_SKB_CB(skb)->end_seq++;
tp->write_seq++;
- /* Special case to avoid Nagle bogosity. If this
- * segment is the last segment, and it was queued
- * due to Nagle/SWS-avoidance, send it out now.
- */
- if(tp->send_head == skb &&
- !sk->nonagle &&
- skb->len < (tp->mss_cache >> 1) &&
- tp->packets_out &&
- !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_URG)) {
- update_send_head(sk);
- TCP_SKB_CB(skb)->when = tcp_time_stamp;
- tp->snd_nxt = TCP_SKB_CB(skb)->end_seq;
- tp->packets_out++;
- tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC));
- if(!tcp_timer_is_set(sk, TIME_RETRANS))
- tcp_reset_xmit_timer(sk, TIME_RETRANS, tp->rto);
- }
+ tcp_push_pending_frames(sk, tp);
} else {
+ /* Nothing is currently pending on this socket; make a
+ * FIN packet and send it directly. */
+
/* Socket is locked, keep trying until memory is available. */
for (;;) {
skb = sock_wmalloc(sk,
--
Martin
Want a faster compiler? http://distcc.samba.org/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-26 5:47 ` Martin Pool
@ 2002-09-26 13:09 ` kuznet
2002-09-26 20:46 ` David S. Miller
0 siblings, 1 reply; 23+ messages in thread
From: kuznet @ 2002-09-26 13:09 UTC (permalink / raw)
To: Martin Pool; +Cc: davem, ak, netdev, Alan.Cox
Hello!
> I was also a bit confused by the purpose of the (skb->len < mss_now)
Me too. :-)
It is not a bug though. See below.
> straight away. The FIN packet will be transmitted before the other
> packets that are queued, even though they are earlier in sequence.
> So, assuming no selective ACK, it will arrive out of order and just
> have to be retransmitted later on.
No really. It is _enqueued_, not sent. So, the only effect of the check
is that when the last frame happens to be mss-sized, FIN will be sent separately
though it could be attached to data. Not a problem.
> The patch is just below. It works with 2.2.22 too. If somebody could
> let me know if it's OK I would appreciate it.
I think it is OK. But, to be honest, it is the case when I do not feel
brave enough to give 100% warranty. :-) I do not understand why
tcp_push_pending_frames() was not used there... maybe, there was some reason
not to use it.
Dave, do you not remember this?
> I think the interesting bit is absent from the dump because it really
No, look at it again. It contains only the first 20% of data.
All the data and acks before connection termination are _lost_.
Alexey
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-26 13:09 ` kuznet
@ 2002-09-26 20:46 ` David S. Miller
2002-09-30 9:59 ` Martin Pool
0 siblings, 1 reply; 23+ messages in thread
From: David S. Miller @ 2002-09-26 20:46 UTC (permalink / raw)
To: kuznet; +Cc: mbp, ak, netdev, Alan.Cox
From: kuznet@ms2.inr.ac.ru
Date: Thu, 26 Sep 2002 17:09:11 +0400 (MSD)
I do not understand why tcp_push_pending_frames() was not used
there... maybe, there was some reason not to use it.
Dave, do you not remember this?
I was just trying to be too clever. That is all.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-26 20:46 ` David S. Miller
@ 2002-09-30 9:59 ` Martin Pool
2002-09-30 10:32 ` David S. Miller
2002-09-30 12:23 ` Alan Cox
0 siblings, 2 replies; 23+ messages in thread
From: Martin Pool @ 2002-09-30 9:59 UTC (permalink / raw)
To: David S. Miller; +Cc: kuznet, ak, netdev, Alan.Cox
On 26 Sep 2002, "David S. Miller" <davem@redhat.com> wrote:
> From: kuznet@ms2.inr.ac.ru
> Date: Thu, 26 Sep 2002 17:09:11 +0400 (MSD)
>
> I do not understand why tcp_push_pending_frames() was not used
> there... maybe, there was some reason not to use it.
>
> Dave, do you not remember this?
So where does this leave us?
Was the patch we came up with correct? It looks reasonable to me, but
I don't know the stack well enough to be sure. I think it would be
nice if it could be fixed in 2.2.
Let me know if there's anything I can do by way of testing, etc.
--
Martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-30 9:59 ` Martin Pool
@ 2002-09-30 10:32 ` David S. Miller
2002-09-30 12:23 ` Alan Cox
1 sibling, 0 replies; 23+ messages in thread
From: David S. Miller @ 2002-09-30 10:32 UTC (permalink / raw)
To: mbp; +Cc: kuznet, ak, netdev, Alan.Cox
From: Martin Pool <mbp@samba.org>
Date: Mon, 30 Sep 2002 19:59:10 +1000
On 26 Sep 2002, "David S. Miller" <davem@redhat.com> wrote:
> Dave, do you not remember this?
So where does this leave us?
Someone has to agree that the patch should go in.
Problem is, at least two of us do not run 2.2.x at all on any
of our systems (actually all of my currently powered-on machines
aren't even supported in 2.2.x) which makes it hard for
us to test this ourselves.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-30 9:59 ` Martin Pool
2002-09-30 10:32 ` David S. Miller
@ 2002-09-30 12:23 ` Alan Cox
2002-10-03 3:30 ` James Morris
1 sibling, 1 reply; 23+ messages in thread
From: Alan Cox @ 2002-09-30 12:23 UTC (permalink / raw)
To: Martin Pool; +Cc: David S. Miller, kuznet, ak, netdev, Alan.Cox
Well if Dave can't test it and isnt doing any 2.2 who wants to be the
2.2 networking maintainer ?
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-09-30 12:23 ` Alan Cox
@ 2002-10-03 3:30 ` James Morris
2002-10-03 3:54 ` Andi Kleen
2002-10-03 7:56 ` David S. Miller
0 siblings, 2 replies; 23+ messages in thread
From: James Morris @ 2002-10-03 3:30 UTC (permalink / raw)
To: Alan Cox; +Cc: Martin Pool, David S. Miller, kuznet, ak, netdev, Alan.Cox
On 30 Sep 2002, Alan Cox wrote:
> Well if Dave can't test it and isnt doing any 2.2 who wants to be the
> 2.2 networking maintainer ?
>
I'd be willing to give it a go.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-03 3:30 ` James Morris
@ 2002-10-03 3:54 ` Andi Kleen
2002-10-03 7:59 ` David S. Miller
2002-10-03 7:56 ` David S. Miller
1 sibling, 1 reply; 23+ messages in thread
From: Andi Kleen @ 2002-10-03 3:54 UTC (permalink / raw)
To: James Morris
Cc: Alan Cox, Martin Pool, David S. Miller, kuznet, ak, netdev,
Alan.Cox
On Thu, Oct 03, 2002 at 05:30:44AM +0200, James Morris wrote:
> On 30 Sep 2002, Alan Cox wrote:
>
> > Well if Dave can't test it and isnt doing any 2.2 who wants to be the
> > 2.2 networking maintainer ?
> >
>
> I'd be willing to give it a go.
2.2 networking unfortunately has some more SMP bugs (DaveM can tell you details)
which are hard to fix. So think twice before you volunteer ;)
-Andi
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-03 3:30 ` James Morris
2002-10-03 3:54 ` Andi Kleen
@ 2002-10-03 7:56 ` David S. Miller
1 sibling, 0 replies; 23+ messages in thread
From: David S. Miller @ 2002-10-03 7:56 UTC (permalink / raw)
To: jmorris; +Cc: alan, mbp, kuznet, ak, netdev, Alan.Cox
From: James Morris <jmorris@intercode.com.au>
Date: Thu, 3 Oct 2002 13:30:44 +1000 (EST)
On 30 Sep 2002, Alan Cox wrote:
> Well if Dave can't test it and isnt doing any 2.2 who wants to be the
> 2.2 networking maintainer ?
I'd be willing to give it a go.
So be it.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-03 3:54 ` Andi Kleen
@ 2002-10-03 7:59 ` David S. Miller
0 siblings, 0 replies; 23+ messages in thread
From: David S. Miller @ 2002-10-03 7:59 UTC (permalink / raw)
To: ak; +Cc: jmorris, alan, mbp, kuznet, netdev, Alan.Cox
From: Andi Kleen <ak@muc.de>
Date: Thu, 3 Oct 2002 05:54:46 +0200
On Thu, Oct 03, 2002 at 05:30:44AM +0200, James Morris wrote:
> On 30 Sep 2002, Alan Cox wrote:
>
> > Well if Dave can't test it and isnt doing any 2.2 who wants to be the
> > 2.2 networking maintainer ?
> >
>
> I'd be willing to give it a go.
2.2 networking unfortunately has some more SMP bugs (DaveM can tell you details)
which are hard to fix. So think twice before you volunteer ;)
These don't matter as much as you may think.
The real show stoppers are the ones like this FIN_WAIT1 cork
bug.
These are the only ones we can come up with safe fixes (in terms of
what this means for 2.2.x) for anyways.
Franks a lot,
David S. Miller
davem@redhat.com
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
@ 2002-10-04 15:06 James Morris
2002-10-04 23:27 ` Martin Pool
2002-10-05 7:51 ` Martin Pool
0 siblings, 2 replies; 23+ messages in thread
From: James Morris @ 2002-10-04 15:06 UTC (permalink / raw)
To: Martin Pool; +Cc: netdev
Martin,
I'm not able to reproduce the bug exactly as described. What kind of
network connection were you using between the boxes, and what was the
kernel version at the server end? (I've been testing between two boxes on
a 10Mbps lan, with 2.2.22 at the client side and both 2.2.20 and 2.4.19
kernels at the server side).
I'm seeing what looks like some quite buggy behaviour (which needs
further analysis), but no long term FIN_WAIT1 states.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-04 15:06 James Morris
@ 2002-10-04 23:27 ` Martin Pool
2002-10-05 7:51 ` Martin Pool
1 sibling, 0 replies; 23+ messages in thread
From: Martin Pool @ 2002-10-04 23:27 UTC (permalink / raw)
To: James Morris; +Cc: netdev
On 5 Oct 2002, James Morris <jmorris@intercode.com.au> wrote:
> Martin,
>
> I'm not able to reproduce the bug exactly as described. What kind of
> network connection were you using between the boxes, and what was the
> kernel version at the server end?
I was using VMware over 100Mbps to a 2.4.19 server. I am pretty sure
it could also be reproduced over localhost TCP just in 2.2.21 inside
VMware. I don't remember the exact hardware; I can let you know later.
It seems to not happen every time, but at least one time in three.
--
Martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-04 15:06 James Morris
2002-10-04 23:27 ` Martin Pool
@ 2002-10-05 7:51 ` Martin Pool
2002-10-05 11:53 ` James Morris
1 sibling, 1 reply; 23+ messages in thread
From: Martin Pool @ 2002-10-05 7:51 UTC (permalink / raw)
To: James Morris; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
On 5 Oct 2002, James Morris <jmorris@intercode.com.au> wrote:
> Martin,
>
> I'm not able to reproduce the bug exactly as described. What kind of
> network connection were you using between the boxes, and what was the
> kernel version at the server end? (I've been testing between two boxes on
> a 10Mbps lan, with 2.2.22 at the client side and both 2.2.20 and 2.4.19
> kernels at the server side).
The machine inside VMware is as shown below. This was originally
reported by a distcc user who was apparently experiencing the problem
on diverse hardware on a 100Mbps switched network.
Did you see the example code that I posted at the start of the thread?
I can't reproduce it locally, but I can reproduce it going to a 2.4.18
machine across a 100Mbps switched network. A tcpdump (complete?) is
attached.
mbp@maudlin:~$ lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (AGP disabled) (rev 01)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 08)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 08)
00:0f.0 VGA compatible controller: Unknown device 15ad:0405
00:10.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10] (rev 01)
00:11.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 10)
mbp@maudlin:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 1
model name : Intel(R) Pentium(R) 4 CPU 1.70GHz
stepping : 2
cpu MHz : 1696.308
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 cflush dtrace acpi mmx fxsr sse xmm2 ssnp 28 acc
bogomips : 2929.45
--
Martin
[-- Attachment #2: tcpdump_1050.txt --]
[-- Type: text/plain, Size: 16887 bytes --]
17:50:58.870451 192.168.1.173.1050 > 192.168.1.1.9: S 1182351029:1182351029(0) win 16060 <mss 1460,sackOK,timestamp 28693 0,nop,wscale 0> (DF)
17:50:58.870499 192.168.1.1.9 > 192.168.1.173.1050: S 1288275163:1288275163(0) ack 1182351030 win 5792 <mss 1460,sackOK,timestamp 501490331 28693,nop,wscale 0> (DF)
17:50:58.870730 192.168.1.173.1050 > 192.168.1.1.9: . ack 1 win 16060 <nop,nop,timestamp 28693 501490331> (DF)
17:50:58.875597 192.168.1.173.1050 > 192.168.1.1.9: P 1:1449(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490331> (DF)
17:50:58.875690 192.168.1.1.9 > 192.168.1.173.1050: . ack 1449 win 8688 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.875879 192.168.1.173.1050 > 192.168.1.1.9: P 1449:2897(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490331> (DF)
17:50:58.875940 192.168.1.1.9 > 192.168.1.173.1050: . ack 2897 win 11584 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.876271 192.168.1.173.1050 > 192.168.1.1.9: . 2897:4345(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.876348 192.168.1.1.9 > 192.168.1.173.1050: . ack 4345 win 14480 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.876527 192.168.1.173.1050 > 192.168.1.1.9: . 4345:5793(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.876585 192.168.1.1.9 > 192.168.1.173.1050: . ack 5793 win 17376 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.876748 192.168.1.173.1050 > 192.168.1.1.9: . 5793:7241(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.876804 192.168.1.1.9 > 192.168.1.173.1050: . ack 7241 win 20272 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.876994 192.168.1.173.1050 > 192.168.1.1.9: . 7241:8689(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.877056 192.168.1.1.9 > 192.168.1.173.1050: . ack 8689 win 23168 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.877283 192.168.1.173.1050 > 192.168.1.1.9: . 8689:10137(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.877354 192.168.1.1.9 > 192.168.1.173.1050: . ack 10137 win 26064 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.877524 192.168.1.173.1050 > 192.168.1.1.9: . 10137:11585(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.877579 192.168.1.1.9 > 192.168.1.173.1050: . ack 11585 win 28960 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.877794 192.168.1.173.1050 > 192.168.1.1.9: . 11585:13033(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.877856 192.168.1.1.9 > 192.168.1.173.1050: . ack 13033 win 31856 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.878020 192.168.1.173.1050 > 192.168.1.1.9: . 13033:14481(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.878074 192.168.1.1.9 > 192.168.1.173.1050: . ack 14481 win 34752 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.878235 192.168.1.173.1050 > 192.168.1.1.9: . 14481:15929(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.878290 192.168.1.1.9 > 192.168.1.173.1050: . ack 15929 win 37648 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.878445 192.168.1.173.1050 > 192.168.1.1.9: . 15929:17377(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.878498 192.168.1.1.9 > 192.168.1.173.1050: . ack 17377 win 40544 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.878656 192.168.1.173.1050 > 192.168.1.1.9: . 17377:18825(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.878712 192.168.1.1.9 > 192.168.1.173.1050: . ack 18825 win 43440 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.878865 192.168.1.173.1050 > 192.168.1.1.9: . 18825:20273(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.878920 192.168.1.1.9 > 192.168.1.173.1050: . ack 20273 win 46336 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.879151 192.168.1.173.1050 > 192.168.1.1.9: . 20273:21721(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.879222 192.168.1.1.9 > 192.168.1.173.1050: . ack 21721 win 49232 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.879424 192.168.1.173.1050 > 192.168.1.1.9: . 21721:23169(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.879486 192.168.1.1.9 > 192.168.1.173.1050: . ack 23169 win 52128 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.879662 192.168.1.173.1050 > 192.168.1.1.9: . 23169:24617(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.879720 192.168.1.1.9 > 192.168.1.173.1050: . ack 24617 win 55024 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.879877 192.168.1.173.1050 > 192.168.1.1.9: . 24617:26065(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.879931 192.168.1.1.9 > 192.168.1.173.1050: . ack 26065 win 57920 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.880091 192.168.1.173.1050 > 192.168.1.1.9: . 26065:27513(1448) ack 1 win 16060 <nop,nop,timestamp 28694 501490332> (DF)
17:50:58.880146 192.168.1.1.9 > 192.168.1.173.1050: . ack 27513 win 60816 <nop,nop,timestamp 501490332 28694> (DF)
17:50:58.880352 192.168.1.173.1050 > 192.168.1.1.9: . 27513:28961(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.880414 192.168.1.1.9 > 192.168.1.173.1050: . ack 28961 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.880581 192.168.1.173.1050 > 192.168.1.1.9: . 28961:30409(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.880639 192.168.1.1.9 > 192.168.1.173.1050: . ack 30409 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.880792 192.168.1.173.1050 > 192.168.1.1.9: . 30409:31857(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.880844 192.168.1.1.9 > 192.168.1.173.1050: . ack 31857 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.881037 192.168.1.173.1050 > 192.168.1.1.9: . 31857:33305(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.881099 192.168.1.1.9 > 192.168.1.173.1050: . ack 33305 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.881255 192.168.1.173.1050 > 192.168.1.1.9: . 33305:34753(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.881381 192.168.1.173.1050 > 192.168.1.1.9: . 34753:36201(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.881430 192.168.1.1.9 > 192.168.1.173.1050: . ack 36201 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.881727 192.168.1.173.1050 > 192.168.1.1.9: P 36201:37649(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.881806 192.168.1.1.9 > 192.168.1.173.1050: . ack 37649 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.881989 192.168.1.173.1050 > 192.168.1.1.9: P 37649:39097(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.882050 192.168.1.1.9 > 192.168.1.173.1050: . ack 39097 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.882210 192.168.1.173.1050 > 192.168.1.1.9: P 39097:40545(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.882266 192.168.1.1.9 > 192.168.1.173.1050: . ack 40545 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.882469 192.168.1.173.1050 > 192.168.1.1.9: P 40545:41993(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.882536 192.168.1.1.9 > 192.168.1.173.1050: . ack 41993 win 63712 <nop,nop,timestamp 501490332 28695> (DF)
17:50:58.883067 192.168.1.173.1050 > 192.168.1.1.9: P 41993:43441(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.883154 192.168.1.1.9 > 192.168.1.173.1050: . ack 43441 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.883400 192.168.1.173.1050 > 192.168.1.1.9: . 43441:44889(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.883545 192.168.1.173.1050 > 192.168.1.1.9: . 44889:46337(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.883597 192.168.1.1.9 > 192.168.1.173.1050: . ack 46337 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.883767 192.168.1.173.1050 > 192.168.1.1.9: . 46337:47785(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490332> (DF)
17:50:58.883934 192.168.1.173.1050 > 192.168.1.1.9: P 47785:49233(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.883990 192.168.1.1.9 > 192.168.1.173.1050: . ack 49233 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.884201 192.168.1.173.1050 > 192.168.1.1.9: P 49233:50681(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.884271 192.168.1.1.9 > 192.168.1.173.1050: . ack 50681 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.884441 192.168.1.173.1050 > 192.168.1.1.9: P 50681:52129(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.884499 192.168.1.1.9 > 192.168.1.173.1050: . ack 52129 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.884655 192.168.1.173.1050 > 192.168.1.1.9: P 52129:53577(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.884711 192.168.1.1.9 > 192.168.1.173.1050: . ack 53577 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.884913 192.168.1.173.1050 > 192.168.1.1.9: P 53577:55025(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.884982 192.168.1.1.9 > 192.168.1.173.1050: . ack 55025 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.885151 192.168.1.173.1050 > 192.168.1.1.9: P 55025:56473(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.885209 192.168.1.1.9 > 192.168.1.173.1050: . ack 56473 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.885408 192.168.1.173.1050 > 192.168.1.1.9: P 56473:57921(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.885652 192.168.1.1.9 > 192.168.1.173.1050: . ack 57921 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.885850 192.168.1.173.1050 > 192.168.1.1.9: P 57921:59369(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.885914 192.168.1.1.9 > 192.168.1.173.1050: . ack 59369 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.886077 192.168.1.173.1050 > 192.168.1.1.9: P 59369:60817(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.886134 192.168.1.1.9 > 192.168.1.173.1050: . ack 60817 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.886346 192.168.1.173.1050 > 192.168.1.1.9: P 60817:62265(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.886417 192.168.1.1.9 > 192.168.1.173.1050: . ack 62265 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.886589 192.168.1.173.1050 > 192.168.1.1.9: P 62265:63713(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.886645 192.168.1.1.9 > 192.168.1.173.1050: . ack 63713 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.886801 192.168.1.173.1050 > 192.168.1.1.9: P 63713:65161(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.886856 192.168.1.1.9 > 192.168.1.173.1050: . ack 65161 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.887054 192.168.1.173.1050 > 192.168.1.1.9: P 65161:66609(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.887123 192.168.1.1.9 > 192.168.1.173.1050: . ack 66609 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.887293 192.168.1.173.1050 > 192.168.1.1.9: P 66609:68057(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.887348 192.168.1.1.9 > 192.168.1.173.1050: . ack 68057 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.887502 192.168.1.173.1050 > 192.168.1.1.9: P 68057:69505(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.887558 192.168.1.1.9 > 192.168.1.173.1050: . ack 69505 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.887758 192.168.1.173.1050 > 192.168.1.1.9: P 69505:70953(1448) ack 1 win 16060 <nop,nop,timestamp 28695 501490333> (DF)
17:50:58.887826 192.168.1.1.9 > 192.168.1.173.1050: . ack 70953 win 63712 <nop,nop,timestamp 501490333 28695> (DF)
17:50:58.888073 192.168.1.173.1050 > 192.168.1.1.9: P 70953:72401(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.888142 192.168.1.1.9 > 192.168.1.173.1050: . ack 72401 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.888307 192.168.1.173.1050 > 192.168.1.1.9: P 72401:73849(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.888364 192.168.1.1.9 > 192.168.1.173.1050: . ack 73849 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.888574 192.168.1.173.1050 > 192.168.1.1.9: P 73849:75297(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.888642 192.168.1.1.9 > 192.168.1.173.1050: . ack 75297 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.888811 192.168.1.173.1050 > 192.168.1.1.9: P 75297:76745(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.888867 192.168.1.1.9 > 192.168.1.173.1050: . ack 76745 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.889023 192.168.1.173.1050 > 192.168.1.1.9: P 76745:78193(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.889080 192.168.1.1.9 > 192.168.1.173.1050: . ack 78193 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.889283 192.168.1.173.1050 > 192.168.1.1.9: P 78193:79641(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.889365 192.168.1.1.9 > 192.168.1.173.1050: . ack 79641 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.889550 192.168.1.173.1050 > 192.168.1.1.9: P 79641:81089(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.889611 192.168.1.1.9 > 192.168.1.173.1050: . ack 81089 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.889819 192.168.1.173.1050 > 192.168.1.1.9: P 81089:82537(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.889890 192.168.1.1.9 > 192.168.1.173.1050: . ack 82537 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.890089 192.168.1.173.1050 > 192.168.1.1.9: P 82537:83985(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.890152 192.168.1.1.9 > 192.168.1.173.1050: . ack 83985 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.890414 192.168.1.173.1050 > 192.168.1.1.9: P 83985:85433(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.890482 192.168.1.1.9 > 192.168.1.173.1050: . ack 85433 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.890732 192.168.1.173.1050 > 192.168.1.1.9: P 85433:86881(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.890803 192.168.1.1.9 > 192.168.1.173.1050: . ack 86881 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.890974 192.168.1.173.1050 > 192.168.1.1.9: P 86881:88329(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.891032 192.168.1.1.9 > 192.168.1.173.1050: . ack 88329 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.891188 192.168.1.173.1050 > 192.168.1.1.9: P 88329:89777(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.891244 192.168.1.1.9 > 192.168.1.173.1050: . ack 89777 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.891448 192.168.1.173.1050 > 192.168.1.1.9: P 89777:91225(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.891516 192.168.1.1.9 > 192.168.1.173.1050: . ack 91225 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.891684 192.168.1.173.1050 > 192.168.1.1.9: P 91225:92673(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.891744 192.168.1.1.9 > 192.168.1.173.1050: . ack 92673 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.891902 192.168.1.173.1050 > 192.168.1.1.9: P 92673:94121(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.891957 192.168.1.1.9 > 192.168.1.173.1050: . ack 94121 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.892157 192.168.1.173.1050 > 192.168.1.1.9: P 94121:95569(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.892225 192.168.1.1.9 > 192.168.1.173.1050: . ack 95569 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.892392 192.168.1.173.1050 > 192.168.1.1.9: P 95569:97017(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.892451 192.168.1.1.9 > 192.168.1.173.1050: . ack 97017 win 63712 <nop,nop,timestamp 501490333 28696> (DF)
17:50:58.893400 192.168.1.173.1050 > 192.168.1.1.9: P 97017:98465(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.893493 192.168.1.1.9 > 192.168.1.173.1050: . ack 98465 win 63712 <nop,nop,timestamp 501490334 28696> (DF)
17:50:58.893684 192.168.1.173.1050 > 192.168.1.1.9: P 98465:99913(1448) ack 1 win 16060 <nop,nop,timestamp 28696 501490333> (DF)
17:50:58.893744 192.168.1.1.9 > 192.168.1.173.1050: . ack 99913 win 63712 <nop,nop,timestamp 501490334 28696> (DF)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-05 7:51 ` Martin Pool
@ 2002-10-05 11:53 ` James Morris
2002-10-08 10:21 ` Martin Pool
2002-10-10 16:36 ` James Morris
0 siblings, 2 replies; 23+ messages in thread
From: James Morris @ 2002-10-05 11:53 UTC (permalink / raw)
To: Martin Pool; +Cc: netdev
On Sat, 5 Oct 2002, Martin Pool wrote:
> The machine inside VMware is as shown below. This was originally
> reported by a distcc user who was apparently experiencing the problem
> on diverse hardware on a 100Mbps switched network.
>
> Did you see the example code that I posted at the start of the thread?
Yep.
> I can't reproduce it locally, but I can reproduce it going to a 2.4.18
> machine across a 100Mbps switched network. A tcpdump (complete?) is
> attached.
Thanks for the extra info.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-05 11:53 ` James Morris
@ 2002-10-08 10:21 ` Martin Pool
2002-10-08 10:28 ` James Morris
2002-10-10 16:36 ` James Morris
1 sibling, 1 reply; 23+ messages in thread
From: Martin Pool @ 2002-10-08 10:21 UTC (permalink / raw)
To: James Morris; +Cc: netdev
On 5 Oct 2002, James Morris <jmorris@intercode.com.au> wrote:
> > I can't reproduce it locally, but I can reproduce it going to a 2.4.18
> > machine across a 100Mbps switched network. A tcpdump (complete?) is
> > attached.
>
> Thanks for the extra info.
OK, let me know if there's anything else you need. At a stretch I
could install 2.2 on a non-VM machine.
--
Martin Discontent Provider
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-08 10:21 ` Martin Pool
@ 2002-10-08 10:28 ` James Morris
0 siblings, 0 replies; 23+ messages in thread
From: James Morris @ 2002-10-08 10:28 UTC (permalink / raw)
To: Martin Pool; +Cc: netdev
On Tue, 8 Oct 2002, Martin Pool wrote:
> OK, let me know if there's anything else you need. At a stretch I
> could install 2.2 on a non-VM machine.
Thanks, but I can at least partially reproduce the problem with a specific
network configuration. At this stage, I'd say the patch supplied is
probably fine, but I'm taking some time to make sure I really understand
what's happening.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-05 11:53 ` James Morris
2002-10-08 10:21 ` Martin Pool
@ 2002-10-10 16:36 ` James Morris
2002-10-10 16:43 ` James Morris
1 sibling, 1 reply; 23+ messages in thread
From: James Morris @ 2002-10-10 16:36 UTC (permalink / raw)
To: Martin Pool; +Cc: netdev
Martin,
Below is a simplified version of your patch, which maintains the
(skb->len < mss_now) check per Alexey's comments.
Note that I've not been able to reproduce the problem with network
configurations from 10-1000Gbps and various combinations of hosts, kernels
and 'server' applications. I did run into what looked like stalled
ESTABLISHED/FIN_WAIT1 connections, although these turned out to be the
(valid) result of the server advertising zero windows after it ran out of
resources. The FIN_WAIT1 states on the client were running timers and
performing zero window probes. A further check showed that it didn't
matter if the client socket sockets were corked or not.
Would you please give this patch some testing? (It would be really great
if any of the RH 6.2 distcc users who reported problems could test it
also).
Thanks,
- James
--
James Morris
<jmorris@intercode.com.au>
diff -urN -X dontdiff linux-2.2.22.orig/net/ipv4/tcp_output.c linux-2.2.22.corkfix/net/ipv4/tcp_output.c
--- linux-2.2.22.orig/net/ipv4/tcp_output.c Fri May 10 12:10:08 2002
+++ linux-2.2.22.corkfix/net/ipv4/tcp_output.c Fri Oct 11 01:22:33 2002
@@ -766,24 +766,7 @@
TCP_SKB_CB(skb)->flags |= TCPCB_FLAG_FIN;
TCP_SKB_CB(skb)->end_seq++;
tp->write_seq++;
-
- /* Special case to avoid Nagle bogosity. If this
- * segment is the last segment, and it was queued
- * due to Nagle/SWS-avoidance, send it out now.
- */
- if(tp->send_head == skb &&
- !sk->nonagle &&
- skb->len < (tp->mss_cache >> 1) &&
- tp->packets_out &&
- !(TCP_SKB_CB(skb)->flags & TCPCB_FLAG_URG)) {
- update_send_head(sk);
- TCP_SKB_CB(skb)->when = tcp_time_stamp;
- tp->snd_nxt = TCP_SKB_CB(skb)->end_seq;
- tp->packets_out++;
- tcp_transmit_skb(sk, skb_clone(skb, GFP_ATOMIC));
- if(!tcp_timer_is_set(sk, TIME_RETRANS))
- tcp_reset_xmit_timer(sk, TIME_RETRANS, tp->rto);
- }
+ tcp_push_pending_frames(sk, tp);
} else {
/* Socket is locked, keep trying until memory is available. */
for (;;) {
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case
2002-10-10 16:36 ` James Morris
@ 2002-10-10 16:43 ` James Morris
0 siblings, 0 replies; 23+ messages in thread
From: James Morris @ 2002-10-10 16:43 UTC (permalink / raw)
To: Martin Pool; +Cc: netdev
> configurations from 10-1000Gbps and various combinations of hosts, kernels
Er, that is 10-1000Mbps :-)
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2002-10-10 16:43 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-09-18 2:03 FIN_WAIT1 / TCP_CORK / 2.2 -- reproducible bug and test case Martin Pool
2002-09-18 1:58 ` David S. Miller
2002-09-18 2:09 ` Martin Pool
2002-09-18 23:38 ` Alexey Kuznetsov
2002-09-26 5:47 ` Martin Pool
2002-09-26 13:09 ` kuznet
2002-09-26 20:46 ` David S. Miller
2002-09-30 9:59 ` Martin Pool
2002-09-30 10:32 ` David S. Miller
2002-09-30 12:23 ` Alan Cox
2002-10-03 3:30 ` James Morris
2002-10-03 3:54 ` Andi Kleen
2002-10-03 7:59 ` David S. Miller
2002-10-03 7:56 ` David S. Miller
2002-09-18 2:30 ` Martin Pool
-- strict thread matches above, loose matches on Subject: below --
2002-10-04 15:06 James Morris
2002-10-04 23:27 ` Martin Pool
2002-10-05 7:51 ` Martin Pool
2002-10-05 11:53 ` James Morris
2002-10-08 10:21 ` Martin Pool
2002-10-08 10:28 ` James Morris
2002-10-10 16:36 ` James Morris
2002-10-10 16:43 ` James Morris
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).