net: tcp: RST handling is weak

[pfalcon]

RFC793 has a repeating closes like:

If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.

(p.36 of https://tools.ietf.org/html/rfc793)

Zephyr's net_tcp_prepare_reset() doesn't take a reference pkt from which it could extract ackno for the above. That means that it won't generate proper RST which would be accepted by a peer, which means that peer can remain confused for extended time about Zephyr's state. For example, if Zephyr and peer was connected, then Zephyr resets, and peer trying to send data on old connection, then Zephyr's RST won't be valid. That's of course if RST is generated by Zephyr at all - I have a feeling that we don't handle all RST cases.

[jukkar]

This is very old one thus closing. Can be re-opened if needed of course.

[pfalcon]

Very little improved, this is still pertinent.

[pfalcon]

This issue was filed against TCP1 implementation, while TCP2 has become default and TCP1 removed. Closing.