baddata

It is obvious that when we get a bad header (as indicated by an XOR check
failure) we can't just junk it and look for the next header.  We can junk
the first character, but then we have to rescan the rest for another
ctl-P.  The reason is that the corrupt header might be partly (but only
partly) line noise, so the ctl-P denoting the start of the next real header 
might be found within the six characters. 

It is less obvious that when we get a bad data packet -- and this includes
not only data packets with bad checksums, but also out-of-window and duplicate
data packets -- that we must similarly rescan the data segment of the packet
looking for an imbedded header.  I originally thought that, since the
xor on the data header passed, we can trust the K field, so it's okay to
skip the data segment (typically 64 bytes) and resume looking for the next
packet after that.  But...

Suppose the file being received is a copy, obtained from a line analyzer,
of just one direction of a uucp data transfer.  If we pay no attention to
what's inside the data segments we see this (assuming 32-byte data segments,
K = 1):

	HHHHHH DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD HHHHHH DDDD...

but since the data contains a uucp packet stream, the data fields contain

	HHHHHH DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD HHHHHH DDDDDDDD....
               ddddhhhhhhdddddddddddddddddddddd        ddddddddddhhhhhh
                                                       
	1          2	                        3          4     5

Now, suppose that the header at 1 gets corrupted in transmission, so the
XOR check fails.  Fine, we junk it and start looking for another ctl-P, 
and we find the "imbedded header" at 2.  It passes xor, so we interpret 
it as a data header, and read the next 32 characters.  If it happens to 
be the right packet number it'll fail on checksum, but more likely it's 
the wrong packet number; whatever, we queue a NAK to tell the sender what 
we want, and resume scanning.  We find the ctl-P at 3...and we're back in 
sync.  

If instead we had said "bad data segment, skip 32 characters" we'd
be looking for the next header starting at 4.  We'd then find the next 
imbedded header at 5.... we'd eventually get back in sync, but it might
take a LONG time!