On Tue, Nov 27, 2007 at 09:14:49AM -0600, Jay Nelson wrote:
> On Tue, Nov 27, 2007 at 10:43:31AM +0000, Alistair Crooks wrote:
> > On Mon, Nov 26, 2007 at 05:29:55PM -0600, Jay Nelson wrote:
> > > I'm trying to configure a sparc64 4.99.37 initiator to mount an
> > > i386 4.0_RC3 target without much luck. I can't get past authentication
> > > and I'm hoping someone can point me to what I'm doing wrong.
> > > 
> > > Log messages start with:
> > > 
> > > No matching user configuration entry for `jdn' was found
> > > Please add an entry for `jdn' to `/etc/iscsi/auths'
> > > pid 3175:/usr/src/dist/iscsi/src/parameters.c:545: ***ERROR*** Unknown
> > > user `0x88ac594f7d6e0b2bce40fa0ecc29d60c'
> > > pid 3175:/usr/src/dist/iscsi/src/parameters.c:187: ***ERROR*** key
> > > "AuthResult" not found in param list
> > > pid 3175:/usr/src/dist/iscsi/src/initiator.c:1904: ***ERROR***
> > > param_text_parse_offer() failed
> > > 
> > > 
> > > yet /etc/iscsi/auths contains
> > > 
> > > 	jdn:none:
> > 
> > Change that line to be:
> > 
> > jdn:chap:none
> >  
> > and restart the target.
> > 
> > > and auths' permissions is 600 on both machines.
> > > 
> > > Initiator command is:
> > > 
> > > 	'iscsifs -u jdn -h acp /mnt'
> > > 
> > > What did I overlook?
> > 
> > Nothing except very weird syntax on the part of the iSCSI target.
> > One of the things on my TODO list is to clean this area up
> > entirely.
> 
> There is still no joy in Mudville. The initiator says:
> 
> sks# iscsifs -u jdn -h acp /iscsi
> pid 13232:/usr/src/dist/iscsi/src/initiator.c:1912: ***ERROR*** Bad Status-Class: got 2, expected 0
> Nov 27 08:45:53 sks iscsifs: pid 13232:/usr/src/dist/iscsi/src/initiator.c:1912: ***ERROR*** Bad Status-Class: got 2, expected 0 
> pid 13232:/usr/src/dist/iscsi/src/initiator.c:1737: ***ERROR*** initiator_cmd_t failed
> pid 13232:/usr/src/dist/iscsi/src/initiator.c:566: ***ERROR*** login_phase_i() failed
> Nov 27 08:45:53 sks iscsifs: pid 13232:/usr/src/dist/iscsi/src/initiator.c:1737: ***ERROR*** initiator_cmd_t failed 
> Nov 27 08:45:53 sks iscsifs: pid 13232:/usr/src/dist/iscsi/src/initiator.c:566: ***ERROR*** login_phase_i() failed 
> pid 13232:/usr/src/dist/iscsi/src/initiator.c:1084: ***ERROR*** enqueue_worker: discovery_phase() failed (ignoring command)
> Nov 27 08:45:53 sks iscsifs: pid 13232:/usr/src/dist/iscsi/src/initiator.c:1084: ***ERROR*** enqueue_worker: discovery_phase() failed (ignoring command)
> 
> And on the target:
> 
> Nov 27 08:49:49 acp iscsi-target: pid 751:/usr/src/dist/iscsi/src/parameters.c:648: ***ERROR*** Initiator authentication failed 79 1d 
> Nov 27 08:49:49 acp iscsi-target: pid 751:/usr/src/dist/iscsi/src/target.c:1087: ***ERROR*** login_command_t() failed 
> Nov 27 08:49:49 acp iscsi-target: pid 751:/usr/src/dist/iscsi/src/target.c:1207: ***ERROR*** execute_t() failed

The good news is that the target has recognised the user name in the
/etc/iscsi/auths file (which is read when it starts up), since the
error message has changed from:

> Please add an entry for `jdn' to `/etc/iscsi/auths' pid 3175:/usr/src/dist/iscsi/src/parameters.c:545: ***ERROR*** Unknown user `0x88ac594f7d6e0b2bce40fa0ecc29d60c'

to

> Nov 27 08:49:49 acp iscsi-target: pid 751:/usr/src/dist/iscsi/src/parameters.c:648: ***ERROR*** Initiator authentication failed 79 1d

That error message comes when the CHAP data returned by the initiator,
and the original data that we asked them to encode with their password
do not agree.

This should not happen. 

You have the same /etc/iscsi/auths information on the initiator and
target?

If so, I notice that the initiator is running on a different, LP64,
Big Endian machine.

It's not a combination I've tried, and we may either have some LP64
problems, or we may have some endian issues.
 
> The only change to the distributed examples are:
> 
> in /etc/iscsi/targets -- a name change to extent0,
> 
> extent0                 /home/iscsi-sks0        0               100MB
> 
> and the addition of "chap" to the passwd,
> 
> jdn:chap:none
> 
> I tried an ending colon and no colon on the passwd and 777 on the
> extent to no avail. Permissions on /etc/iscsi are 755 on both
> systems. Also, kernel config contains:
> 
> sks# config -x /netbsd | egrep -i 'pu[tf]'
> file-system PUFFS       # Pass to userspace filesystem
> pseudo-device putter
> 
> Can't think of anything else.

We're getting far enough for these to not be a problem. If the initiator
machine didn't have puffs or putter, the communication wouldn't be showing
up at the target.

Similarily, the permissions on the files in /etc/iscsi should not matter,
except for the fact that people may be able to misuse it - I'm of the
opinion that chap is not security, but a form of authentication that is
not exactly secure, which is why I tend not to delve into this part of
the target much.

WRT the problem you're seeing, I'm inclined to look for some endian issues,
since I know of people running the target on amd64, so LP64 shouldn't be
a problem, and (famous last words) lint and gcc find a lot of the LP64
issues.

I'll have a further look, but would you be able to do any troubleshooting
for us?

Thanks,
Alistair