TCP: No RST response to segments with some strange flag combinations

[maartenvds]

When you send a segment (non SYN) to a listening port, pico will respond with a RST (expected behaviour).

RFC 793 - Section 3.4 Establishing a Connection p36:
If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except 
another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.

For some flag combinations, this is not the case. Segments with the following flags will not produce any response:

• no flags
• PSH
• PSH|FIN
• URG
• URG|PSH
• URG|PSH|FIN

For some segments, pico should respond with RST and for some, it should respond with RST|ACK. The algorithm is like this:

 RFC 793 - Section 3.9. Event Processing p65:
 If the state is CLOSED (i.e., TCB does not exist) then

  all data in the incoming segment is discarded.  An incoming
  segment containing a RST is discarded.  An incoming segment not
  containing a RST causes a RST to be sent in response.  The
  acknowledgment and sequence field values are selected to make the
  reset sequence acceptable to the TCP that sent the offending
  segment.
  If the ACK bit is off, sequence number zero is used,
    <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
  If the ACK bit is on,
    <SEQ=SEG.ACK><CTL=RST>
  Return.

We should expect RST when the segment contains an ACK flag, we should expect RST|ACK we no ACK flag was set!

Reproduce: sudo ./run.sh --test responsefromclosedsocket testcases/hardware/tcp_connect_bench_dut.txt

[bibireiulian]

Implemented a TCP flags check mechanism using a new matrix containing all valid flag combinations for each TCP state. "response from closed socket" robot framework test and Linux autotest passed.

[toonst]

No RST is received. Introduced somewhere between 19 Feb, 9h46 and 20 Feb, 9h41.