Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!bikini!manatee.cis.ufl.edu!esj
From: esj@manatee.cis.ufl.edu (Eric S. Johnson)
Newsgroups: comp.bugs.4bsd
Subject: What happens when someone says they want a TCP MSS=0?
Summary: In Berkeley 4.3+VJ TCP code
Message-ID: <20651@bikini.cis.ufl.EDU>
Date: 28 Jul 89 20:30:35 GMT
Sender: news@bikini.cis.ufl.EDU
Reply-To: esj@manatee.cis.ufl.edu (Eric S. Johnson)
Organization: UF CIS Department
Lines: 50


(BSD box below means any BSDish machine with the Van Jacobson
TCP routines posted to comp.bugs.4bsd.ucb-fixes last year)

We have a PC here which runs a TCP/IP package which comes from
a 3 letter company. When used to FTP to a BSD box, a get command
causes it to reply to the SYN (sent from BSD box) on FTP-DATA with
a SYN/ACK TCP packet with a option of MSS=0. To me this means the 
PC and its TCP/IP software is broken. 

But... BSD, upon receipt of this SYN/ACK, option MSS=0 packet, proceeds
to start sending continuous ACK packets, with no data (the third part of
the handshake). This continual ACKing will lock up the UNIX box in question,
and wreck havoc on gateways between PC and victim.

A quick look through tcp_output.c shows these code segments to be 
the *apparent* cause:

tcp_output(tp)
	register struct tcpcb *tp;
{
.
.
.
again:
	sendalot = 0;
.
.
.
	if (len > tp->t_maxseg) {
		len = tp->t_maxseg;
		sendalot = 1;
	}
.
.
.
	if (sendalot)
		goto again;
	return (0);
}


I am not a BSD TCP/IP wiz, but if len is >0 when some dopey PC has
requested a tcp mss=0, then packet flooding is what would be expected
from this code eh? Not terribly robust.

So, if I am misunderstanding the cause of the problem, please correct me.
And in any case, how do I fix it?

Ej