Re: PATCH: fix iBFT firmware reading with newer kernels
On 28 Jan 2009 at 22:49, 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.
Hi!
I have almost no ideas on the implementation, but please see my comments:
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);
What do you thing you gain by using strncat(dev_dir, /net, FILENAMESZ);
instead of strcat(dev_dir, /net);?
+
+ 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);
What is too bug? too long?
+ break;
+ }
+
+ strcpy(context-iface, dent-d_name);
+ rc = 0;
+ break;
+ }
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: PATCH: do not use exit()
On 28 Jan 2009 at 22:51, Hans de Goede wrote:
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.
Hi!
Let me comment on this:
if (errno != EEXIST) {
+ log_error(Maybe you are not root?);
In case of an error, don't try to spewculate, but give details (i.e. errno)
instead. Would something be wrong with using strerror(errno) here?
Also, for a library when returning error codes, there is no need to print
messages
(unless there is a generic error reporting framework that can be customized).
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: PATCH: fix iBFT firmware reading with newer kernels
On Thu, Jan 29, 2009 at 12:34 AM, Mike Christie micha...@cs.wisc.edu wrote: strncat(dev_dir, /, FILENAMESZ); strncat(dev_dir, dent-d_name, FILENAMESZ); I assume the third argument should have been FILENAMESZ - strlen(dev_dir) ? Bart. --~--~-~--~~~---~--~~ 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: Filesystem corruption using iser transport
On 29 Jan 2009 at 0:32, Dr. Volker Jaenisch wrote: 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. Hi! Well if you thing the problem is transport related, and you are doing performance evaluation anyway, you could try to use iozone: I think it has a checksumming/verification feature. Maybe this helps to reveal the problems. Maybe even, write your own code (e.g. write some long piece of data to a partition directly (using no file system), then read it back and compare it byte-by-byte. Many years ago my brother had a PC that worked fine when reading data slowly from a data disc, or when the CPU cache (external at that time) was disabled, but when the CPU chache was on and a huge amount of data was read using an Adaptec 2940, the last four bytes of a transfer were corrupted. Meaning: It could be a hardware issue. Maybe update any firmware to the latest before re-trying. 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: PATCH: fix iBFT firmware reading with newer kernels
On 28 Jan 2009 at 17:34, Mike Christie wrote: strncat(dev_dir, dent-d_name, FILENAMESZ); Hi, once again: The third argument of strncpy() counts the bytes to be added, not the bytes that are already there, so the code may not do what some of you seem to expect! The alternatives are ugly to implement, like this: d = snprintf(cp, cap, %s, string_of_unknown_lenght); #ifdef C99_LIBRARY if ( d cap ) d = cap; #else if ( d 0 ) #endif cp += d, cap -= d; (cp being the write position, cap the remaining capacity) 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
Hi Mike thanks for your reply. My answers follow bellow right next to your questions. Tkx/Regards, PECastro 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 Initially I did iscsiadm -m discovery -t sendtargets -p 10.238.17.201 And I started the iscsi daemon, from there after it all just worked. 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. But I do an ifconfig on the loopback interface adding a new IP on a virtual lo:0 I'm not messing with the original IP 10.238.17.201 which is still associated with eth0 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. Coul you explain me how I would be able to achieve that?! How do I create a session to the new IP? Perform a another discovery ? How can I use multipath between the two sessions?! 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- 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
Hi Ulrich, My response follows bellow On Jan 29, 7:11 am, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: 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. I don't think I understand what you mean... This is my routing table whilst having iscsi working correctly and before I set up the virtual IP. Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.238.17.128 0.0.0.0 255.255.255.128 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 10.238.17.254 0.0.0.0 UG0 0 0 eth0 And this is after I create the virtual IP agains lo:0 [r...@vmbox1 ~]# ifconfig lo:0 10.238.17.220 netmask 255.255.255.128 broadcast 10.238.17.255 up [r...@vmbox1 ~]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.238.17.128 0.0.0.0 255.255.255.128 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 10.238.17.254 0.0.0.0 UG0 0 0 eth0 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?!- 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
Hi! Your output (if complete) looks quite strange, because I see no routes to lo. Also If lines were not wrapped, it would be easier to read. Something I have here looks like this: # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.1.1 132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 192.53.103.104 132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 195.135.220.3 132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 63.76.115.39132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 213.31.172.75 132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 212.201.100.143 132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 132.199.1.15132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 195.135.220.8 132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 132.199.1.17132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 192.53.103.103 132.199.176.253 255.255.255.255 UGH 0 0 0 bond0 194.94.155.48 132.199.176.253 255.255.255.240 UG0 0 0 bond0 132.199.0.0 0.0.0.0 255.255.0.0 U 0 0 0 bond0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 132.199.207.6 0.0.0.0 UG0 0 0 bond0 (Note the route to lo). Regards, Ulrich On 29 Jan 2009 at 2:29, PECastro wrote: Hi Ulrich, My response follows bellow On Jan 29, 7:11 am, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: 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. I don't think I understand what you mean... This is my routing table whilst having iscsi working correctly and before I set up the virtual IP. Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.238.17.128 0.0.0.0 255.255.255.128 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 10.238.17.254 0.0.0.0 UG0 0 0 eth0 And this is after I create the virtual IP agains lo:0 [r...@vmbox1 ~]# ifconfig lo:0 10.238.17.220 netmask 255.255.255.128 broadcast 10.238.17.255 up [r...@vmbox1 ~]# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.238.17.128 0.0.0.0 255.255.255.128 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 10.238.17.254 0.0.0.0 UG0 0 0 eth0 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
Re: PATCH: do not use exit()
Ulrich Windl wrote:
On 28 Jan 2009 at 22:51, Hans de Goede wrote:
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.
Hi!
Let me comment on this:
if (errno != EEXIST) {
+ log_error(Maybe you are not root?);
In case of an error, don't try to spewculate, but give details (i.e. errno)
instead. Would something be wrong with using strerror(errno) here?
We do that in the next line logged, also note that this message was already
there, only the order of the 2 messages is being changed, so that libiscsi
(which saves the last log_error message) gives a reasonable error when this
happens.
Also, for a library when returning error codes, there is no need to print
messages
(unless there is a generic error reporting framework that can be customized).
This is not being printed, instead the last log_error message is kept in a
buffer for the application to retrieve when it wants something more verbose
then just strerror to show to the user.
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
-~--~~~~--~~--~--~---
Re: PATCH: fix iBFT firmware reading with newer kernels
Ulrich Windl wrote:
On 28 Jan 2009 at 22:49, 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.
Hi!
I have almost no ideas on the implementation, but please see my comments:
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);
What do you thing you gain by using strncat(dev_dir, /net, FILENAMESZ);
instead of strcat(dev_dir, /net);?
Nothing I copied this from the existing code, assuming (wrong) the existing
code was ok, which it is not. The idea is to protect against buffer overflows,
but using strncat this way will not accomplish this.
+
+ 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);
What is too bug? too long?
too big, another piece I copied and pasted.
Regards,
Hams
--~--~-~--~~~---~--~~
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
Bart Van Assche wrote: On Thu, Jan 29, 2009 at 12:34 AM, Mike Christie micha...@cs.wisc.edu wrote: strncat(dev_dir, /, FILENAMESZ); strncat(dev_dir, dent-d_name, FILENAMESZ); I assume the third argument should have been FILENAMESZ - strlen(dev_dir) ? Yes something like that, maybe just do a snprintf with all components in one go instead of all this strcat pain. 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 -~--~~~~--~~--~--~---
Re: PATCH: fix iBFT firmware reading with newer kernels
Ulrich Windl wrote: On 28 Jan 2009 at 17:34, Mike Christie wrote: strncat(dev_dir, dent-d_name, FILENAMESZ); Hi, once again: The third argument of strncpy() counts the bytes to be added, not the bytes that are already there, so the code may not do what some of you seem to expect! Ack, Copy and paste error, may I suggest to instead just do one snprintf call to build the entire path in one go? That removes all this pain. 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 -~--~~~~--~~--~--~---
Re: CHAP with Open-iSCSI
Ulrich Windl wrote: 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)? wireshark/ethereal. --~--~-~--~~~---~--~~ 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: 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? What version are you using? I noticed in git one way chap is broken. 870.1 works though. --~--~-~--~~~---~--~~ 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, This explains it. We are using: iscsid: transport class version 2.0-867. iscsid version 2.0-869 I will see how to upgrade it. We have patches for bidirectional and large CBDs. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Thursday, January 29, 2009 1:34 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI 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? What version are you using? I noticed in git one way chap is broken. 870.1 works though. --~--~-~--~~~---~--~~ 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, This explains it. We are using: iscsid: transport class version 2.0-867. iscsid version 2.0-869 No, this is fine. Newer tools support older kernels. That combo should work fine (all login is in userspace anyways so the kernel does not even come into play at this point). Let me do some more debugging and see what is up. I see one bug in the chap code right now. I will see how to upgrade it. We have patches for bidirectional and large CBDs. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Thursday, January 29, 2009 1:34 PM To: open-iscsi@googlegroups.com Subject: Re: CHAP with Open-iSCSI 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? What version are you using? I noticed in git one way chap is broken. 870.1 works though. --~--~-~--~~~---~--~~ 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: Mike, This explains it. We are using: iscsid: transport class version 2.0-867. iscsid version 2.0-869 No, this is fine. Newer tools support older kernels. That combo should work fine (all login is in userspace anyways so the kernel does not even come into play at this point). Let me do some more debugging and see what is up. I see one bug in the chap code right now. I fixed the problem I was hitting. It was only in git head and never in a open-iscsi.org release, so you probably would not have seen it. If you were using iscsid version 2.0-869 you would not have seen it. Let me do some more digging for your issue. --~--~-~--~~~---~--~~ 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: Yes it does the same thing, is this from the open-iscsi VCS ? and where do I find that ? Ok, I will merge up your code instead with the fixes in the thread. Thanks! It is in our git tree. You can get it by doing: git clone git://git.kernel.org/pub/scm/linux/kernel/git/mnc/open-iscsi.git If you do not have git and are using fedora, I think you can just do yum install git. --~--~-~--~~~---~--~~ 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
Mike Christie wrote:
Hans de Goede wrote:
Yes it does the same thing, is this from the open-iscsi VCS ? and where do I
find that ?
Ok, I will merge up your code instead with the fixes in the thread. Thanks!
Here is the rediffed patch. I used strncat here:
+ strncat(dev_dir, /net, FILENAMESZ - strlen(dev_dir))
and am going to replace it with strlcat when I move some code.
--~--~-~--~~~---~--~~
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 --git a/utils/fwparam_ibft/fwparam_ibft_sysfs.c
b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
index a79c1c6..3ce1b74 100644
--- a/utils/fwparam_ibft/fwparam_ibft_sysfs.c
+++ b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
@@ -103,33 +103,6 @@ static int get_iface_from_device(char *id, struct
boot_context *context)
rc = EINVAL;
rc = 0;
break;
- } 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 {
printf(Could not read ethernet to net link\n.);
rc = EOPNOTSUPP;
@@ -137,6 +110,40 @@ static int get_iface_from_device(char *id, struct
boot_context *context)
}
}
+ closedir(dirfd);
+
+ if (rc != ENODEV)
+ return rc;
+
+ /* If not found try again with newer kernel networkdev sysfs layout */
+ strncat(dev_dir, /net, FILENAMESZ - strlen(dev_dir));
+
+ 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 big for iface buffer.\n,
+ dent-d_name);
+ break;
+ }
+
+ strcpy(context-iface, dent-d_name);
+ rc = 0;
+ break;
+ }
+
+ closedir(dirfd);
+
return rc;
}
RE: CHAP with Open-iSCSI
Mike, Thanks for this excellent support. Let me know if I can do anything. I can send you wire shark trace with MS initiator oneway-CHAP if this will help. Thx, Arvind. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Thursday, January 29, 2009 3:08 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 It looks a normal old interop bug. It looks like the initiator and target do not agree what stage/phase we should be in. The initiator thinks you guys goof and the target thinks we should be continuing on with chap. I have not touched the login acl code in 6 years, so it will take me a bit to look over it and figure out who is wrong. --~--~-~--~~~---~--~~ 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
Mike, I tried to disable nops. But the issue still persists. So what else can be the reason for this? It became show stopper. Thanks Chava On Jan 28, 12:35 pm, Mike Christie micha...@cs.wisc.edu wrote: chava45wrote: 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,chava45ssch...@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 -- 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: iferror -38
Mike , What else could be the reason for it? it became showstopper. thanks Chava On Jan 28, 12:35 pm, Mike Christie micha...@cs.wisc.edu wrote: 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 -- 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: CHAP with Open-iSCSI
Arvind Jain wrote: Mike, Thanks for this excellent support. Let me know if I can do anything. I can send you wire shark trace with MS initiator oneway-CHAP if this will help. I do not need it yet. I think I can see where you guys differ from what I get with other targets. I just need to read the spec about what is correct. --~--~-~--~~~---~--~~ 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 , What else could be the reason for it? it became showstopper. What is the error you get now? Could you send the logs? If you see this: ping timeout of 5 secs expired then you do not have nops off. Could you also do a quick test with iet (it is the target used in open filer I think): http://iscsitarget.sourceforge.net/ I attached a ietd.conf that will export some virtual luns. Just install iet from the tarball, then copy the ietd.conf to /etc. Then do service iscsi-target start, and try to login again. thanks Chava On Jan 28, 12:35 pm, Mike Christie micha...@cs.wisc.edu wrote: 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 -- 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 -~--~~~~--~~--~--~--- # Example iscsi target configuration # # Everything until the first target definition belongs # to the global configuration. # Right now this is only the user configuration used # during discovery sessions. IncomingUser specifies credentials the # initiator has to provide - several of these are supported. If mutual # CHAP shall be employed, OutgoingUser specifies the user/pass # combination the target will provide - only one is supported. # Leave them alone (keep them commented out) if you don't want to use # authentication for discovery sessions. #iSNSServer 192.168.1.16 #iSNSAccessControl No #IncomingUser joe secret #OutgoingUser jack 12charsecret # Targets definitions
Re: PATCH: fix iBFT firmware reading with newer kernels
Mike Christie wrote: Mike Christie wrote: Hans de Goede wrote: Yes it does the same thing, is this from the open-iscsi VCS ? and where do I find that ? Ok, I will merge up your code instead with the fixes in the thread. Thanks! Here is the rediffed patch. I used strncat here: + strncat(dev_dir, /net, FILENAMESZ - strlen(dev_dir)) Looks good, Thanks, 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 -~--~~~~--~~--~--~---
