Core-iSCSI v1.6.2.4 has been released with the following changes:
v1.6.2.3 -> v1.6.2.4
1) Added initial code for Wasabi mutual authentication fix
2) Added first wave of sendpage() bits (currently disabled)
3) Updated default parameter settings
4) Fixed CHANNEL rescanning bug
5) Fixed result is minimum/maximum for numerical parameters from Section
12 of RFC 3720
6) Other various minor fixes
Note that I was trying to get sendpage() production ready for this
release, but have been encountering problems on 32-bit highmem machines.
I did not want to wait on this release any longer, but with some luck
another release will be along in a few days after this last sendpage()
related bug is squashed and the releated is validated.
The source tarball can be located at:
http://www.kernel.org/pub/linux/kernel/people/nab/iscsi-initiator-core/core-iscsi-v1.6.2.4.tar.bz2
On a related note, the Core-iSCSI & http://linux-iscsi.org team has been
working hard on the core-iscsi/boot project, and will be updating the
Core-iSCSI boot howto, as well as some other very interesting bits.
Please stay tuned and check the process at:
http://www.linux-iscsi.org/index.php/Main_Page
Thanks!
--
Nicholas A. Bellinger <n...@kernel.org>
first tests this morning I found that the authentication with the
Wasabi target (mutual auth) still does not work.
When I have the time this evening I'll produce a ethereal trace for
you.
Albert
/etc/sysconfig/initiator (only relevant part, rest is default):
CHANNEL="0 1 eth2 10.0.0.1 3260 0
AuthMethod=CHAP;MaxRecvDataSegmentLength=8192 nopout_timeout=5
iqn.2000-05.com.wasabisystems.storagebuilder:cyan-0"
/etc/sysconfig/initiator_auth:
AUTH="0 1 iscsi thepassword00 iscsi_in iscsi_in1234"
ethereal shows that an iSCSI Login command is given to the target,
The Key/Value pairs given (by the initiator) are:
AuthMethod=CHAP
InitiatorName=iqn.2005-12. ...... (etc)
InitiatorAlias=PyX Initiator
SessionType=Discovery
The target responds with an iSCSI Response (Success), and the value
pair:
AuthMethod=CHAP
And that's it, the abovementioned intiator/target response is repeated,
but no CHAP secrets are exchanged.
Albert
Note that the changeset that sent into v1.6.2.4 was only the driver
required stuff to distinguish between discovery/normal sessions during
the login process that eventually gets passed to the authentication
daemon (ie: core-iscsi-tools).
I did some work on the tools part after the original thread, but have
not had the chance to complete this as of yet. Please still feel free
to send the updated packet capture however. :-)
Thanks!
--
Nicholas A. Bellinger <n...@kernel.org>
The initiator asks for login with the following Key/Value pairs:
nitiatorName=....
InitiatorAlias=....
TargetName=....
SessionType=Normal
AuthMethod=CHAP
The target responds:
AuthMethod=CHAP
TargetPortalGroupTag=1
The initiator continues:
CHAP_A=5
The target replies:
CHAP_N=iscsi_in
CHAP_R=....
>From now on the normal session parameters are exchanged.
As far as I can see core-iscsi first does a SessionType=Discovery but
never gets out of that loop. Frankly, I noticed that even the Microsoft
initiator can't do a discovery with the authentication set.
Isn't it an option to avoid discovery when the authentication
(especially mutual authentication) is set?
Albert
> I compared the open-iscsi login phase with core-iscsi (given above).
> Here is the open-iscsi sequence:
>
> The initiator asks for login with the following Key/Value pairs:
>
> nitiatorName=....
> InitiatorAlias=....
> TargetName=....
> SessionType=Normal
> AuthMethod=CHAP
>
> The target responds:
>
> AuthMethod=CHAP
> TargetPortalGroupTag=1
>
> The initiator continues:
>
> CHAP_A=5
>
> The target replies:
>
> CHAP_N=iscsi_in
> CHAP_R=....
I think something is missing from your trace. Like one packet going
each direction.
The offer of CHAP_A is supposed to be followed by a response for
CHAP_A (=5) and an offer of CHAP_C and CHAP_I.
You can't get a CHAP_R without a CHAP_C and CHAP_I.
Take care,
Bill
I will be able to take a look at this again soon. Note that
core-iscsi/initiator_authd.c needs to use auth_t->session_type and
perform only perform the server side authentication when mutual
authentication is enabled. Feel free to hack on this code and I will
add a channel attrib to make this happen.
Thanks!
--
Nicholas A. Bellinger <n...@kernel.org>
I'll wait for your solution.
Thanks,
Albert