From: Wenhua Liu <liuw(a)vmware.com>
I’m testing our NVMe/TCP initiator for handling C2H_TERM_REQ (PDU type
0x3). In order to test it, I intentionally injected an error to a H2CData PDU by
modifying its data offset field DATAO to an invalid value. This error, if detected
by the target, will be treated as a fatal transport error with fatal error status FES
set to 4 (Data Transfer Out of Range).
When I tested this, I can see SPDK NVMe/TCP target can detect this error and
set the FES to value 4 as expected, but when sending C2H_TERM_REQ PDU, it
always fails with a message “IC_RESP or TERM_REQ could not write to socket.”,
then on host side, the initiator gets the error “Connection reset by peer” when
[2021-11-08 00:47:06.795739] tcp.c:1437:nvmf_tcp_h2c_data_hdr_handle:
*ERROR*: Queue 3, fes 4, offset 0
[2021-11-08 00:47:06.795879] tcp.c: 837:_tcp_write_pdu: *ERROR*: IC_RESP or
TERM_REQ could not write to socket.
What could be the problem here?
It seems like the target went down a code path that closed the socket prior to sending the
response, but I don't currently see which code path that would be. Can you file a
GitHub issue with all of the relevant information (version especially) so we can take a
look at DATAO errors more closely?