TCP Close Ignore data in RST segments. error

[hakehuang]

Describe the bug
Ignore data in RST segments. test is Fail on Zephyr3.0.0 on qemu_x86

References

RFC 1122: section 4.2.2.12 {RST can contain data}

Results

FAIL: tcp.v4 got echo response, which is not an expected result.

Environment (please complete the following information):

• OS: (e.g. Linux )
• Toolchain (e.g Zephyr SDK)
• Commit SHA or Version used: Zephyr3.0.0

[hakehuang]

Also fails on qemu_x86 for Zephyr3.0.0

[rlubos]

@hakehuang Can you provide a Wireshark pcap for this one, I'd like to see what's going on. Also, it's not clear to me what is the expected pass scenario for this test? Currently we just drop the RST packet and abort the connection. The linked RFC is also not clear about the RST segment containing data:

         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.

[hakehuang]

Uploading tcp_close_ignore_data_in_rst.zip…
@rlubos please check the attached pcap

[rlubos]

Uploading tcp_close_ignore_data_in_rst.zip… @rlubos please check the attached pcap

It seems that the file did not upload properly?

[hakehuang]

tcp_close_ignore_data_in_rst.zip
reupload, @rlubos

[rlubos]

Hmm, so the logs from Wireshark doesn't seem to follow the issue description:

FAIL: tcp.v4 got echo response, which is not an expected result.

There is not reply from DUT in the logs. It's still not clear to me what is the cultprit of the failure here. One idea is that perhaps Zephyr should reply with ICMP Destination Unreachable in this case, but I'm not sure if that's the core problem here.

[hakehuang]

looks like after server sends the close package, the DUT does not reply close status.

[ssharks]

I thinks this test tries to validate the following section from the metioned RFC:

      fourth other text or control

        Any other control or text-bearing segment (not containing SYN)
        must have an ACK and thus would be discarded by the ACK
        processing.  An incoming RST segment could not be valid, since
        it could not have been sent in response to anything sent by this
        incarnation of the connection.  So you are unlikely to get here,
        but if you do, drop the segment, and return.