the check was not quite correct. iscsi->pending_reconnect can be true but
we are still connected (and thus can disconnect). This is the case when
we receive an async logout request.
Signed-off-by: Peter Lieven <pl@kamp.de>
if reconnect is disabled then a failure in iscsi_service_reconnect_if_loggedin
can leak back to the application by iscsi_service returning an error
but the error string is not being updated.
Thus the applucation will print the last prevous error message that was set.
Change iscsi_service_reconnect_if_loggedin to print a less confusing
error message.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
If we are reconnecting and the connection is already established we
end up looping forever if there is a socket error before we finish
the login process. Fix this by invoking the reconnect callback if
there is an error and no new reconnect is scheduled.
Signed-off-by: Peter Lieven <pl@kamp.de>
those are part of the login process to consume UNIT_ATTENTIONS.
Its questionable if we should consume them at all, but iff we change
that behaviour we should do it for the initial login as well as
for a reconnect.
Signed-off-by: Peter Lieven <pl@kamp.de>
Just ignore any iSCSI AsyncMsg / SCSI Async Events we receive instead of
reconnecting. We can't pass the data back to the application anyway
with the current API.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
this is meant as a hint that there can be no event at the moment
and in this special case iscsi_service will return immediately.
We use this at the moment in the case of a wait for a reconnect
in which case we would enter a busy loop waiting for that
reconnect. The 0 means do not poll for the client application.
Do not poll, just wait a little (a few hundred ms) and call iscsi_which_events
again. The wait should be timer driven or at least non busy looping,
of course.
Signed-off-by: Peter Lieven <pl@kamp.de>
RFC3720 10.13.4. states that the statsn should explicitly set with
the first Login Repsonse. In theory the target could choose a StatSN
that is not greater than iscsi->statsn (zero at start) in Serial32
arithmetic.
Signed-off-by: Peter Lieven <pl@kamp.de>
RFC3720 10.19. NOP-In
NOP-In is either sent by a target as a response to a NOP-Out, as a
"ping" to an initiator, or as a means to carry a changed ExpCmdSN
and/or MaxCmdSN if another PDU will not be available for a long time
(as determined by the target).
...
Signed-off-by: Peter Lieven <pl@kamp.de>
originally NOPs where used to detect failures in the transport
layer. This is e.g. implemented in qemu since a few years now.
Recently I found a few vServers with hanging I/O where
the NOP mechanism could not detect the error.
The reason is most likely due to a bug in the target,
however if NOPs increase the CmdSN this could help
to detect such failures. If there are requests hanging
and the OS stops I/O before CmdSN > MaxCmdSN we can currently
send NOPs forever and they might still be answered. If
a NOP increases the CmdSN we will enter a point where CmdSN
is greater than MaxCmdSN. This is, of course, not the ideal check,
but it might detect some types of errors. Ideally we would
send out a Test-Unit-Ready command with attr=ordered, but
that requires a new API and/or modification of the tool
that uses libiscsi. This here comes with no modification for
the userspace.
Signed-off-by: Peter Lieven <pl@kamp.de>
iscsi-ls show luns command does not work when the target redirects at login.
to avoid redundant code allow iscsi_full_connect_async to skip the testunit ready
part.
Signed-off-by: Peter Lieven <pl@kamp.de>
We allowed iscsi to be NULL in iscsi_parse_url. Especially
qemu does this and currently segfaults at start. Change the
usage guidelines for target username/password to be the same
as for chap username/password.
Signed-off-by: Peter Lieven <pl@kamp.de>
Don't reset nalloc when resetting an iovector during reconnect.
Resetting offset/consumed should be sufficient.
Also, don't reset the iovectors when we detect an error condition in
iscsi_iovector_readv_writev. If there is a bug feeding an invalid
pos into this function, where pos suddently points before the amount
of data we have already read/written, then singlan this as an error
and return -EINVAL.
Previosly we did not reset the iovectors correctly when we re-queued
PDUs after a reconnect and thus relied on the iovectors being automatically
reset if/when we detected this type of error in readv_writev.
Now we do reset the iovectors properly so we do nt need to atuo reset them
here anymore and we can change this check to test for and abort the transfer
if an error is detected.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
The only PDU type that does not have ISCSI_PDU_DROP_ON_RECONNECT is the
SCSI COMMAND PDU. Thsi is the only PDU that we re-queue on reconnect.
All other, including DATA-OUT, NOP, task management, PDUs are simply
dropped.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
This is a bug that has been there a long time.
When we reconnect and requeue a PDU we must reset the iovectors
for the task. Otherwise, any partially sent/received data when the
command is reconnected would end up containing garbage.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
