TCP/IP Testing help, Round 2 - Done!

[Michael B. Brutman]

John R. wrote:

> What do you mean by "allowable RST?" RST can be thought of as
> hard-close, or "Sorry peer, I don't have any context about the
> connection you sent a packet for," or "this port is not accepting
> connections."
> 
> It is always allowed. It is not the ideal way to close a connection,
> but as a peer receiving it you must always handle it, and you may send
> it if you have a good reason.
> 
> Some consideration may be given to detecting spoofed RSTs attempting
> to interfere with valid connections. But I suspect you are not
> terribly interested in complicating your code with such corner case at
> this point (there are a lot of things like this if you really want to
> get into it).


There are lots of rules in RFC 793 for RST segment generation and handling.

You don't want to just whack any connection that gets an RST.  The RST 
has to have correct sequence and ack numbers in the header.  Correct can 
be extended to mean 'in the allowable window'.  Otherwise, somebody can 
have some real fun with your server by just spraying random RST segments 
at you.

I code my RST handling code such that the RST has to be within the 
current receive window, which is how I read 793.  I think I have misread 
or misinterpreted, and I should include RST packets that are in my 
window of previously sent (but not yet acknowledged) packets.


Corner cases are an interesting design problem.  I could make the code 
quite a bit smaller if I just tweaked the spec a bit.  Things like not 
supporting two sides to do active opens at each other can save code, and 
it is not a commonly used feature.  I might go back and start sprinkling 
my code with #defines to delete features like that if they are not needed.