I do not know if it is in accordance with the specification or not but I have traces
containig data in the RST segment. Maybe, it some bug in the vxWorks TCP implementation.
I will try to reproduce it with Linux.
Guy Harris wrote:
Tomas Kukosa said:
When abortive close is used and there are some data in outgoing buffer.
Then data and RST flag are sent together in one IP packet.
RFC 1122 says:
4.2.2.12 RST Segment: RFC-793 Section 3.4
A TCP SHOULD allow a received RST segment to include data.
DISCUSSION
It has been suggested that a RST segment could contain
ASCII text that encoded and explained the cause of the
RST. No standard has yet been established for such
data.
and gives no more details of how the data in an RST segment are to be
interpreted.
Abortive closes are presumably described by
Abort
Format: ABORT (local connection name)
This command causes all pending SENDs and RECEIVES to be
aborted, the TCB to be removed, and a special RESET message to
be sent to the TCP on the other side of the connection.
Depending on the implementation, users may receive abort
indications for each outstanding SEND or RECEIVE, or may simply
receive an ABORT-acknowledgment.
in section 3.8 of RFC 793, and section 3.9 says:
ABORT Call
...
SYN-RECEIVED STATE
ESTABLISHED STATE
FIN-WAIT-1 STATE
FIN-WAIT-2 STATE
CLOSE-WAIT STATE
Send a reset segment:
<SEQ=SND.NXT><CTL=RST>
All queued SENDs and RECEIVEs should be given "connection reset"
notification; all segments queued for transmission (except for the
RST formed above) or retransmission should be flushed, delete the
TCB, enter CLOSED state, and return.
and, when describing how to handle an RST in ESTABLISHED state:
If the RST bit is set then, any outstanding RECEIVEs and SEND
should receive "reset" responses. All segment queues should be
flushed. Users should also receive an unsolicited general
"connection reset" signal. Enter the CLOSED state, delete the
TCB, and return.
which seems to indicate that data in the RST segment shouldn't be supplied
to the user.
So why would a TCP implementation send data with an RST segment *other*
than to supply, for example, the sort of out-of-band data RFC 1122 is
talking about (other than laziness, i.e. not clearing out the data from a
segment once it decides to turn send a RST in that segment)?
Is the idea to deliver some data that was intended to be sent before the
RST? If so, at least as I read RFC 793, that data won't get delivered to
the user on the remote side, as the RST processing clause above appears
before the "process the segment data" clause.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
