Some tests may cause a target to drop the session.
For these tests we DO want the test tool to detect that the command
failed and later reconnect the session again when we proceed to the next subtest
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
For writes that span across multiple DATA-OUT segments we have to
increment the DATASN field for each segment.
We didnt use to, and most targets were perfectly happy, ignoring that the DATASN was constant 0 for every DATAOUT we sent.
LIO however does check this and did cause it to reject the libiscsi test tool.
(This is something we should write a iscsi test for so we can flag all non-LIO targets as broken and needing to be fixed)
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
in that case we will never reach test unit ready being successful since it will fail with NOT_READY/MEDIUM_NOT_PRESENT.
Treat this sense code as a successful login as far as the login process is concerned
Harmonize the signatures for READ10/WRITE10 to match the ones for READ12/16 and WRITE12/16
This breaks the API/ABI so this forces the next version of the library to bump the major version to 2.0
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
If the login phase takes multiple login requests we should keep the ITT the same for all login requets and not increment it.
A multi-phase login is only a single task eventhough it may be spread across multiple login requetst.
While most targets are forgiving and still work if we increment the ITT for each login command, some targets such as SOLARIS/COMSTAR is NOT forgiving if we break the protocol in this situation.
Fix the ITT handling so that we dont make SOLARIS/COMSTAR upset.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Set only the (socket) options which are defined on a given platform.
The function becomes a no-op if no option is known at complie time.
Remove autoconf test for HAVE_TCP_KEEPALIVE too.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
no data to read from the socket and there is no error.
For this case, if FIONREAD tells us that there are 0 bytes to read, check if
there is a socket error and return ok/error based on that.
Some eventsystems may cause this to burn some cpu if the socket is ok
but there are no bytes available to read by invoking POLLIN over and over, but it is better than failing the application.
