Re: Broadcom NIC sessions not retaining on reboot (node.startup=automatic not working)
On 11/06/2012 02:29 AM, vaibhav pol wrote: Hi set node.startup = manual in iscsid.conf then run iscsiadm to turn on specific portals by setting the --value/-v to automatic. Just wanted to add some more details. The iscsi/iscsid service does not go by the iscsid.conf settings alone. When you discovery/setup targets it uses those as the defaults for the records that get made. If you run iscsiadm -m node -T youtarget -p ip -I iface then you will see the settings that will get used for that specific records. If those also have automatic, then check that the iscsid and iscsi services are started at boot (in some distros it might be called open-iscsi). And to set settings for specific records run: iscsiadm -m node -T youtarget -p ip -I iface -o update -n nameofsetting -v newvalue Thanks and regards Vaibhav Pol Senior Technical Officer National PARAM Supercomputing Facility Centre for Development of Advanced Computing Ganeshkhind Road Pune University Campus PUNE-Maharastra Phone +91-20-25704176 ext: 176 Cell Phone : +919850466409 On Mon, Nov 5, 2012 at 1:46 PM, riva gupta riva7s...@gmail.com mailto:riva7s...@gmail.com wrote: Dear All I have connected my host and iSCSI storage directly with LAN cable. The iface created for the particular port through which the connection is made is: * iscsiadm -m iface -I bnx2i.3c:d9:2b:f5:2e:e7* # BEGIN RECORD 2.0-872 iface.iscsi_ifacename = bnx2i.3c:d9:2b:f5:2e:e7 iface.net_ifacename = empty iface.ipaddress = 192.168.3.20 iface.hwaddress = 3c:d9:2b:f5:2e:e7 iface.transport_name = bnx2i iface.initiatorname = empty # END RECORD I have successfully discovered the target using the command: *iscsiadm -m discovery -t st -p 192.168.3.14:3260 http://192.168.3.14:3260 -I bnx2i.3c:d9:2b:f5:2e:e7* And logged into my storage successfully as: *iscsiadm -m node -p 192.168.3.14:3260 http://192.168.3.14:3260 -I bnx2i.3c:d9:2b:f5:2e:e7 -l * I can then see my sessions successfully as: *iscsiadm -m session* bnx2i: [2] 192.168.3.14 tel:%5B2%5D%20192.168.3.14:3260,1 iqn.2001-03.jp.nec:storage01:ist-m000-sn-00090019.lx-hprhel6.target I have the setting *node.startup = automatic* in the file /etc/iscsi/iscsid.conf But on reboot I see: *iscsiadm -m session* iscsiadm: No active sessions. I think the node.startup=automatic is not working. Have any of you faced such a problem. Please help. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/iSgT7ktg3bMJ. To post to this group, send email to open-iscsi@googlegroups.com mailto:open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com mailto:open-iscsi%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- 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?hl=en. -- 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?hl=en.
Re: Broadcom NIC sessions not retaining on reboot (node.startup=automatic not working)
It is also possible that the corresponding nic interface is up on boot. It's worthwhile to make sure that the ONBOOT=yes is set inside that corresponding sysconfig network script. On Tue, 2012-11-06 at 03:00 -0600, Mike Christie wrote: On 11/06/2012 02:29 AM, vaibhav pol wrote: Hi set node.startup = manual in iscsid.conf then run iscsiadm to turn on specific portals by setting the --value/-v to automatic. Just wanted to add some more details. The iscsi/iscsid service does not go by the iscsid.conf settings alone. When you discovery/setup targets it uses those as the defaults for the records that get made. If you run iscsiadm -m node -T youtarget -p ip -I iface then you will see the settings that will get used for that specific records. If those also have automatic, then check that the iscsid and iscsi services are started at boot (in some distros it might be called open-iscsi). And to set settings for specific records run: iscsiadm -m node -T youtarget -p ip -I iface -o update -n nameofsetting -v newvalue Thanks and regards Vaibhav Pol Senior Technical Officer National PARAM Supercomputing Facility Centre for Development of Advanced Computing Ganeshkhind Road Pune University Campus PUNE-Maharastra Phone +91-20-25704176 ext: 176 Cell Phone : +919850466409 On Mon, Nov 5, 2012 at 1:46 PM, riva gupta riva7s...@gmail.com mailto:riva7s...@gmail.com wrote: Dear All I have connected my host and iSCSI storage directly with LAN cable. The iface created for the particular port through which the connection is made is: * iscsiadm -m iface -I bnx2i.3c:d9:2b:f5:2e:e7* # BEGIN RECORD 2.0-872 iface.iscsi_ifacename = bnx2i.3c:d9:2b:f5:2e:e7 iface.net_ifacename = empty iface.ipaddress = 192.168.3.20 iface.hwaddress = 3c:d9:2b:f5:2e:e7 iface.transport_name = bnx2i iface.initiatorname = empty # END RECORD I have successfully discovered the target using the command: *iscsiadm -m discovery -t st -p 192.168.3.14:3260 http://192.168.3.14:3260 -I bnx2i.3c:d9:2b:f5:2e:e7* And logged into my storage successfully as: *iscsiadm -m node -p 192.168.3.14:3260 http://192.168.3.14:3260 -I bnx2i.3c:d9:2b:f5:2e:e7 -l * I can then see my sessions successfully as: *iscsiadm -m session* bnx2i: [2] 192.168.3.14 tel:%5B2%5D%20192.168.3.14:3260,1 iqn.2001-03.jp.nec:storage01:ist-m000-sn-00090019.lx-hprhel6.target I have the setting *node.startup = automatic* in the file /etc/iscsi/iscsid.conf But on reboot I see: *iscsiadm -m session* iscsiadm: No active sessions. I think the node.startup=automatic is not working. Have any of you faced such a problem. Please help. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/iSgT7ktg3bMJ. To post to this group, send email to open-iscsi@googlegroups.com mailto:open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com mailto:open-iscsi%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- 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?hl=en. -- 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?hl=en.
no LUN 1/disk size
Hi Guys, I ran into something interesting, and I'm wondering if this can or should be fixed. I setup a second disk pointing to a partition on my drive, which already had another partition shared out using open-iscsi. I found out really quickly that no drives show up in Windows 7 computer management console, even though it's successful connecting. So, I ran tgtadm -m target -o show, and got the following... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: I_T nexus: 1 Initiator: iqn.1991-05.com.microsoft:tda-desktop Connection: 1 IP Address: 192.168.8.4 LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 Luckily, I thought about what the problem might be, seeing the first partition was working fine. The problem that occurred was that I had edited the disk partition table while tgtd was using the drive. Of course you get the standard message that a reboot is necessary. Instead of that, I shut down tgtd, opened the disk, and re-wrote the partition table. After restarting tgtd, the output of the above command is now... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00020001 SCSI SN: beaf21 Size: 268436 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /dev/sdf2 Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 So, I guess my question is, should this be considered a bug? Is there any way that open-iscsi can notify the client that the disk is not yet working? Thanks. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/LpfJCiBDURoJ. 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?hl=en.
Re: Antw: Re: Q: Slow extraordinarily slow performance of dmraid -s -c -c -c
It might be due to retrying what something (initiator or target) thinks is a bad IO. On 11/05/2012 06:47 AM, Ulrich Windl wrote: Hi! I have an update on the ioctl() takes 16 seconds issue: It seems (don't ask me for an explanation) if the buffer size for the SCSI response is too small (in my case less than 18 octets), the wsystemcall to read the SCSI serial number takes 15-16 seconds, while with a buffer of 18 octets or more, it takes 3ms (over an iSCSI-FC-Gateway). Maybe Mike finds this output of a test program useful: === buflen = 17 testprog /dev/sdu 17 SCSI cmd sent: 12 1 80 0 11 0 ioctl duration: 15976 msecs SCSI response: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 resplen = 17, pgcode = 0x 0, pglen = 0 /dev/sdu serial no: : real0m15.979s user0m0.000s sys 0m0.000s === buflen = 18 testprog /dev/sdu 18 SCSI cmd sent: 12 1 80 0 12 0 ioctl duration: 0 msecs SCSI response: 0 80 0 e 50 42 35 41 38 44 34 41 41 55 36 38 33 39 resplen = 18, pgcode = 0x80, pglen = 14 /dev/sdu serial no: PB5A8D4AAU6839 : real0m0.003s user0m0.000s sys 0m0.000s === Regards, Ulrich Ulrich Windl schrieb am 24.09.2012 um 08:57 in Nachricht 50600460.815 : 161 : 60728: Michael Christie micha...@cs.wisc.edu schrieb am 24.09.2012 um 04:46 in Nachricht 1f8fae71-ee7c-4785-a648-24758b18e...@cs.wisc.edu: From what I can tell, it is a dm raid issue or a target issue. The len dm raid is using might not be right, but I am not sure. I do not know why the target does not like it. On Sep 21, 2012, at 5:59 AM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote # time sg_inq -e -p 80- /dev/sdc unrecognized multiplier Bad argument to '--page=', expecting 0 to 255 inclusive Modified: # time sg_inq -e -p 80 /dev/sdc I goofed when I wrote the example. You need to pass it in hex so it should be sg_inq -e -p 0x80 /dev/sdc I think that will end up working ok though. sg_inq seems to use a different len than what dm raid does. Hi Mike! Thanks for that. Still, that command responds as quick as possible, so maybe it's actually more dmraid than iSCSI. # time sg_inq -e -p 0x80 /dev/sdc VPD INQUIRY: Unit serial number page Unit serial number: PB5A8D3AATZBSH real0m0.025s user0m0.000s sys 0m0.000s 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?hl=en.
Re: bug in function get_random_bytes()
On 11/02/2012 04:14 AM, rahul wrote:
Guys,
There seems to be a bug in function get_random_bytes(). I reported
this earlier as well but somehow it didn't appear here.
Sorry about that. I think I deleted it in the spam filters.
get_random_bytes(unsigned char *data, unsigned int length)
{
long r;
unsigned n;
int fd;
fd = open(/dev/urandom, O_RDONLY);
while (length 0) {
if (!fd || read(fd, r, sizeof(long)) != -1) the condition is
incorrect
The correct check should be
if (fd == -1 || read(fd, r, sizeof(long)) == -1)
Can someone take a look ?
Huh. Not sure what happened there. You are right. I made the attached
patch. Thanks for the bug report and thanks for following up!
--
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?hl=en.
diff --git a/usr/auth.c b/usr/auth.c
index c924545..52e9946 100644
--- a/usr/auth.c
+++ b/usr/auth.c
@@ -194,19 +194,19 @@ get_random_bytes(unsigned char *data, unsigned int length)
fd = open(/dev/urandom, O_RDONLY);
while (length 0) {
- if (!fd || read(fd, r, sizeof(long)) != -1)
+ if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 4);
n = r 0x7;
- if (!fd || read(fd, r, sizeof(long)) != -1)
+ if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
n = (n 3) | (r 0x7);
- if (!fd || read(fd, r, sizeof(long)) != -1)
+ if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
Re: iSCSI session problem(using LOM of Intel i350 and NIC of intel corporation 82580 on IBM x3650M4 Server with RHEL6.1)
On 11/05/2012 02:48 AM, Manju sharma wrote: *Hi ,* *Current setup is:* (LOM of Intel i350 and NIC of intel corporation 82580 on IBM x3650M4 Server with RHEL6.1)also i installed the software of multipathing. *The issue is:* *iSCSI session shows random behaviour* ,some time only one of the session made via LOM and NIC card retain and sometimes both retain after system reboot following are some of the settings of */etc/iscsi/iscsid.conf* file *node.startup = automatic node.session.timeo.replacement_timeout = 30* __ _i created the session by following the below mention steps:_ #iscsiadm -m iface -I iface_name --op=new #iscsiadm -m iface -I iface_name --op=update -n iface.hwaddress -v hardware address /hardware address of particular ethX to which i want to bind the iface/ #iscsiadm -m discovery -t st -p portal_address -I iface_name -P 1 /e.g of portal address: 192.168.3.4:3260/ #iscsiadm -m node -I iface_name -p portal_address -l _and i check the session via following command_ #iscsiadm -m session So what you run this command only one session is made sometimes? What is the output of the login command when it fails to create one of the sessions? - Can anybody help me in solving this*issue .i.e why session show random behaviour *.what should i do to overcome this problem*i.e Is i have to do some more setting so that the iscsi sessions will retain after system reboot too. -*Is there any particular file in Linux file system to see the iSCSI related logs. or is there any command to debug. /var/log/messages. -- 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?hl=en.
Re: no LUN 1/disk size
On 11/06/2012 09:47 PM, Trenton Adams wrote: Hi Guys, I ran into something interesting, and I'm wondering if this can or should be fixed. I setup a second disk pointing to a partition on my drive, which already had another partition shared out using open-iscsi. I found out really quickly that no drives show up in Windows 7 computer management console, even though it's successful connecting. So, I ran tgtadm -m target -o show, and got the following... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: I_T nexus: 1 Initiator: iqn.1991-05.com.microsoft:tda-desktop Connection: 1 IP Address: 192.168.8.4 LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 Luckily, I thought about what the problem might be, seeing the first partition was working fine. The problem that occurred was that I had edited the disk partition table while tgtd was using the drive. Of course you get the standard message that a reboot is necessary. Instead of that, I shut down tgtd, opened the disk, and re-wrote the partition table. After restarting tgtd, the output of the above command is now... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00020001 SCSI SN: beaf21 Size: 268436 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /dev/sdf2 Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 So, I guess my question is, should this be considered a bug? Is there any way that open-iscsi can notify the client that the disk is not yet working? I am not sure if I understand the problem. In the case where lun1 is not made you want open-iscsi to return some sort of error or notification? If so, there is nothing open-iscsi can do. We just log into the target and ask it what luns it has. open-iscsi does not even do the part where it asks what luns are available. It has the scsi layer do this. In the iscsi spec there is a way for the target to tell the initiator that new luns have been added but tgtd does not support it. You would have to ask the developers on tgt list to implement 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?hl=en.
Re: [PATCH 1/2] iscsi_flash_sysfs: Add flash target mgmt support through sysfs.
On 11/04/2012 11:17 PM, Lalit Chandivade wrote: Mike, The related options are clubbed as a bit map, each bit means something within an option. I am trying to give few examples for each option, + FLASH_TGT_OPTIONS, This is an IPv6 target This is a discovery target (send target) + FLASH_TGT_ISCSI_OPTIONS, Data Digest is enabled Header Digest is enabled + FLASH_TGT_TCP_OPTIONS, Disable TCP Scale Window + FLASH_TGT_IP_OPTIONS, Disable Fragmentation Did I misread the code? The defs for the bits are qla specific right now right? I am just asking to move the definitions for the bits to the iscsi_flash_sysfs code, so it is usable and defined for all drivers that use the interface. It should be such that if we have a qla4xxx target and a be2iscsi target then writing the same bitmap to the options file turns/off the same features. -- 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?hl=en.
Re: no LUN 1/disk size
Okay, that makes sense. The problem was that the new partition table was not available, because it was in use when I modified it. :P Kind of my problem I suppose. lol On Tue, Nov 6, 2012 at 11:03 PM, Mike Christie micha...@cs.wisc.edu wrote: On 11/06/2012 09:47 PM, Trenton Adams wrote: Hi Guys, I ran into something interesting, and I'm wondering if this can or should be fixed. I setup a second disk pointing to a partition on my drive, which already had another partition shared out using open-iscsi. I found out really quickly that no drives show up in Windows 7 computer management console, even though it's successful connecting. So, I ran tgtadm -m target -o show, and got the following... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: I_T nexus: 1 Initiator: iqn.1991-05.com.microsoft:tda-desktop Connection: 1 IP Address: 192.168.8.4 LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 Luckily, I thought about what the problem might be, seeing the first partition was working fine. The problem that occurred was that I had edited the disk partition table while tgtd was using the drive. Of course you get the standard message that a reboot is necessary. Instead of that, I shut down tgtd, opened the disk, and re-wrote the partition table. After restarting tgtd, the output of the above command is now... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00020001 SCSI SN: beaf21 Size: 268436 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /dev/sdf2 Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 So, I guess my question is, should this be considered a bug? Is there any way that open-iscsi can notify the client that the disk is not yet working? I am not sure if I understand the problem. In the case where lun1 is not made you want open-iscsi to return some sort of error or notification? If so, there is nothing open-iscsi can do. We just log into the target and ask it what luns it has. open-iscsi does not even do the part where it asks what luns are available. It has the scsi layer do this. In the iscsi spec there is a way for the target to tell the initiator that new luns have been added but tgtd does not support it. You would have to ask the developers on tgt list to implement 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?hl=en.
Re: bug in function get_random_bytes()
On 11/07/2012 12:17 AM, rahul wrote:
Mike,
Huh. Not sure what happened there. You are right. I made the attached
patch. Thanks for the bug report and thanks for following up!
diff --git a/usr/auth.c b/usr/auth.c
index c924545..52e9946 100644
--- a/usr/auth.c
+++ b/usr/auth.c
@@ -194,19 +194,19 @@ get_random_bytes(unsigned char *data, unsigned
int length)
fd = open(/dev/urandom, O_RDONLY);
while (length 0) {
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 4);
n = r 0x7;
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
n = (n 3) | (r 0x7);
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
Thanks for taking a look at this and fixing this. I feel following check
would be better. If open fails, it returns -1, so (!fd) is not correct.
We should check for fd == -1.
if ( fd == -1 || read(fd, r, sizeof(long)) != sizeof(long))
You are very correct. I will fix that in the patch that gets merged. Thanks.
--
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?hl=en.
Antw: no LUN 1/disk size
Hi! I guess it's an issue with tgtd, if at all: If the OS doesn't see a partition locally, there's litte sense complaining that using it won't work. Whatever application you are using. Regards, Ulrich Trenton Adams trenton.d.ad...@gmail.com schrieb am 07.11.2012 um 04:47 in Nachricht 89e30135-4d58-4ec1-ba33-4dd30fe11...@googlegroups.com: Hi Guys, I ran into something interesting, and I'm wondering if this can or should be fixed. I setup a second disk pointing to a partition on my drive, which already had another partition shared out using open-iscsi. I found out really quickly that no drives show up in Windows 7 computer management console, even though it's successful connecting. So, I ran tgtadm -m target -o show, and got the following... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: I_T nexus: 1 Initiator: iqn.1991-05.com.microsoft:tda-desktop Connection: 1 IP Address: 192.168.8.4 LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 Luckily, I thought about what the problem might be, seeing the first partition was working fine. The problem that occurred was that I had edited the disk partition table while tgtd was using the drive. Of course you get the standard message that a reboot is necessary. Instead of that, I shut down tgtd, opened the disk, and re-wrote the partition table. After restarting tgtd, the output of the above command is now... Target 2: iqn.2012-11.ca.trentonadams:tdadesktop System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 0002 SCSI SN: beaf20 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00020001 SCSI SN: beaf21 Size: 268436 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /dev/sdf2 Backing store flags: Account information: iqn.1991-05.com.microsoft:tda-desktop ACL information: 192.168.8.191 192.168.8.99 192.168.8.4 127.0.0.1 So, I guess my question is, should this be considered a bug? Is there any way that open-iscsi can notify the client that the disk is not yet working? Thanks. -- 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?hl=en.
Antw: Re: bug in function get_random_bytes()
rahul junky_fel...@yahoo.co.in schrieb am 07.11.2012 um 07:17 in Nachricht
102cd120-1e96-4e71-9c41-eeaeb8675...@googlegroups.com:
Mike,
Huh. Not sure what happened there. You are right. I made the attached
patch. Thanks for the bug report and thanks for following up!
diff --git a/usr/auth.c b/usr/auth.c
index c924545..52e9946 100644
--- a/usr/auth.c
+++ b/usr/auth.c
@@ -194,19 +194,19 @@ get_random_bytes(unsigned char *data, unsigned int
length)
fd = open(/dev/urandom, O_RDONLY);
while (length 0) {
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 4);
n = r 0x7;
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
n = (n 3) | (r 0x7);
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
Hi!
Sorry for jumping on this train:
Isn't the proper test for a failed read read(fd, r, sizeof(long)) !=
sizeof(long))?
Ulrich
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
Thanks for taking a look at this and fixing this. I feel following check
would be better. If open fails, it returns -1, so (!fd) is not correct. We
should check for fd == -1.
if ( fd == -1 || read(fd, r, sizeof(long)) != sizeof(long))
--
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?hl=en.
Re: Antw: Re: bug in function get_random_bytes()
On 11/07/2012 01:48 AM, Ulrich Windl wrote:
rahul junky_fel...@yahoo.co.in schrieb am 07.11.2012 um 07:17 in
Nachricht
102cd120-1e96-4e71-9c41-eeaeb8675...@googlegroups.com:
Mike,
Huh. Not sure what happened there. You are right. I made the attached
patch. Thanks for the bug report and thanks for following up!
diff --git a/usr/auth.c b/usr/auth.c
index c924545..52e9946 100644
--- a/usr/auth.c
+++ b/usr/auth.c
@@ -194,19 +194,19 @@ get_random_bytes(unsigned char *data, unsigned int
length)
fd = open(/dev/urandom, O_RDONLY);
while (length 0) {
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 4);
n = r 0x7;
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
n = (n 3) | (r 0x7);
-if (!fd || read(fd, r, sizeof(long)) != -1)
+if (!fd || read(fd, r, sizeof(long)) == -1)
Hi!
Sorry for jumping on this train:
Isn't the proper test for a failed read read(fd, r, sizeof(long)) !=
sizeof(long))?
It is late :) You are saying the same thing as rahul below right?
Ulrich
r = rand();
r = r ^ (r 8);
r = r ^ (r 5);
Thanks for taking a look at this and fixing this. I feel following check
would be better. If open fails, it returns -1, so (!fd) is not correct. We
should check for fd == -1.
if ( fd == -1 || read(fd, r, sizeof(long)) != sizeof(long))
--
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?hl=en.
