Pb to discover my iSCSI targets from a Solaris 10 Netra X1

1/ I configured a iSCSI target using the open-e SOHO
   IDE module, and created 2 targets:
   ~ iqn.2007-08:iscsi.target0
   ~ iqn.2007-08:iscsi.target1
   available on IP 192.168.1.4 (it runs on a Dell
   PowerEdge 1400sc)

2/ then on my Netra x1
   I ran the 3 commands:
   ~ iscsiadm add discovery-address 192.168.1.4
   ~ iscsiadm modify discovery --sendtargets enable
   ~ devfsadm -i iscsi
   as described on the pages around this one:
    http://www.**--****.com/ 

3/ for every command I had lines in /var/adm/messages saying:

   ~ Aug  5 10:36:55 netrax1 iscsi: [ID 919666 kern.notice] \
                NOTICE: iscsi: SendTarget discovery failed (11)
   ~ Aug  5 10:36:55 netrax1 iscsi: [ID 114404 kern.notice] \
                NOTICE: iscsi discovery failure - SendTargets
(192.168.001.004)
   ~ Aug  5 10:37:57 netrax1 iscsi: [ID 919666 kern.notice] \
                NOTICE: iscsi: SendTarget discovery failed (11)
   ~ Aug  5 10:37:57 netrax1 iscsi: [ID 114404 kern.notice] \
                NOTICE: iscsi discovery failure - SendTargets
(192.168.001.004)
   ~ Aug  5 16:30:05 netrax1 iscsi: [ID 919666 kern.notice] \
                NOTICE: iscsi: SendTarget discovery failed (11)

   Searches on onesearch.sun.com with the string "sendtarget
   discovery failed" or "iscsi discovery failure" returns NOTHING !

4/ so it failed, I can't discover my targets; here is my config:
   ~ # uname -a
   ~ SunOS netrax1 5.10 Generic_118833-33 sun4u sparc SUNW,UltraAX-i2

   ~ # iscsiadm list discovery
   ~ Discovery:
   ~        Static: disabled
   ~        Send Targets: enabled
   ~        iSNS: disabled

   ~ # patchadd -p | grep -i iscsi
   ~ Patch: 119090-22 Obsoletes: 121980-03 123500-02 Requires:
118833-25
   ~ Incompatibles: Packages: SUNWiscsir SUNWiscsiu
   ~ Patch: 119092-10 Obsoletes: Requires: Incompatibles: Packages:
SUNWiscsir

   so I guess with these setup and configuration it *should* work
   shouldn't it ?

5/ if I do a 'cat' of network-iscsi_initiator:default.log
   located in /etc/svc/volatile/
   I get:
   ~ [ Aug  5 09:16:53 Disabled. ]

   and if I do a 'strings' of iscsi_v1.dbc and iscsi_v1.dbp in
   /etc/iscsi
   I see things like:
   ~ NodeName
   ~ iqn.1986-03.com.sun:01:0003ba053bd8.46376268
   ~ NodeAlias
   ~ DiscAddr
   ~ 192.168.001.004
   ~ DiscMethod
   ~ Chap
   ~ iqn.1986-03.com.sun:01:0003ba053bd8.46376268
   ~ iqn.1986-03.com.sun:01:0003ba053bd8.46376268
   ~ SENDTARGETS_DISCOVERY
   ~ SENDTARGETS_DISCOVERY

   but nothing about my iqn.2007-08:iscsi.target0 and
   target1 targets !

6/ It doesn't come from my netra because Microsoft's
   iSCSI initiator does discover my targets properly !

Could someone help me, gimme some hints or a track to
follow to further troubleshoot my issue here ?

Thanks...
Regards,
SR

Since your failing discovery make sure your doing basic network
troubleshooting.
  1) Can you ping the address?
  2) Can you telnet to the port at the address?


Peeking at the code this failure message is here.

   http://www.**--****.com/ #2684

It looks like the "11" is a cmd_result value, what ever that is.  But,
I found it here.

   http://www.**--****.com/ #159

iscsi.h:
  159 	/* cmd (tran_abort/reset) failed */
  160 	ISCSI_STATUS_CMD_FAILED,

Looking prior to line 2684 in iscsi_io.c it looks like it was going to
try and send
a iSCSI TEXT (SendTargets) on the wire and the command failed due to a
abort
or reset.

Maybe try the following.  Disable all discovery.

  iscsiadm modify discovery -t disable

Then make sure your discovery address is still present.

  iscsiadm list discovery-address

Then issue the following.  This command if still possible was a little
bit of a
debugging back door left in by one of the developers.  It will issue a
send
target request without all the extra overhead of trying to create LUNs
in
Solaris etc.  It just tests the connection and sendtargets request.

  iscsiadm list discovery-address -v

If you see it return a list of targets then things are good.  If it
fails check
/var/adm/messages for your errors again.  If it does fail again it
sounds
like a settings or protocol imcompatibility.  I know people have used
Open-E's iSCSI target with Solaris successfully so make sure you clear
all your parameter settings (digests, etc) and repeat the test.  If
that doesn't
work the quickest way to solve the problem is probably going to be to
dive
into the protocol.  Collect a wireshark(ethereal) or snoop trace
during the
discovery-address -v command.  This should be a pretty small trace
and
should give lots of hints/details to why its failing.  You could
either post that
trace where someone knowledgable can access it on the net or open a
support ticket to sun with your documentation to have them look at it.

Dave,
First of all thanks a lot for your hints here.

I'm sorry I forgot to say that I can of course
-ping my 192.168.1.4 iSCSI host,
-and perform a telnet connection on the default port without any
 problem (3260 if i'm not mistaken).

I'll try the options you describe and provide you with some positive
feedback -hopefully-.

Do you mind if I also send you copies to your mail address ?

Once again, thanks.

dave schreef:

#  iscsiadm list discovery-address
returns right away:
~ Discovery Address: 192.168.1.4:3260

#  iscsiadm list discovery-address  -v
returns after about 20 to 30 seconds:
~ Discovery Address: 192.168.1.4:3260
~         Unable to get targets.

and here var adm messages says, as usual:
~ Aug  8 20:26:51 netrax1 iscsi: [ID 919666 kern.notice]  \
~               NOTICE: iscsi: SendTarget discovery failed (11)

I tried to install
ethereal-0.99.0-solaris2.9-sparc-local
but it fails with
~ This package requires gtk+ version >= 1.2 installed in \
~                                                    /usr/sfw/bin.
~ Aborting installation.

so I tried to install
gtk+-1.2.10-sol9-sparc-local
and it worked but didn't install it in this /usr/sfw/bin,
so another attempt to install gtk+ failed once more.

Is ther ea way to tell 'pkgadd' to install a pkg in a
given target directory ? I did a 'pkgadd -d' every
time.
(I'm no ux admin whatsoever, and never was...)

Thanks.
Sastien