CHAP with Open-iSCSI
Hi Mike, We are using Open iSCSI initiator with our iSCSI target. I have a question on CHAP. I did some experiment and it appears to me that OneWay-CHAP does not work with open-iscsi, Mutual-CHAP does work fine for me. Have others seen the same behavior? Thx, Arvind. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: CHAP with Open-iSCSI
Mike Christie wrote: Arvind Jain wrote: Hi Mike, We are using Open iSCSI initiator with our iSCSI target. I have a question on CHAP. I did some experiment and it appears to me that OneWay-CHAP does not work with open-iscsi, Mutual-CHAP does work fine for me. Have others seen the same behavior? Not really. I have the opposite. I have seen a report where Mutual-CHAP does not work, but OneWay-CHAP works fine with LSI targets. Mutual-CHAP or OneWay-CHAP works fine with IET, Netapp and Equallogic Actually not sure about Equallogic. I think we just tested one way. I am not sure if we tested 2 way. and some box you probably never heard of here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
RE: CHAP with Open-iSCSI
Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed BTW, Microsoft initiator works fine with OneWay-CHAP and Mutual-CHAP with our target. So I think it something subtle. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, January 28, 2009 1:25 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Mike Christie wrote: Arvind Jain wrote: Hi Mike, We are using Open iSCSI initiator with our iSCSI target. I have a question on CHAP. I did some experiment and it appears to me that OneWay-CHAP does not work with open-iscsi, Mutual-CHAP does work fine for me. Have others seen the same behavior? Not really. I have the opposite. I have seen a report where Mutual-CHAP does not work, but OneWay-CHAP works fine with LSI targets. Mutual-CHAP or OneWay-CHAP works fine with IET, Netapp and Equallogic Actually not sure about Equallogic. I think we just tested one way. I am not sure if we tested 2 way. and some box you probably never heard of here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~--- open_iscsi_MutualCHAP.pcap Description: Binary data open_iscsi_OnewayCHAP.pcap Description: Binary data
Re: iferror -38
Mike , Can you also let me know if there is any workaround on this issue? On Jan 28, 10:42 am, chava45 ssch...@gmail.com wrote: Mike , In response to the following update by you... --- Either you are hitting the bug I thought I fixed or these nops are really timing out. I am downloading open filer now to test it out here. ------ Could you let me know once you test it? I am stuck up here and can not move forward with Oracle RAC installation on Oracle VM. Thanks Chava On Jan 28, 9:35 am, Mike Christie micha...@cs.wisc.edu wrote: chava45wrote: Mike, Here is the log information from /var/log/messages. ---- Jan 27 14:02:04 rac1 iscsid: iSCSI logger with pid=4380 started! Jan 27 14:02:05 rac1 iscsid: transport class version 2.0-724. iscsid version 2.0-868 Jan 27 14:02:05 rac1 iscsid: iSCSI daemon with pid=4381 started! Jan 27 14:03:02 rac1 kernel: scsi1 : iSCSI Initiator over TCP/IP Jan 27 14:03:03 rac1 kernel: Vendor: OPNFILER Model: VIRTUAL- DISK Rev: 0 Jan 27 14:03:03 rac1 kernel: Type: Direct- Access ANSI SCSI revision: 04 Jan 27 14:03:03 rac1 kernel: SCSI device sda: 1048576 512-byte hdwr sectors (537 MB) Jan 27 14:03:03 rac1 kernel: sda: Write Protect is off Jan 27 14:03:03 rac1 kernel: SCSI device sda: drive cache: write through Jan 27 14:03:03 rac1 kernel: SCSI device sda: 1048576 512-byte hdwr sectors (537 MB) Jan 27 14:03:03 rac1 kernel: sda: Write Protect is off Jan 27 14:03:03 rac1 kernel: SCSI device sda: drive cache: write through Jan 27 14:03:03 rac1 iscsid: received iferror -38 Jan 27 14:03:03 rac1 last message repeated 2 times Jan 27 14:03:03 rac1 iscsid: connection2:0 is operational now Jan 27 14:03:06 rac1 udevd-event[4401]: wait_for_sysfs: waiting for '/ sys/devices/platform/host1/session2/target1:0:0/1:0:0:0/ioerr_cnt' failed Jan 27 14:03:13 rac1 kernel: sda:3ping timeout of 5 secs expired, last rx 47558, last ping 48808, now 50058 Either you are hitting the bug I thought I fixed or these nops are really timing out. I am downloading open filer now to test it out here.- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
loopback interface IP problem
Hi there. I'm mounting a standard iscsi target. I've been doing a lot of interesting nice things, I can see the disk, I can play with it and everything is very wonderfull ! :) Long story short, the disk has been running fine as if it was really attached. The problem started when I had the need to configure a virtual IP on lo:0 . My client box IP is something like 10.238.17.221 and I was trying to configure a 10.238.17.220 IP on lo:0 with ifconfig lo:0 10.238.17.220 netmask 255.255.255.128 broadcast 10.238.17.255 up but the moment I do this I seem to lose connection to the disk whilst iscsi is throwing errors to the log. Jan 28 19:00:34 vmbox kernel: connection1:0: iscsi: detected conn error (1011) Jan 28 19:00:34 vmbox iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) Jan 28 19:00:37 vmbox iscsid: connect failed (111) Jan 28 19:01:08 vmbox last message repeated 8 times Whilst trying to dd the disk I also got this Jan 28 19:02:34 vmbox last message repeated 6 times Jan 28 19:02:34 vmbox kernel: session1: iscsi: session recovery timed out after 120 secs Jan 28 19:02:34 vmbox kernel: iscsi: cmd 0x28 is not queued (8) Jan 28 19:02:34 vmbox kernel: sd 1:0:0:0: SCSI error: return code = 0x0001 Jan 28 19:02:34 vmbox kernel: end_request: I/O error, dev sdb, sector 0 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 0 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 1 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 2 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 3 Jan 28 19:02:34 vmbox kernel: iscsi: cmd 0x28 is not queued (8) Jan 28 19:02:34 vmbox kernel: sd 1:0:0:0: SCSI error: return code = 0x0001 Jan 28 19:02:34 vmbox kernel: end_request: I/O error, dev sdb, sector 0 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 0 Jan 28 19:02:37 vmbox iscsid: connect failed (111) Jan 28 19:03:11 vmbox last message repeated 9 times I hacked the init.d start file so that iscsid would start with the maximum verbosity of 8. The version I'm currently working with is from the RPM iscsi-initiator- utils-6.2.0.868-0.7.el5 bundled for CENTOS. Can any one reproduce this problem or even better can anyone explain why is this happening and if there's a way of getting away with this?! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: CHAP with Open-iSCSI
Arvind Jain wrote: Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed Could you give me the output of iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 And could you run iscsid by hand with debugging and give me that output when you try to login # iscsid -d 8 -f will print it out to the console. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: iferror -38
chava45 wrote: Mike , Can you also let me know if there is any workaround on this issue? Yeah, if this is the bug I thought I fixed then you can just turn off nops. Are you using dm-multipath? They are mostly useful for fast failovers when using multipath. You can turn them off by setting node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 in /etc/iscsi/iscsid.conf, then redoing the discovery command (iscsiadm -m discovery -t st -p ip). Or you can set this for already setup nodes by doing iscsiadm -m node -o update -n node.conn[0].timeo.noop_out_interval -v 0 iscsiadm -m node -o update -n node.conn[0].timeo.noop_out_timeout -v 0 (note if you do this you still want to set it in iscsid.conf so new targets that are discovered will get the new setting). On Jan 28, 10:42 am, chava45 ssch...@gmail.com wrote: Mike , In response to the following update by you... --- Either you are hitting the bug I thought I fixed or these nops are really timing out. I am downloading open filer now to test it out here. ------ Could you let me know once you test it? I am stuck up here and can not move forward with Oracle RAC installation on Oracle VM. Thanks Chava On Jan 28, 9:35 am, Mike Christie micha...@cs.wisc.edu wrote: chava45wrote: Mike, Here is the log information from /var/log/messages. ---- Jan 27 14:02:04 rac1 iscsid: iSCSI logger with pid=4380 started! Jan 27 14:02:05 rac1 iscsid: transport class version 2.0-724. iscsid version 2.0-868 Jan 27 14:02:05 rac1 iscsid: iSCSI daemon with pid=4381 started! Jan 27 14:03:02 rac1 kernel: scsi1 : iSCSI Initiator over TCP/IP Jan 27 14:03:03 rac1 kernel: Vendor: OPNFILER Model: VIRTUAL- DISK Rev: 0 Jan 27 14:03:03 rac1 kernel: Type: Direct- Access ANSI SCSI revision: 04 Jan 27 14:03:03 rac1 kernel: SCSI device sda: 1048576 512-byte hdwr sectors (537 MB) Jan 27 14:03:03 rac1 kernel: sda: Write Protect is off Jan 27 14:03:03 rac1 kernel: SCSI device sda: drive cache: write through Jan 27 14:03:03 rac1 kernel: SCSI device sda: 1048576 512-byte hdwr sectors (537 MB) Jan 27 14:03:03 rac1 kernel: sda: Write Protect is off Jan 27 14:03:03 rac1 kernel: SCSI device sda: drive cache: write through Jan 27 14:03:03 rac1 iscsid: received iferror -38 Jan 27 14:03:03 rac1 last message repeated 2 times Jan 27 14:03:03 rac1 iscsid: connection2:0 is operational now Jan 27 14:03:06 rac1 udevd-event[4401]: wait_for_sysfs: waiting for '/ sys/devices/platform/host1/session2/target1:0:0/1:0:0:0/ioerr_cnt' failed Jan 27 14:03:13 rac1 kernel: sda:3ping timeout of 5 secs expired, last rx 47558, last ping 48808, now 50058 Either you are hitting the bug I thought I fixed or these nops are really timing out. I am downloading open filer now to test it out here.- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: loopback interface IP problem
PECastro wrote: Hi there. I'm mounting a standard iscsi target. I've been doing a lot of interesting nice things, I can see the disk, I can play with it and everything is very wonderfull ! :) Long story short, the disk has been running fine as if it was really attached. The problem started when I had the need to configure a virtual IP on lo:0 . My client box IP is something like 10.238.17.221 and I was trying to configure a 10.238.17.220 IP on lo:0 with ifconfig lo:0 10.238.17.220 netmask 255.255.255.128 broadcast 10.238.17.255 up but the moment I do this I seem to lose connection to the disk whilst iscsi is throwing errors to the log. So you do the ifconfig to lo after iscsi is setup and logged in right? Is the ip address different from what you originally logged into? I mean originally you did iscsiadm -m node -T some_tagret -p original_ip -l then when you do the ifconfig it is a new_ip, but the iscsi tools think you want to still connect to original_ip so you get the connect failed errors and eventually the replacement/recovery timeout errors. What you would have to do is create a session to original_ip, then create a new session to new_ip, and if you do not want to see IO errors then you would use dm-multipath over both sessions and that would handle switching from the old path to the new path for you. Jan 28 19:00:34 vmbox kernel: connection1:0: iscsi: detected conn error (1011) Jan 28 19:00:34 vmbox iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) Jan 28 19:00:37 vmbox iscsid: connect failed (111) Jan 28 19:01:08 vmbox last message repeated 8 times --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
PATCH: fix iBFT firmware reading with newer kernels
Hi,
While testing I noticed that iscsiadmin -m fw does not work properly on newer
(rawhide atleast) kernels, the attached patch (already applied to the Fedora
devel packages) fixes this.
Regards,
Hans
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
diff -up open-iscsi-2.0-870.1/utils/fwparam_ibft/fwparam_ibft_sysfs.c~
open-iscsi-2.0-870.1/utils/fwparam_ibft/fwparam_ibft_sysfs.c
--- open-iscsi-2.0-870.1/utils/fwparam_ibft/fwparam_ibft_sysfs.c~
2009-01-28 22:09:21.0 +0100
+++ open-iscsi-2.0-870.1/utils/fwparam_ibft/fwparam_ibft_sysfs.c
2009-01-28 22:10:29.0 +0100
@@ -186,6 +186,40 @@ static int get_iface_from_device(const c
break;
}
+ closedir(dirfd);
+
+ if (rc != ENODEV)
+ return rc;
+
+ /* If not found try again with newer kernel networkdev sysfs layout */
+ strncat(dev_dir, /net, FILENAMESZ);
+
+ if (!file_exist(dev_dir))
+ return rc;
+
+ dirfd = opendir(dev_dir);
+ if (!dirfd)
+ return errno;
+
+ while ((dent = readdir(dirfd))) {
+ if (!strcmp(dent-d_name, .) || !strcmp(dent-d_name, ..))
+ continue;
+
+ /* Take the first regular directory entry */
+ if (strlen(dent-d_name) (sizeof(context-iface) - 1)) {
+ rc = EINVAL;
+ printf(Net device %s too bug for iface buffer.\n,
+ dent-d_name);
+ break;
+ }
+
+ strcpy(context-iface, dent-d_name);
+ rc = 0;
+ break;
+ }
+
+ closedir(dirfd);
+
return rc;
}
PATCH: do not use exit()
Hi All,
While testing I noticed that idbm_lock() uses exit when it cannot lock, leading
to interesting effect when using it from libiscsi, when typing import
libiscsi in python as normal user, my entire python interpreter exited, not
good.
The attached patch instead returns an error code, and fixes all callers to
check this.
Regards,
Hans
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
--- open-iscsi-2.0-870.1/usr/idbm.c~2009-01-28 13:23:47.0 +0100
+++ open-iscsi-2.0-870.1/usr/idbm.c 2009-01-28 13:25:06.0 +0100
@@ -843,7 +843,7 @@ int idbm_lock(void)
if (access(LOCK_DIR, F_OK) != 0) {
if (mkdir(LOCK_DIR, 0660) != 0) {
log_error(Could not open %s. Exiting\n, LOCK_DIR);
- exit(-1);
+ return errno;
}
}
@@ -857,10 +857,10 @@ int idbm_lock(void)
break;
if (errno != EEXIST) {
+ log_error(Maybe you are not root?);
log_error(Could not lock discovery DB: %s: %s,
LOCK_WRITE_FILE, strerror(errno));
- log_error(Maybe you are not root?);
- exit(-1);
+ return errno;
} else if (i == 0)
log_debug(2, Waiting for discovery DB lock);
@@ -915,7 +915,10 @@ static int __idbm_rec_read(node_rec_t *o
if (!info)
return ENOMEM;
- idbm_lock();
+ rc = idbm_lock();
+ if (rc)
+ goto free_info;
+
f = fopen(conf, r);
if (!f) {
log_debug(5, Could not open %s err %d\n, conf, errno);
@@ -931,6 +934,7 @@ static int __idbm_rec_read(node_rec_t *o
unlock:
idbm_unlock();
+free_info:
free(info);
return rc;
}
@@ -1386,14 +1390,18 @@ idbm_discovery_read(discovery_rec_t *out
return ENOMEM;
portal = malloc(PATH_MAX);
- if (!portal)
+ if (!portal) {
+ rc = ENOMEM;
goto free_info;
+ }
snprintf(portal, PATH_MAX, %s/%s,%d, ST_CONFIG_DIR,
addr, port);
log_debug(5, Looking for config file %s\n, portal);
- idbm_lock();
+ rc = idbm_lock();
+ if (rc)
+ goto free_info;
f = idbm_open_rec_r(portal, ST_CONFIG_NAME);
if (!f) {
@@ -1494,7 +1502,9 @@ static int idbm_rec_write(node_rec_t *re
rec-name, rec-conn[0].address, rec-conn[0].port);
log_debug(5, Looking for config file %s, portal);
- idbm_lock();
+ rc = idbm_lock();
+ if (rc)
+ goto free_portal;
rc = stat(portal, statb);
if (rc) {
@@ -1579,13 +1589,16 @@ idbm_discovery_write(discovery_rec_t *re
return ENOMEM;
}
- idbm_lock();
+ rc = idbm_lock();
+ if (rc)
+ goto free_portal;
+
snprintf(portal, PATH_MAX, %s, ST_CONFIG_DIR);
if (access(portal, F_OK) != 0) {
if (mkdir(portal, 0660) != 0) {
log_error(Could not make %s\n, portal);
rc = errno;
- goto free_portal;
+ goto unlock;
}
}
@@ -1596,13 +1609,14 @@ idbm_discovery_write(discovery_rec_t *re
if (!f) {
log_error(Could not open %s err %d\n, portal, errno);
rc = errno;
- goto free_portal;
+ goto unlock;
}
idbm_print(IDBM_PRINT_TYPE_DISCOVERY, rec, 1, f);
fclose(f);
-free_portal:
+unlock:
idbm_unlock();
+free_portal:
free(portal);
return rc;
}
@@ -1722,7 +1736,10 @@ int idbm_add_node(node_rec_t *newrec, di
log_debug(7, node addition making link from %s to %s, node_portal,
disc_portal);
- idbm_lock();
+ rc = idbm_lock();
+ if (rc)
+ goto free_portal;
+
if (symlink(node_portal, disc_portal)) {
if (errno == EEXIST)
log_debug(7, link from %s to %s exists, node_portal,
@@ -2009,7 +2026,10 @@ static int idbm_remove_disc_to_node_link
if (rc)
goto done;
- idbm_lock();
+ rc = idbm_lock();
+ if (rc)
+ goto done;
+
if (!stat(portal, statb)) {
if (unlink(portal)) {
log_error(Could not remove link %s err %d\n,
@@ -2046,7 +2066,10 @@ int
Filesystem corruption using iser transport
Hello Open-IScsi-Group! We use infiniband for our storage backend. Recently we managed to get iscsi-over ISER to work with stgtd 0.9.3 (build from tgz) and open-iscsi 2.0.870 (Debian package) on Debian Lenny. Running tiotest we get impressive performance but also filesystem corruption [45343.062563] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659479 [45343.071480] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659480 [45343.080868] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659481 [45343.152037] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659482 [45343.164261] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659483 [45343.184682] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659484 [45343.195180] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659485 [45343.201188] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659486 [45343.212957] EXT2-fs error (device sdc): ext2_free_blocks: bit already cleared for block 659487 The error is 100% reproduceble. We got this with ext2 and also ext3 filesystems. But we get this with ISER-Transport, only. If we use the tcp-Transport we have no error at all. So we think this has nothing to do with the underlying harddisc hardware nor the filesystem. We think the ISER transport may be the problem. Has anybody an idea? Google says not much to that issue. How may we debug further? Best regards Volker -- inqbus it-consulting +49 ( 341 ) 5643800 Dr. Volker Jaenisch http://www.inqbus.de Herloßsohnstr.12 0 4 1 5 5Leipzig N O T - F Ä L L E +49 ( 170 ) 3113748 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: PATCH: fix iBFT firmware reading with newer kernels
Hans de Goede wrote:
Hi,
While testing I noticed that iscsiadmin -m fw does not work properly on
newer
(rawhide atleast) kernels, the attached patch (already applied to the Fedora
devel packages) fixes this.
Did you port this from another file/version?
Not sure what I was thinking when I put it in the while loop above the
code you are adding but in fwparam_ibft_sysfs.c we have
get_iface_from_device doing this:
} else if (!strncmp(dent-d_name, net, 3)) {
DIR *net_dirfd;
struct dirent *net_dent;
strncat(dev_dir, /, FILENAMESZ);
strncat(dev_dir, dent-d_name, FILENAMESZ);
net_dirfd = opendir(dev_dir);
if (!net_dirfd) {
printf(Could not open net path %s.\n,
dev_dir);
rc = errno;
break;
}
while ((net_dent = readdir(net_dirfd))) {
if (!strcmp(net_dent-d_name, .) ||
!strcmp(net_dent-d_name, ..))
continue;
strncpy(context-iface, net_dent-d_name,
sizeof(context-iface));
break;
}
closedir(net_dirfd);
rc = 0;
break;
} else {
which I think does the same thing you are doing right (again not sure
why I put it in a loop instead of just opening the net dir directly)?
If it is the same I will just remove the part in the loop since I have
no idea why I did that, and just merge the patch. Do not worry about
resending. I can just do it when I merge it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
RE: CHAP with Open-iSCSI
Mike, I have the following info as you requested: [r...@localhost ~]# iscsid -d 8 -f iscsid: sysfs_init: sysfs_path='/sys' iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: add to cache '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: cache '/sys/module/scsi_transport_iscsi/version' with attribute value '2.0-867' iscsid: transport class version 2.0-867. iscsid version 2.0-869 iscsid: in ctldev_open iscsid: created NETLINK_ISCSI socket... iscsid: InitiatorName==iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorName=iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorAlias=localhost.localdomain iscsid: in ctldev_close iscsid: Max file limits 1024 1024 iscsid: reaped pid 3625, reap_count now 0 [r...@localhost ~]# iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 node.name = iqn.2008-07.com.wasabi:osd.1 node.tpgt = -1 node.startup = manual iface.hwaddress = default iface.iscsi_ifacename = default iface.net_ifacename = default iface.transport_name = tcp iface.initiatorname = empty node.discovery_address = 192.168.0.90 node.discovery_port = 3260 node.discovery_type = send_targets node.session.initial_cmdsn = 0 node.session.initial_login_retry_max = 4 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.auth.authmethod = CHAP node.session.auth.username = user0 node.session.auth.password = node.session.auth.username_in = empty node.session.auth.password_in = empty node.session.timeo.replacement_timeout = 120 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.err_timeo.host_reset_timeout = 60 node.session.iscsi.FastAbort = Yes node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = No node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.session.iscsi.DefaultTime2Retain = 0 node.session.iscsi.DefaultTime2Wait = 2 node.session.iscsi.MaxConnections = 1 node.session.iscsi.MaxOutstandingR2T = 1 node.session.iscsi.ERL = 0 node.conn[0].address = 192.168.0.90 node.conn[0].port = 3260 node.conn[0].startup = manual node.conn[0].tcp.window_size = 524288 node.conn[0].tcp.type_of_service = 0 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.auth_timeout = 45 node.conn[0].timeo.noop_out_interval = 30 node.conn[0].timeo.noop_out_timeout = 30 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 node.conn[0].iscsi.HeaderDigest = None node.conn[0].iscsi.DataDigest = None node.conn[0].iscsi.IFMarker = No node.conn[0].iscsi.OFMarker = No [r...@localhost ~]# The above info is with the Oneway-CHAP. Let me know if you need any other info. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, January 28, 2009 3:31 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Arvind Jain wrote: Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed Could you give me the output of iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 And could you run iscsid by hand with debugging and give me that output when you try to login # iscsid -d 8 -f will print it out to the console. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
RE: CHAP with Open-iSCSI
Oops, forgot to attach the login debug info using iscsid -d 8 -f last time. Debug output attached for oneway-CHAP and Mutual-CHAP. Mutual-CHAP works fine with our target. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Arvind Jain Sent: Wednesday, January 28, 2009 8:43 PM To: open-iscsi@googlegroups.com Subject: RE: CHAP with Open-iSCSI Mike, I have the following info as you requested: [r...@localhost ~]# iscsid -d 8 -f iscsid: sysfs_init: sysfs_path='/sys' iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: add to cache '/sys/module/scsi_transport_iscsi/version' iscsid: sysfs_attr_get_value: cache '/sys/module/scsi_transport_iscsi/version' with attribute value '2.0-867' iscsid: transport class version 2.0-867. iscsid version 2.0-869 iscsid: in ctldev_open iscsid: created NETLINK_ISCSI socket... iscsid: InitiatorName==iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorName=iqn.2005-03.org.open-iscsi:1bd5bc7d3378 iscsid: InitiatorAlias=localhost.localdomain iscsid: in ctldev_close iscsid: Max file limits 1024 1024 iscsid: reaped pid 3625, reap_count now 0 [r...@localhost ~]# iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 node.name = iqn.2008-07.com.wasabi:osd.1 node.tpgt = -1 node.startup = manual iface.hwaddress = default iface.iscsi_ifacename = default iface.net_ifacename = default iface.transport_name = tcp iface.initiatorname = empty node.discovery_address = 192.168.0.90 node.discovery_port = 3260 node.discovery_type = send_targets node.session.initial_cmdsn = 0 node.session.initial_login_retry_max = 4 node.session.cmds_max = 128 node.session.queue_depth = 32 node.session.auth.authmethod = CHAP node.session.auth.username = user0 node.session.auth.password = node.session.auth.username_in = empty node.session.auth.password_in = empty node.session.timeo.replacement_timeout = 120 node.session.err_timeo.abort_timeout = 15 node.session.err_timeo.lu_reset_timeout = 20 node.session.err_timeo.host_reset_timeout = 60 node.session.iscsi.FastAbort = Yes node.session.iscsi.InitialR2T = No node.session.iscsi.ImmediateData = No node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 node.session.iscsi.DefaultTime2Retain = 0 node.session.iscsi.DefaultTime2Wait = 2 node.session.iscsi.MaxConnections = 1 node.session.iscsi.MaxOutstandingR2T = 1 node.session.iscsi.ERL = 0 node.conn[0].address = 192.168.0.90 node.conn[0].port = 3260 node.conn[0].startup = manual node.conn[0].tcp.window_size = 524288 node.conn[0].tcp.type_of_service = 0 node.conn[0].timeo.logout_timeout = 15 node.conn[0].timeo.login_timeout = 15 node.conn[0].timeo.auth_timeout = 45 node.conn[0].timeo.noop_out_interval = 30 node.conn[0].timeo.noop_out_timeout = 30 node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 node.conn[0].iscsi.HeaderDigest = None node.conn[0].iscsi.DataDigest = None node.conn[0].iscsi.IFMarker = No node.conn[0].iscsi.OFMarker = No [r...@localhost ~]# The above info is with the Oneway-CHAP. Let me know if you need any other info. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, January 28, 2009 3:31 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI Arvind Jain wrote: Mike, I have attached the wire shark trace for OneWay-CHAP and Mutual-CHAP. I am not sure how helpful this is. In case of OneWay-CHAP, Open-iscsi initiator does not continues with the login step and gives and error as follows: Logging in to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260] iscsiadm: Could not login to [iface: default, target: iqn.2008-07.com.wasabi:osd.1, portal: 192.168.0.90,3260]: iscsiadm: initiator reported error (5 - encountered iSCSI login failure) Target discovery or login failed Could you give me the output of iscsiadm -m node -T iqn.2008-07.com.wasabi:osd.1 -p 192.168.0.90,3260 And could you run iscsid by hand with debugging and give me that output when you try to login # iscsid -d 8 -f will print it out to the console. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~--- [r...@localhost ~]# iscsid -d 8 -f iscsid: sysfs_init: sysfs_path='/sys' iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version' iscsid: sysfs_attr_get_value: new uncached
Re: CHAP with Open-iSCSI
On 28 Jan 2009 at 12:06, Mike Christie wrote: Arvind Jain wrote: Hi Mike, We are using Open iSCSI initiator with our iSCSI target. I have a question on CHAP. I did some experiment and it appears to me that OneWay-CHAP does not work with open-iscsi, Mutual-CHAP does work fine for me. Have others seen the same behavior? Not really. I have the opposite. I have seen a report where Mutual-CHAP does not work, but OneWay-CHAP works fine with LSI targets. Hi! This brings up the basic question: How to debug/trace CHAP (assuming you have an installation using precompiled software)? Regards, Ulrich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: loopback interface IP problem
On 28 Jan 2009 at 11:06, PECastro wrote: Hi there. I'm mounting a standard iscsi target. I've been doing a lot of interesting nice things, I can see the disk, I can play with it and everything is very wonderfull ! :) Long story short, the disk has been running fine as if it was really attached. The problem started when I had the need to configure a virtual IP on lo:0 . My client box IP is something like 10.238.17.221 and I was trying to configure a 10.238.17.220 IP on lo:0 with ifconfig lo:0 10.238.17.220 netmask 255.255.255.128 broadcast 10.238.17.255 up Hi! I'd suggest running netstat -rn, and I assume the kernel will route your net via lo now. Regards, Ulrich but the moment I do this I seem to lose connection to the disk whilst iscsi is throwing errors to the log. Jan 28 19:00:34 vmbox kernel: connection1:0: iscsi: detected conn error (1011) Jan 28 19:00:34 vmbox iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) Jan 28 19:00:37 vmbox iscsid: connect failed (111) Jan 28 19:01:08 vmbox last message repeated 8 times Whilst trying to dd the disk I also got this Jan 28 19:02:34 vmbox last message repeated 6 times Jan 28 19:02:34 vmbox kernel: session1: iscsi: session recovery timed out after 120 secs Jan 28 19:02:34 vmbox kernel: iscsi: cmd 0x28 is not queued (8) Jan 28 19:02:34 vmbox kernel: sd 1:0:0:0: SCSI error: return code = 0x0001 Jan 28 19:02:34 vmbox kernel: end_request: I/O error, dev sdb, sector 0 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 0 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 1 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 2 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 3 Jan 28 19:02:34 vmbox kernel: iscsi: cmd 0x28 is not queued (8) Jan 28 19:02:34 vmbox kernel: sd 1:0:0:0: SCSI error: return code = 0x0001 Jan 28 19:02:34 vmbox kernel: end_request: I/O error, dev sdb, sector 0 Jan 28 19:02:34 vmbox kernel: Buffer I/O error on device sdb, logical block 0 Jan 28 19:02:37 vmbox iscsid: connect failed (111) Jan 28 19:03:11 vmbox last message repeated 9 times I hacked the init.d start file so that iscsid would start with the maximum verbosity of 8. The version I'm currently working with is from the RPM iscsi-initiator- utils-6.2.0.868-0.7.el5 bundled for CENTOS. Can any one reproduce this problem or even better can anyone explain why is this happening and if there's a way of getting away with this?! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
