Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!UTAH-CS.ARPA!cetron
From: cetron@UTAH-CS.ARPA (Edward J Cetron)
Newsgroups: mod.protocols.tcp-ip
Subject: Ultrix 1.2 and unacceptable tcp packets
Message-ID: <8609152123.AA19278@utah-cs.ARPA>
Date: Mon, 15-Sep-86 17:23:12 EDT
Article-I.D.: utah-cs.8609152123.AA19278
Posted: Mon Sep 15 17:23:12 1986
Date-Received: Tue, 16-Sep-86 09:18:13 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: utah-cs!cetron (Edward J Cetron)
Organization: Center for Engineering Design, Univ of Utah
Lines: 27
Approved: tcp-ip@sri-nic.arpa

After hacking with the Tek tcp/ip package to add keep-alive (or probe-alive
as the case may be) support, I found the following behaviour from two Ultrix
sites:

	line sits idle for x length of time (so snd.nxt = snd.una = Ultrix
		rcv.nxt...)
	Tek tcp/ip sends a packet designed to be unacceptable in order to force
		a response (as documented in the mil-std and rfc for tcp). This
		packet has   seg.seq = snd.nxt-1   and   seg.ack = rcv.nxt-1
		which is obviously unacceptable and should force and ack with
		the proper counters.

	The Ultrix site receives the packet, and promptly drops it off of the
		face of the earth (though apparently reading the code it does
		use it to update the window...)

Am I missing something or is this indeed non-compliant?  All of the 4.2bsd and
4.3 bsd sites handle this fine...  I know what is different between the 4.3bsd
and the Ultrix code but before I fix it myself, I want to be sure I haven't 
overlooked something and/or that other Ultrix sites have noticed this same 
problem....

		thanx

			ed

cetron%utah-cbd@utah-cs.arpa