This is one issue split out from the overall OCI iSCSI issues bug PR259152. More detail is available on in comments 11 through 13 on PR259152. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259152#c11 A pcap demonstrating this issue is in an attachment on that PR, https://bugs.freebsd.org/bugzilla/attachment.cgi?id=228924 Summary of the specific issue here: In frame 15 we send a Login Command containing MaxRecvDataSegmentLength=262144. The response in frame 17 does not contain a MaxRecvDataSegmentLength. As a result we never update conn->conn_max_recv_data_segment_length in usr.sbin/iscsid/login.c login_negotiate_key(). In frame 189 we issue a read with ExpectedDataTransferLength: 0x00004000. The response is in frame 192 with DataSegmentLength 0x00004000. We then drop the connection with: WARNING: icl_conn_receive_pdu: received data segment length 16384 is larger than negotiated; dropping connection
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=fc79cf4fea7221fa62d480648f05e30f7df73f92 commit fc79cf4fea7221fa62d480648f05e30f7df73f92 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2021-10-21 15:09:58 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2021-10-25 20:25:15 +0000 iscsid: set max_recv_data_segment_length to what we advertise Previously we updated the conection's conn_max_recv_data_segment_length only when we received a response containing MaxRecvDataSegmentLength from the target. If the target did not send MaxRecvDataSegmentLength then we left conn_max_recv_data_segment_length at the default (i.e., 8192). A target could then send more data than that defult (up to our advertised maximum), and we would drop the connection. RFC 7143 specifies that MaxRecvDataSegmentLength is Declarative, not negotiated. Just set conn_max_recv_data_segment_length to our advertised value in login_negotiate(). PR: 259355 Reviewed by: mav MFC after: 1 week Fixes: a15fbc904a4d ("Alike to r312190 decouple iSCSI...") Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32605 usr.sbin/iscsid/login.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1da2deab7c2f195ea0e32878951833496f5a1a68 commit 1da2deab7c2f195ea0e32878951833496f5a1a68 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2021-10-21 15:09:58 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2021-11-03 20:47:11 +0000 iscsid: set max_recv_data_segment_length to what we advertise Previously we updated the conection's conn_max_recv_data_segment_length only when we received a response containing MaxRecvDataSegmentLength from the target. If the target did not send MaxRecvDataSegmentLength then we left conn_max_recv_data_segment_length at the default (i.e., 8192). A target could then send more data than that defult (up to our advertised maximum), and we would drop the connection. RFC 7143 specifies that MaxRecvDataSegmentLength is Declarative, not negotiated. Just set conn_max_recv_data_segment_length to our advertised value in login_negotiate(). PR: 259355 Reviewed by: mav MFC after: 1 week Fixes: a15fbc904a4d ("Alike to r312190 decouple iSCSI...") Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32605 (cherry picked from commit fc79cf4fea7221fa62d480648f05e30f7df73f92) usr.sbin/iscsid/login.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)