: > This should be easy to fix.
:
: I.e., we should fix the summary line to list the ack only if
: ACK is set?
I think it would be nicer if both header line and content tree were
consistent.
: I don't see anything obvious in RFC 793 to indicate that the
: Acknowledgment field is meaningful if ACK isn't set, regardless of
: whether RST is set or not. RFC 793 says:
:
: Acknowledgment Number: 32 bits
:
: If the ACK control bit is set this field contains the
: value of the
: next sequence number the sender of the segment is expecting to
: receive. Once a connection is established this is always sent.
:
: Later, under "Reset Generation", it says:
:
: 2. If the connection is in any non-synchronized state (LISTEN,
: SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
: something not yet sent (the segment carries an
: unacceptable ACK), or
: if an incoming segment has a security level or compartment which
: does not exactly match the level and compartment
: requested for the
: connection, a reset is sent.
:
Since both Sequence Number and Acknowledgement Number are mandatory in TCP,
why not always include them in the tree, possibly with a note telling they
are not relevant if required. It is true that the value of the
Acknowledgement Number is meaningless when ACK is not set, but it's still in
and many TCP implementations will write a meaningful value anyhow although
the TCP protocol does not mandate this.
: ...
:
: 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.
: The connection remains in the same state.
:
: Presumably in the "otherwise" case, the reset has both RST
: and ACK set.
:
FYI, the example TCP stream looks like:
>>> SYN
<<< SYN, ACK
>>> ACK
>>> PSH, ACK
<<< ACK
<<< FIN, PSH, ACK
>>> ACK
>>> RST
Regards,
Olivier