Core-iSCSI v1.6.2.4

2 views
Skip to first unread message

Nicholas A. Bellinger

unread,
Mar 12, 2006, 10:55:41 PM3/12/06
to Core-iSCSI, iet-dev
Greetings all,

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>

Albert Pauw

unread,
Mar 13, 2006, 6:01:45 AM3/13/06
to Core-iSCSI
Hi Nicholas,

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

Albert Pauw

unread,
Mar 13, 2006, 1:12:10 PM3/13/06
to Core-iSCSI
Ok, here's what I have:

/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

Nicholas A. Bellinger

unread,
Mar 13, 2006, 1:46:18 PM3/13/06
to Core-iSCSI
Hi 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>

Albert Pauw

unread,
Mar 13, 2006, 1:52:29 PM3/13/06
to Core-...@googlegroups.com
Hi Nicholas,

here is the ethereal trace of a non-succesful login.

Albert

core-iscsi.ethereal

Albert Pauw

unread,
Mar 16, 2006, 3:46:41 AM3/16/06
to Core-iSCSI
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=....

>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

William Studenmund

unread,
Mar 16, 2006, 4:13:55 PM3/16/06
to Core-...@googlegroups.com
On Mar 16, 2006, at 12:46 AM, Albert Pauw wrote:

> 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

Nicholas A. Bellinger

unread,
Mar 20, 2006, 12:06:15 AM3/20/06
to Core-iSCSI
Greeting Albert,

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>

Albert Pauw

unread,
Mar 23, 2006, 1:52:24 AM3/23/06
to Core-iSCSI
Hi Nicholas,

I'll wait for your solution.

Thanks,

Albert

Reply all
Reply to author
Forward
0 new messages