Re: [PATCH] Allow empty username for CHAP
Mike Christie wrote: > On 09/29/2009 08:46 AM, Hannes Reinecke wrote: >> Some iSCSI implementations (eg HP) is using an empty username for >> CHAP negotiations. So we should be allowing the same. >> > > Do we need this support for discovery? There is one other one auth setup > function in discovery.c:setup_authentication(). Not sure why we have two > almost identical functions there. Probably due to how it is all > compiled. Do not worry about the duplication in this patch. We can just > fix up discovery.c:setup_authentication(). > Yes, we also need to support an empty username for discovery. And I seriously think if we shouldn't redesign the discovery node database: Currently we're storing the _detected_ target names under /etc/iscsi/send_targets, ie we have to preset the CHAP variables in /etc/iscsid.conf. But this makes it impossible to have different settings for different portals; one iSCSI portal might require CHAP authentication discovery, the next might not, and another one might have a different username/password. It would be far more sensible to store the settings for the _portal_ under /etc/iscsi/send_targets, too; this would allow us to modify them via -o update and have different settings for different targets. > Can you have a empty incoming username? If so I think we need to modify > acl_chap_auth_request like how you did to acl_set_user_name. No, not what I've seen so far; but I haven't been exactly successful here. I'll dig further here. BTW, would it be sensible to support both methods if CHAP is enabled? Currently we're only setting the auth method to either 'CHAP' or 'None'. We means we cannot login to a target which just supports 'None' when we set the record to 'CHAP'. Any specific reason? Methinks it'd be far more sensible to announce 'CHAP,None' whenever CHAP is selected. And to allow login with no credentials, too, in this case. Comments? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
SD Driver incrementing on every snapshot.
Group, I'm using linux to backup an ISCSI target. My backup script calls the snapshot function on my iscsi server, then uses open-iscsi to connect to a snapshot target on that server. The target is backed up, then I logoff the target until the next backup. The problem is that the scsi device number in linux keeps incrementing: scsi13 : iSCSI Initiator over TCP/IP scsi14 : iSCSI Initiator over TCP/IP scsi15 : iSCSI Initiator over TCP/IP Is this cause for concern? Will it quit on me at some point? Is there a way to make open-iscsi reuse an old scsi device number? Thanks, schu --~--~-~--~~~---~--~~ 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: Intel NIC iSCSI acceleration in Linux and open-iscsi
On Mon, Sep 28, 2009 at 08:50:57PM -0700, Meenakshi Ramamoorthi wrote: >Yes, what details do you require ? > Well.. what's the status? Is the code available from somewhere? Can I test it? :) I haven't seen anything on open-iscsi list.. at least I can't remember. Thanks! -- Pasi >On Sat, Sep 26, 2009 at 4:49 AM, Pasi Kärkkäinen <[1]pa...@iki.fi> wrote: > > Hello, > > Is anyone working on Linux/open-iscsi iSCSI offloading/acceleration > using Intel gigabit and 10 gigabit NICs? > > -- Pasi > >> > References > >Visible links >1. mailto:pa...@iki.fi --~--~-~--~~~---~--~~ 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: building from source fails on "custom cloud/xen" kernel.
On 09/28/2009 03:04 PM, Xenophod wrote: > I'm trying to build the open-iscsi module for a xen kernel provided by > 3Tera/Applogic (based on CentOS 5.1 I believe). > I have the kernel source from the vendor and I'm not sure if I'm doing > this right. > Here is the command I'm running: > > # make KSRC=/root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg \ > KBUILD_OUTPUT=/root/rpm/BUILD/xen-3.2.2-src/build-linux-2.6.18- > xenU_x86_32 > > make -C /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg M=`pwd` > KBUILD_OUTPUT=/root/rpm/BUILD/xen-3.2.2-src/build-linux-2.6.18- > xenU_x86_32 V=0 modules > make[2]: Entering directory `/root/rpm/BUILD/xen-3.2.2-src/ > linux-2.6.18-xen.hg' >CC [M] /root/open-iscsi-2.0-870.3/kernel/scsi_transport_iscsi.o > In file included from /root/open-iscsi-2.0-870.3/kernel/ > scsi_transport_iscsi.h:34, > from /root/open-iscsi-2.0-870.3/kernel/ > scsi_transport_iscsi.c:33: > /root/open-iscsi-2.0-870.3/kernel/open_iscsi_compat.h:190: error: > redefinition of ‘shost_priv’ > /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg/include/scsi/ > scsi_host.h:644: error: previous definition of ‘shost_priv’ was here > /root/open-iscsi-2.0-870.3/kernel/open_iscsi_compat.h:218: error: > redefinition of ‘scsi_set_resid’ > /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg/include/scsi/ > scsi_cmnd.h:150: error: previous definition of ‘scsi_set_resid’ was > here > /root/open-iscsi-2.0-870.3/kernel/open_iscsi_compat.h:223: error: > redefinition of ‘scsi_get_resid’ > /root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg/include/scsi/ > scsi_cmnd.h:155: error: previous definition of ‘scsi_get_resid’ was > here > /root/open-iscsi-2.0-870.3/kernel/scsi_transport_iscsi.c: In function > ‘__iscsi_unblock_session’: > /root/open-iscsi-2.0-870.3/kernel/scsi_transport_iscsi.c:551: warning: > unused variable ‘ihost’ > make[4]: *** [/root/open-iscsi-2.0-870.3/kernel/ > scsi_transport_iscsi.o] Error 1 > make[3]: *** [_module_/root/open-iscsi-2.0-870.3/kernel] Error 2 > make[2]: *** [modules] Error 2 > make[2]: Leaving directory `/root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18- > xen.hg' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/root/open-iscsi-2.0-870.3/kernel' > make: *** [all] Error 2 > > > I've tried this with both open-iscsi-2.0-870.3 and open-iscsi-2.0-871 > sources and I get the same results. > Is there something I'm doing wrong? Am I missing some tools that I > should get through yum? > The open-iscsi kernel build code supports upstream kernels and in some cases where someone modified the core patches to support it some specific red hat kernels. It does not support other vendor kernels well, because we have no idea what is in there, or the build system is not smart enough to figure out what is going on, or because I messed up on the compat code and did not make it generic enough. --~--~-~--~~~---~--~~ 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: connection error kills iscsi session
On 09/28/2009 09:39 AM, Drew Morris wrote: > Mike, > > Thanks for your prompt/detailed reply. > > Vtrak is an iscsi disk array, which unfortunately doesn't seem to be > reporting any errors. > Is there any sort of debugging I could do to discern what the cause of the > problem is? I'm pretty sure it's not a pulled cable, but either the target or > the initiator dropping the connection for some reason... > What sort of "invalid data" would cause the initiator to drop the connection? > > There are no errors about pings or nops. The fragment I sent was the > "beginning" of the problem. Can the verbosity of the iscsi messages be > increased? > Are you using the kernel modules and tools from open-iscsi.org? If so, each iscsi module has a mod param that can used to turn on different debugging. You can also set it through sysfs like so: echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_conn echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_session echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_eh echo 1 > /sys/module/iscsi_tcp/parameters/debug_iscsi_tcp echo 1 > /sys/module/libiscsi_tcp/parameters/debug_libiscsi_tcp This turns on all the logging, so if you run IO it will be a lot of info. You probably just want to turn all this on when not doing any reads/writes. That way we will just get what causes the initial conn error. --~--~-~--~~~---~--~~ 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: SCSI pass through command cause iscsi Conn error
On 09/26/2009 09:20 PM, niko scsi wrote: > I followed the howto > http://tldp.org/HOWTO/SCSI-Generic-HOWTO/scsi_snd_cmd.html > to pass through scsi cmd with data (self defined,target can handle > it) to iscsi disk. > however,the request was handled six times ,I checked the log ,the > reason is shown below. The connection failed and recovered six > times ,and I tested many times ,each time ,the same :six times! > I'm newbie to scsi program. Any idea that can cause this problem ? > > error occurred in function iscsi_data_rsp > > tcp debug infomations show below : > > ... > Sep 27 09:37:01 localhost kernel: tcp: skb dfab65c0 ptr=da5a5a54 > avail=60 > Sep 27 09:37:01 localhost kernel: tcp: copied 0 0 size 48 recv > Sep 27 09:37:01 localhost kernel: tcp: iscsi_tcp_segment_recv copying > 48 > Sep 27 09:37:01 localhost kernel: tcp: copied 0 48 size 48 recv > Sep 27 09:37:01 localhost kernel: tcp: iscsi_tcp_segment_unmap > cb76be10 > Sep 27 09:37:01 localhost kernel: tcp: total copied 48 total size 48 > Sep 27 09:37:01 localhost kernel: tcp: segment done > Sep 27 09:37:01 localhost kernel: tcp: opcode 0x25 ahslen 0 datalen 12 > Sep 27 09:37:01 localhost kernel: tcp: iscsi_data_rsp: ctask- >> exp_datasn(1) != rhdr->datasn(0) You might not be doing anything wrong. It might a target or initiator bug. What target are you using? In your setup, did you modify the iscsi target in some way? And what kernel are using? --~--~-~--~~~---~--~~ 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] Allow empty username for CHAP
On 09/29/2009 08:46 AM, Hannes Reinecke wrote: > Some iSCSI implementations (eg HP) is using an empty username for > CHAP negotiations. So we should be allowing the same. > Do we need this support for discovery? There is one other one auth setup function in discovery.c:setup_authentication(). Not sure why we have two almost identical functions there. Probably due to how it is all compiled. Do not worry about the duplication in this patch. We can just fix up discovery.c:setup_authentication(). Can you have a empty incoming username? If so I think we need to modify acl_chap_auth_request like how you did to acl_set_user_name. --~--~-~--~~~---~--~~ 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: iSCSI Connection failure with bnx2i transport
Thanks for catching this bug Thomas and testing this bug Narendra. The patch looks good. Reviewed-by: Benjamin Li On Tue, 2009-09-29 at 09:03 -0700, shyam_i...@dell.com wrote: > 1. Install Red Hat Enterprise Linux 5.4 snapshot 5 i386 on a server with > Broadcom iSCSI offload capable LOMs. > *** Note: 32-bit OS believed necessary *** > 2. Discover an iSCSI target on the local IP network using the offload > interface. > iscsiadm -m discovery -p -t st -I bnx2i. > 3. Configure the offload interface to use DHCP. > iscsiadm -m iface -I bnx2i -o update -n iface.ipaddress -v 0.0.0.0 > 4. Attempt to connect to the iSCSI target. > iscsiadm -m node -l > 5. Observe that the connection attempt eventually times out. > > This bug affects the upstream versions of the cnic code as well. > > Signed-off-by: Thomas Chenault > Tested-by: Narendra K > > --- > open-iscsi-2.0-871-test4.bnx2i/brcm_iscsi_uio/src/unix/libs/cnic_nl.c > 2009-08-18 23:03:34.0 -0500 > +++ > open-iscsi-2.0-871-test4.bnx2i.new/brcm_iscsi_uio/src/unix/libs/cnic_nl. > c 2009-08-18 23:06:12.0 -0500 > @@ -124,7 +124,7 @@ > path_rsp->ip_addr_len = 4; > memcpy(&path_rsp->src.v4_addr, &nic_iface->ustack.hostaddr, > sizeof(nic_iface->ustack.hostaddr)); > - memcpy(path_rsp->mac_addr, mac_addr, sizeof(mac_addr)); > + memcpy(path_rsp->mac_addr, mac_addr, 6); > path_rsp->vlan_id = path_req->vlan_id; > path_rsp->pmtu= path_req->pmtu; > > > > --~--~-~--~~~---~--~~ 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: Intel NIC iSCSI acceleration in Linux and open-iscsi
Yes, what details do you require ? On Sat, Sep 26, 2009 at 4:49 AM, Pasi Kärkkäinen wrote: > > Hello, > > Is anyone working on Linux/open-iscsi iSCSI offloading/acceleration > using Intel gigabit and 10 gigabit NICs? > > -- Pasi > > > > > --~--~-~--~~~---~--~~ 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: Cannot build new open-iscsi in Suse 10 SP2
I'm getting the same messages when I try to build on my CentOS VM running a Xen Kernel. On Sep 15, 9:39 pm, Liming wrote: > I tried to build new open-iscsi(2.0-871) in Suse 10 SP2 but it failed. > I got some error message. The kernel version is 2.6.16-60. Do any one > know how to fix it?? > > > > goddard-suse:/home/guardkuo/open-iscsi-2.0-865 # make KSRC=/usr/src/ > linux KBUILD_OUTPUT=/usr/src/linux-obj/i386/smp > make -C usr > make[1]: Entering directory `/home/guardkuo/open-iscsi-2.0-865/usr' > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o util.o util.c > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o io.o io.c > io.c:86: warning: ‘get_hwaddress_from_netdev’ defined but not used > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o auth.o auth.c > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o login.o login.c > ... > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsiadm.o iscsiadm.c > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o > sha1.o iscsi_sysfs.o idbm.o strings.o discovery.o iscsiadm.o -o > iscsiadm > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsistart.o iscsistart.c > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o statics.o statics.c > cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - > DNETLINK_ISCSI=8 -D_GNU_SOURCE -static netlink.o util.o io.o auth.o > login.o log.o md5.o sha1.o iscsi_sysfs.o idbm.o initiator.o queue.o > actor.o mgmt_ipc.o isns.o transport.o iscsistart.o statics.o -o > iscsistart > login.o: In function `resolve_address': > /home/guardkuo/open-iscsi-2.0-865/usr/login.c:168: warning: Using > 'getaddrinfo' in statically linked applications requires at runtime > the shared libraries from the glibc version used for linking > make[1]: Leaving directory `/home/guardkuo/open-iscsi-2.0-865/usr' > make -C kernel > make[1]: Entering directory `/home/guardkuo/open-iscsi-2.0-865/kernel' > echo "Patching source code for linux-2.6.16-18 ..." > Patching source code for linux-2.6.16-18 ... > if [ -e cur_patched ]; then \ > make -C . clean; \ > fi > patch -p1 < 2.6.16-18_compat.patch > patching file iscsi_2.6.20_compat.h > patching file iscsi_tcp.h > Hunk #1 succeeded at 52 (offset 3 lines). > patching file libiscsi.c > Hunk #1 succeeded at 760 (offset 44 lines). > Hunk #2 succeeded at 1527 (offset 19 lines). > patching file libiscsi.h > patching file scsi_transport_iscsi.c > patching file scsi_transport_iscsi.h > Hunk #1 succeeded at 182 (offset 6 lines). > cp 2.6.16-18_compat.patch has_16to18_patch > ln -s has_16to18_patch cur_patched > make -C /usr/src/linux M=`pwd` KBUILD_OUTPUT=/usr/src/linux-obj/i386/ > smp V=0 modules > make[2]: Entering directory `/usr/src/linux-2.6.16.60-0.21' > CC [M] /home/guardkuo/open-iscsi-2.0-865/kernel/ > scsi_transport_iscsi.o > CC [M] /home/guardkuo/open-iscsi-2.0-865/kernel/libiscsi.o > CC [M] /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_tcp.o > In file included from /home/guardkuo/open-iscsi-2.0-865/kernel/ > iscsi_tcp.h:55, > from /home/guardkuo/open-iscsi-2.0-865/kernel/ > iscsi_tcp.c:45: > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:4: > error: redefinition of ‘struct hash_desc’ > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:10: > error: redefinition of ‘crypto_hash_init’ > /usr/src/linux-2.6.16.60-0.21/include/linux/crypto.h:949: error: > previous definition of ‘crypto_hash_init’ was here > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: In > function ‘crypto_hash_init’: > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:11: > error: implicit declaration of function ‘crypto_digest_init’ > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: At top > level: > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:18: > error: redefinition of ‘crypto_hash_digest’ > /usr/src/linux-2.6.16.60-0.21/include/linux/crypto.h:968: error: > previous definition of ‘crypto_hash_digest’ was here > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: In > function ‘crypto_hash_digest’: > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:19: > error: implicit declaration of function ‘crypto_digest_digest’ > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h: At top > level: > /home/guardkuo/open-iscsi-2.0-865/kernel/iscsi_2.6.20_compat.h:26: > error: redefinition of ‘crypto_hash_update’ > /usr/src/linux-2.6.16.60-0.21/include/linux/crypto.h:956: error: > previous definition of ‘crypto_hash_updat
building from source fails on "custom cloud/xen" kernel.
I'm trying to build the open-iscsi module for a xen kernel provided by 3Tera/Applogic (based on CentOS 5.1 I believe). I have the kernel source from the vendor and I'm not sure if I'm doing this right. Here is the command I'm running: # make KSRC=/root/rpm/BUILD/xen-3.2.2-src/linux-2.6.18-xen.hg \ KBUILD_OUTPUT=/root/rpm/BUILD/xen-3.2.2-src/build-linux-2.6.18- xenU_x86_32 make -C utils/fwparam_ibft make[1]: Entering directory `/root/open-iscsi-2.0-870.3/utils/ fwparam_ibft' cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fwparam_ibft.o fwparam_ibft.c cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fw_entry.o fw_entry.c cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o prom_lex.o prom_lex.c :1622: warning: ‘yyunput’ defined but not used cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o prom_parse.tab.o prom_parse.tab.c cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -c -o fwparam_ppc.o fwparam_ppc.c fwparam_ppc.c: In function ‘loop_devs’: fwparam_ppc.c:352: warning: passing argument 4 of ‘qsort’ from incompatible pointer type make[1]: Leaving directory `/root/open-iscsi-2.0-870.3/utils/ fwparam_ibft' make -C usr make[1]: Entering directory `/root/open-iscsi-2.0-870.3/usr' cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o util.o util.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o io.o io.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o auth.o auth.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o login.o login.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o log.o log.c log.c:334: warning: ‘__dump_char’ defined but not used cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o md5.o md5.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o sha1.o sha1.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iface.o iface.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o idbm.o idbm.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o sysdeps.o sysdeps.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o sysfs.o sysfs.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsi_sysfs.o iscsi_sysfs.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o netlink.o netlink.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o initiator.o initiator.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o scsi.o scsi.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o actor.o actor.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o mgmt_ipc.o mgmt_ipc.c mgmt_ipc.c: In function ‘event_loop’: mgmt_ipc.c:645: warning: implicit declaration of function ‘sysfs_cleanup’ cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o isns.o isns.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o transport.o transport.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsid.o iscsid.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iface.o idbm.o sysdeps.o sysfs.o iscsi_sysfs.o netlink.o initiator.o scsi.o actor.o mgmt_ipc.o isns.o transport.o iscsid.o -o iscsid cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o strings.o strings.c strings.c: In function ‘enlarge_data’: strings.c:83: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘size_t’ strings.c:83: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 4 has type ‘size_t’ cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o discovery.o discovery.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE -c -o iscsiadm.o iscsiadm.c cc -O2 -g -Wall -Wstrict-prototypes -I../include -DLinux - DNETLINK_ISCSI=8 -D_GNU_SOURCE util.o io.o auth.o login.o log.o md5.o sha1.o iface.o idbm.o sysdeps.o sysfs.o iscsi_sysfs.o ../utils/ fwparam_ibft/fw_entry.o ../utils/fwparam_ibft/fwparam_ibft.o ../utils/ fwparam_ibft/fwparam_ppc.o ../utils/fwparam_ibft/prom_lex.o ../utils/ fwparam_ibft/prom_parse.tab.o strings.o discovery.o i
iSCSI Connection failure with bnx2i transport
1. Install Red Hat Enterprise Linux 5.4 snapshot 5 i386 on a server with Broadcom iSCSI offload capable LOMs. *** Note: 32-bit OS believed necessary *** 2. Discover an iSCSI target on the local IP network using the offload interface. iscsiadm -m discovery -p -t st -I bnx2i. 3. Configure the offload interface to use DHCP. iscsiadm -m iface -I bnx2i -o update -n iface.ipaddress -v 0.0.0.0 4. Attempt to connect to the iSCSI target. iscsiadm -m node -l 5. Observe that the connection attempt eventually times out. This bug affects the upstream versions of the cnic code as well. Signed-off-by: Thomas Chenault Tested-by: Narendra K --- open-iscsi-2.0-871-test4.bnx2i/brcm_iscsi_uio/src/unix/libs/cnic_nl.c 2009-08-18 23:03:34.0 -0500 +++ open-iscsi-2.0-871-test4.bnx2i.new/brcm_iscsi_uio/src/unix/libs/cnic_nl. c 2009-08-18 23:06:12.0 -0500 @@ -124,7 +124,7 @@ path_rsp->ip_addr_len = 4; memcpy(&path_rsp->src.v4_addr, &nic_iface->ustack.hostaddr, sizeof(nic_iface->ustack.hostaddr)); - memcpy(path_rsp->mac_addr, mac_addr, sizeof(mac_addr)); + memcpy(path_rsp->mac_addr, mac_addr, 6); path_rsp->vlan_id = path_req->vlan_id; path_rsp->pmtu= path_req->pmtu; --~--~-~--~~~---~--~~ 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] Allow empty username for CHAP
Some iSCSI implementations (eg HP) is using an empty username for
CHAP negotiations. So we should be allowing the same.
Signed-off-by: Hannes Reinecke
diff --git a/usr/auth.c b/usr/auth.c
index 4b9afb5..cc232a0 100644
--- a/usr/auth.c
+++ b/usr/auth.c
@@ -1892,8 +1892,10 @@ acl_set_user_name(struct iscsi_acl *client, const char
*username)
return AUTH_STATUS_ERROR;
}
- if (strlcpy(client->username, username, AUTH_STR_MAX_LEN) >=
- AUTH_STR_MAX_LEN) {
+ if (!username)
+ client->username[0] = '\0';
+ else if (strlcpy(client->username, username, AUTH_STR_MAX_LEN) >=
+AUTH_STR_MAX_LEN) {
client->phase = AUTH_PHASE_ERROR;
return AUTH_STATUS_ERROR;
}
diff --git a/usr/initiator.c b/usr/initiator.c
index f05b87c..43f454a 100644
--- a/usr/initiator.c
+++ b/usr/initiator.c
@@ -250,8 +250,7 @@ __setup_authentication(iscsi_session_t *session,
if (auth_cfg->username_in[0]
|| auth_cfg->password_in_length) {
/* sanity check the config */
- if ((auth_cfg->username[0] == '\0')
- || (auth_cfg->password_length == 0)) {
+ if (auth_cfg->password_length == 0) {
log_debug(1,
"node record has incoming "
"authentication credentials but has no outgoing "
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Resolved: CHAP login with HP mpx100
Hi all, finally I managed to login to a HP mpx100 bridge with CHAP enabled. Turned out that the HP is not using a CHAP username at all, just the password. So we need to tweak open-iscsi to allow empty usernames. Patch to follow. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
