Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Jul 2015 10:32:18 +0200
From:      Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org>
To:        RA H <rah.lists@gmail.com>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: [iscsictl] connection to invalid target
Message-ID:  <20150702083218.GA16246@brick.home>
In-Reply-To: <CAFzyudjxb6k7E_BdCFAghCrF62RZ-93dNsfSifHGh2k9F3RmgA@mail.gmail.com>
References:  <CAFzyudhbMyEr9KEqo_%2Bxvr-AOnqinCJ%2B5Px9KZmTUpMsCWXPEQ@mail.gmail.com> <20150630194558.GA1223@brick.home> <CAFzyudjxb6k7E_BdCFAghCrF62RZ-93dNsfSifHGh2k9F3RmgA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 0701T1527, RA H wrote:
> Thanks for the suggestion. Based on the debug log it looked like the
> problem was with the SAN, and in fact it is. Apparently it's not considered
> a pressing issue because most initiators will only attempt to connect to
> targets returned by a discovery session...

So basically it's not a FreeBSD bug?

> I'm using another workaround for the target validation which works fine,
> but it's more complicated than my initial plan, nevermind simply parsing
> the output of a discovery session eg. "iscontrol -dt <target address>".
> Since I have your attention, is there any chance of such a thing being
> implemented with iscsictl?

The problem here is that the discovery is performed by iscsid; the way
to implement it would be to make iscsictl add the discovery session, wait
for iscsid to finish discovery but not connect to the targets, report
targets, and then remove them.  So basically pretty much what you are
doing anyway.

> Thanks again.
> 
> On Tue, Jun 30, 2015 at 3:45 PM, Edward Tomasz NapieraƂa <trasz@freebsd.org>
> wrote:
> 
> > On 0629T1458, RA H wrote:
> > > I have a SAN with four iSCSI targets,
> > > eui.000B56007135B1B0 through eui.000B56007135B1B3
> > >
> > > I need to validate target names entered manually by a user.
> > > Normally, I would do this is by searching the output of a discovery
> > > session. Since iscsictl doesn't allow doing discovery *only*, the only
> > > way I can think of to validate a target is to connect, then parse the
> > > output of "iscsictl -L". Unfortunately, attempting to connect to certain
> > > invalid targets results in connection to a valid target:
> > >
> > > # iscsictl -Ad 192.168.3.111
> > > # iscsictl -L
> > > Target name                          Target portal    State
> > > eui.000B56007135B1B0                 192.168.3.111    Connected: da0
> > > eui.000B56007135B1B1                 192.168.3.111    Connected: da2
> > > eui.000B56007135B1B2                 192.168.3.111    Connected: da1
> > > eui.000B56007135B1B3                 192.168.3.111    Connected: da3
> > > # iscsictl -Ra
> > > # iscsictl -A -p 192.168.3.111 -t eui.000B56007135B1A1
> > > # iscsictl -L
> > > Target name                          Target portal    State
> > > eui.000B56007135B1A1                 192.168.3.111    Connected: da0
> > > # dmesg
> > > ...
> > > da0: Serial Number 000B56007135B1B10000
> > > ...
> > >
> > > As the Serial Number indicates, iscsictl actually connected to
> > > target eui.000B56007135B1B1.
> >
> > That's weird.  Could you paste the iscsid debug log when this happens?
> > (Basically do "pkill iscsid; while :; do iscsid -d; done" in a separate
> > shell and capture the output).
> >
> >
> _______________________________________________
> freebsd-scsi@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150702083218.GA16246>