This will be used in future changes to support large text requests
spanning multiple PDUs.
Provide wrapper functions keys_load/save_pdu that operate use a PDU's
data buffer.
Reviewed by: mav
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D33547
Move some of the code duplicated between ctld(8) and iscsid(8) into a
libiscsiutil library.
Sharing the low-level PDU code did require having a
'struct connection' base class with a method table to permit separate
initiator vs target behavior (e.g. in handling proxy PDUs).
Reviewed by: mav, emaste
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D33544
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: a15fbc904a ("Alike to r312190 decouple iSCSI...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32605
Foundation copyrights, approved by emaste@. It does not include
files which carry other people's copyrights; if you're one
of those people, feel free to make similar change.
Reviewed by: emaste, imp, gbe (manpages)
Differential Revision: https://reviews.freebsd.org/D26980
It does not change anything immediately, but allows further support of
Command Priority, Status Qualifier and new task management functions.
MFC after: 1 month
Sponsored by: iXsystems, Inc.
the wrong length to strlcpy(3). It looks like it could overflow into
the next field, isc_user, which is properly long to accomodate for it;
I don't think it could cause any harm other than breaking the connection.
Reviewed by: mav
MFC after: 2 weeks
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D26247
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
No functional change intended.
Connection parameters should remain at defaults until negotiated.
While there, remove sythetic limits, applied if kernel provided none.
iscsid has no own limitations, no configuration and no any idea what
values are good. Assume kernel knows what it requests.
Decouple the send and receive limits on the amount of data in a single
iSCSI PDU. MaxRecvDataSegmentLength is declarative, not negotiated, and
is direction-specific so there is no reason for both ends to limit
themselves to the same min(initiator, target) value in both directions.
Allow iSCSI drivers to report their send, receive, first burst, and max
burst limits explicitly instead of using hardcoded values or trying to
derive all of them from the receive limit (which was the only limit
reported by the drivers prior to this change).
Display the send and receive limits separately in the userspace iSCSI
utilities.
Reviewed by: jpaetzel@ (earlier version), trasz@
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7279
rework might be needed to support asymetrical limits, but this should be
ok for now.
Obtained from: Mellanox Technologies (earlier version)
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
initiator iSCSI offload. Pass maximum data segment size supported by
chosen offload module to iscsid(8), and make iscsid(8) not try to negotiate
anything larger than that.
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
While we don't support MCS, hole in received sequence numbers may mean
only PDU loss. While we don't support lost PDU recovery, terminate the
connection to avoid stuck commands.
While there, improve handling of sequence numbers wrap after 2^32 PDUs.
MFC after: 2 weeks
if we got a Login Response PDU without the "T" bit set, try again with
an empty request. This fixes interoperability with COMSTAR.
Reviewed by: mav@
Tested by: mav@
MFC after: 1 week
Previously ISID was changed every time, that made impossible correct
persistent reservation, because reconnected session was identified as
completely new one.
Reviewed by: trasz
MFC after: 1 week
fix for LIO (Linux target), removing possibility for the target to avoid mutual
CHAP by choosing to skip authentication altogether, and fixing truncated error
messages in iscsictl(8) output. This also fixes several of the problems found
with Coverity.
Note that this change requires world rebuild.
Coverity CID: 1088038, 1087998, 1087990, 1088004, 1088044, 1088041, 1088040
Approved by: re (blanket)
Sponsored by: FreeBSD Foundation
