tdh@frog.UUCP (T. Dave Hudson) (10/17/90)
This seems to be a previously unpublished bug.
(Do 4.3BSD TCP/IP bugs belong in comp.bugs.4bsd.ucb-fixes instead?)
We are using the following base revisions of 4.3BSD TCP/IP source
modules:
@(#)tcp_input.c 7.15.1.3 (Berkeley) 2/15/89
@(#)tcp_output.c 7.13.1.4 (Berkeley) 2/15/89
When a user program (which I did not write) does
1) socket(PF_INET, SOCK_STREAM, 0)
2) bind() {PF_INET, port=3000, INADDR_ANY}
3) connect() {PF_INET, port=3000, local host's IP address}
the kernel goes into an infinite "loop" (dump indicates many ACKs but
little data in tcpstats) presumably scheduling SYN/ACK (and possibly
something else; dump only showed last message) messages to and from
presumably the same tcpcb. The tcpcb is in SYN SENT state, with
tcp_output() called from the dropafterack section of tcp_input(), and
with tcp_output() having successfully sent a message, contents unknown
except that the last freed mbuf, appropriately, is SYN/ACK with both
ports equal to 3000 and using the local node's Ethernet interface's IP
address. The SYN/ACK message contains an ISN that disagrees (having
been incremented) with the tcpcb's idea of it, but an acknowledgement
number that (matching the SYN/ACK's ISN, properly incremented from
the tcpcb's ISN) is OK.
I suspect that a workable fix is to use the tcpcb's ISN when sending
any SYN, although I haven't tried this yet. However, the failure to
do this ought to have generated a RST, IMHO, so I guess there are
actually two bugs here.
Has anyone already worked out a fix for this? (I will summarize
responses received by email. My guess is that it will be another
month or two before I can spend time working out a fix myself.)
David Hudsonsubbu@hpindda.cup.hp.com (MCV Subramaniam) (10/18/90)
>This seems to be a previously unpublished bug. Yes, it is unpublished, but not unreported. We, at HP have found this bug in 4.3 BSD, and have submitted a fix to Mike Karels. You may not believe it, but 4.3 BSD cannot handle crossing SYNs! (i.e. if two 4.3 machines send SYN to each other and they cross each other, the machines will go in an infinite loop sending SYN|ACKs to each other). Connecting to the same port number causes a similar situation to happen. You send a SYN and go into SYN_SENT state, and you receive the SYN while in SYN_SENT state! The fix involves handling a SYN correctly while in the SYN_SENT state. >I suspect that a workable fix is to use the tcpcb's ISN when sending >any SYN, although I haven't tried this yet. However, the failure to >do this ought to have generated a RST, IMHO, so I guess there are >actually two bugs here. The ISN is already used while sending a SYN. -Subbu