Re: Antw: [EXT] ISCSI Target and Initiator on same host

[Paul Koning]

> On Jun 30, 2021, at 7:29 AM, Ulrich Windl  
> wrote:
> 
> I think I did that about 10 years ago...
> 
 Riaan Pretorius  schrieb am 30.06.2021 um 
 12:41
> in Nachricht <07b30064-72b3-42c1-ae71-f40c885c06...@googlegroups.com>:
>> I have an interesting question to ask:
>> 
>> Is it possible to share the target on the same server as a initiator ?
>> e.g. server1: target -> server1: initiator 

Yes, I've used that in a test setup when I needed to put a file system on iSCSI 
(to test pNFS).

paul

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/B3425A37-BF5B-48DE-A3DB-3DFC856F19E7%40comcast.net.

Re: iSCSI Multiqueue

[Paul Koning]

> On Jan 24, 2020, at 3:43 AM, Vladislav Bolkhovitin  wrote:
> 
> 
>> ...
> 
> From my old iSCSI target development days, MS is fundamentally not
> friendly to multi-queue, because it requires by the iSCSI spec to
> preserve order of commands inside the session across multiple
> connections. Commands serialization => shared lock or atomic => no
> multi-queue benefits.
> 
> Hence, usage of MS for multi-queue would be beneficial only if to drop
> (aka violate) this iSCSI spec requirement.
> 
> Just a small reminder. I have not looked in the updated iSCSI spec for a
> while, but don't remember this requirement was anyhow eased there.
> 
> In any case, multiple iSCSI sessions per block level "session" would
> always be another alternative that would require virtually zero changes
> in open-iscsi and in-kernel iSCSI driver[1] as opposed to complex
> changes required to start supporting MS in it as well as in many iSCSI
> targets around that currently do not[2]. If I would be working on iSCSI
> MQ, I would consider this as the first and MUCH more preferable option.
> 
> Vlad
> 
> 1. Most likely, completely zero.
> 2. Where requirement to preserve commands order would similarly kill all
> the MQ performance benefits.

My reaction, from a similar background, matches yours.  iSCSI makes things 
quite hard by requiring ordering across the connections that make up a session. 
 That discourages implementation of multi-connection support in targets (it's 
optional).  In some cases, it entirely rules it out; for example, in the 
EqualLogic storage arrays it would be pretty useless to support 
multi-connection since the connections could not be spread over multiple 
arrays, and for that reason we ruled out that feature.

By contrast, MPIO (several independent sessions used by the storage stack as a 
wider and/or more fault tolerant pipe to the storage) requires essentially no 
work at the target and gives at least as much benefit as MCS for a lot less 
work.

paul


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/B7F71EA1-6E05-43A5-BADA-4F29550424D6%40comcast.net.

Re: How to address more than one LUN in a target

[Paul Koning]

Gerry,

I'm not sure I understand the question.  iSCSI doesn't talk to LUNs, it talks 
to iSCSI targets.  You address targets (by their IP address).

Once you're talking to a target, iSCSI provides a path for SCSI to do its thing 
with that target.  One of the things SCSI (not iSCSI) does is ask the target to 
"Report LUNs".  For most storage devices, a list of LUNs comes back, and SCSI 
will make each LUN it sees available as a Linux device.   (EqualLogic is an 
exception, it has just one LUN per target; but few targets, many more LUNs, is 
the much more common pattern and Compellent follows that common pattern.)

The softlink you showed indicates that those LUNs are detected and mapped to 
/dev/sdX Linux block devices, as expected.

One more point: Report LUNs will see the LUNs that the storage device wants you 
to see.  A lot of them do "LUN Masking" which means that only some LUNs are 
visible to a given client, according to access control settings.  If there are 
20 LUNs, but LUN Masking is set so your client does not have permission to see 
19 of them, then from your client only one LUN will appear in the Report LUNs 
reply, and only one /dev/sdX will be created.

paul

> On Apr 11, 2018, at 7:24 AM, jmgerryobr...@gmail.com wrote:
> 
> Hi,
> 
>   How do you address more than one LUN in a target? We are trying to connect 
> from Debian Stretch to an iSCSI volume in a DellEMC Compellent SC5050 array. 
> In the Compellents the targets are the WQNs for the controller interfaces not 
> the volumes Individual iSCSI volumes are given LUN numbers, eg. LUN1, LUN2, 
> etc. Is there any way in open-iscsi to address individual LUNs within a given 
> target? If we reboot the server the individual LUNs are connected to by the 
> Device Mapper and given individual /dev/disk/by-path entries with "-lin-N" 
> suffix (see below). We can't find any way to get open-iscsi to discover 
> individual LUNs when there is more than on LUN attached to a target.
> 
> Can you help us please.
> 
> Regards,
>Gerry
> 
> /dev/disk/by-path/ip-10.32.141.10:3260-iscsi-iqn.2002-03.com.compellent:5000d310055ba23d-lun-4
>  -> ../../sdz

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

[Paul Koning]

> On Jul 5, 2017, at 3:08 AM, Ulrich Windl  
> wrote:
> 
 Jeffrey Walton  schrieb am 17.06.2017 um 16:23 in 
 Nachricht
> :
> 
> [...]
>> But its not clear to me how to ensure uniqueness when its based on
>> randomness from the generators.
> 
> Even with a perfect random generator non-unique values are possible (that's 
> why it's random). It's unlikely, but it can happen. The question is whether 
> the probability of non-unique values from /dev/urandom is any higher than 
> that for values read from /dev/random. One _might_ be able to predict the 
> values from /dev/urandom.

In the implementations I know, /dev/random and /dev/urandom are the same 
driver, the only difference is that when you read from /dev/random there's a 
check for the current entropy level.

If you haven't fed enough entropy yet to the driver since startup, and you read 
/dev/urandom, you get a value that isn't sufficiently secure.  

If you have a properly constructed RNG, as soon as it's been fed enough entropy 
it is secure (at least for the next 2^64 bits or so).  The notion of "using up 
entropy" is not meaningful for a good generator.   See Bruce Schneier's 
"Yarrow" paper for the details.

paul

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [kernel-hardening] [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

[Paul Koning]

> On Jun 17, 2017, at 10:23 AM, Jeffrey Walton  wrote:
> 
> On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan  wrote:
>> On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote:
>>> Hi Lee,
>>> 
>>> On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan  wrote:
 It seems like what you are doing is basically "good", i.e. if there is
 not enough random data, don't use it. But what happens in that case? The
 authentication fails? How does the user know to wait and try again?
>>> 
>>> The process just remains in interruptible (kill-able) sleep until
>>> there is enough entropy, so the process doesn't need to do anything.
>>> If the waiting is interrupted by a signal, it returns -ESYSRESTART,
>>> which follows the usual semantics of restartable syscalls.
>>> 
>> In your testing, how long might a process have to wait? Are we talking
>> seconds? Longer? What about timeouts?
>> 
>> Sorry, but your changing something that isn't exactly broken, so I just
>> want to be sure we're not introducing some regression, like clients
>> can't connect the first 5 minutes are a reboot.
> 
> CHAP (https://www.rfc-editor.org/rfc/rfc1994.txt) and iSCSI
> (https://www.ietf.org/rfc/rfc3720.txt) require random values. If iSCSI
> is operating without them, it seems like something is broken. From RFC
> 3720, Section 8.2.1, CHAP Considerations:
> 
>   When CHAP is performed over a non-encrypted channel, it is vulnerable
>   to an off-line dictionary attack.  Implementations MUST support use
>   of up to 128 bit random CHAP secrets, including the means to generate
>   such secrets and to accept them from an external generation source.
>   Implementations MUST NOT provide secret generation (or expansion)
>   means other than random generation.

That only applies to the generation of the secret, which is configured into 
iscsi, not created by it.  A utility to generate the secret might be supplied, 
of course, just as one might have utilities to generate strong passwords, but 
it's not a component of the iSCSI protocol.

> CHAP actually has a weaker requirement since it only requires _unique_
> (and not _random_). From RFC 1994, Section 2.3, Design Requirements:
> 
>   Each challenge value SHOULD be unique, since repetition of a
>   challenge value in conjunction with the same secret would permit an
>   attacker to reply with a previously intercepted response.  Since it
>   is expected that the same secret MAY be used to authenticate with
>   servers in disparate geographic regions, the challenge SHOULD exhibit
>   global and temporal uniqueness.
> 
> But its not clear to me how to ensure uniqueness when its based on
> randomness from the generators.

A strong RNG of length n will produce numbers likely to be unique until you 
approach the birtday limit 2^(n/2).  So, say, a 128 bit challenge will be 
adequate.

paul


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: login fails

[Paul Koning]

> On Jun 21, 2016, at 11:38 PM, electric0...@gmail.com wrote:
> 
> Hi everybody.
> 
> I have the question
> 
> log :
> iscsiadm: initiator reported error (13 - daemon access denied)
> iscsiadm: Could not log into all portals
> 
> Could you tell me the reason?

Sure.  Something is wrong.

If you are looking for a more detailed answer you will need to ask a more 
detailed question.  You didn't supply any detail about what you wanted to do, 
what configuration, what settings, etc.

paul


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: SHA-1 hashing Algorithm for CHAP

[Paul Koning]

 On Jan 8, 2015, at 9:30 AM, Tejas vaykole tejas.vaykol...@gmail.com wrote:
 
 ...
 Various crypto protocols indeed uses SHA-1 (typically in more complex form 
 like HMAC) for message authentication.  And each of them will obviously have 
 some identifier for that.  But that has nothing to do with CHAP.  For CHAP 
 in iSCSI, you have to look in the iSCSI RFC, and you will find in there only 
 a single identifier, which is for CHAP using MD5. 
 Yes ,you are right. But their is some correction. In iSCSI RFC(3720) page 186 
 (CHAP 11.1.4)  Points to RFC1994(CHAP) for the implementation of CHAP and 
 RFC3720 also mandates initiator/targets to implement MD5 as one required 
 option. But it does not bar the possibility of implementing another hash 
 algorithm with CHAP.  

Correct.  But implementing it at one end of the protocol has no effect; you 
need to implement it in both initiator and target.

You can pick a random number to indicate “CHAP with SHA-1” (such as the 7 you 
mentioned) and put that in both initiator and target, if you have the ability 
to modify both.  That will work; at that point you have a proprietary extension 
to iSCSI.  But if you want standard initiators or targets to use SHA-1 in a 
CHAP exchange, you have to start by getting it added to the standard, and then 
wait for implementers to implement that new feature.

The other point I would add is “why bother?”  There is no cryptographic reason 
for doing this, given the present state of knowledge around MD5 and other 
hashes.  It might be worth while proposing such an extension to the standard as 
a precaution in case a pre-image attack on MD5 is discovered, but at this point 
such an attack is entirely hypothetical.

If your answer is “as an experiment, to see if it can be done”, sure.  You can 
do that, and I would predict that you would get it to work pretty easily 
(again, given that you have control over the implementations of both initiator 
and target to make matching changes).  But if you want to take it beyond an 
experiment, the first step would be to do the standards work, and the first 
step in that work is to justify the effort of making the change.  I expect that 
you may have some difficulty convincing others it’s worth the trouble. 

paul

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion

[Paul Koning]

 On Jan 8, 2015, at 9:11 AM, Bart Van Assche bvanass...@acm.org wrote:
 
 On 01/08/15 14:45, Sagi Grimberg wrote:
 Actually I started with that approach, but the independent connections
 under a single session (I-T-Nexus) violates the command ordering
 requirement. Plus, such a solution is specific to iSER…

The iSCSI standard specifies an ordering requirement for the case of multiple 
connections under a single session.  That requirement is in fact a reason why 
some iSCSI targets have declined to implement multiple connections.

On the other hand, there are lots of “MPIO” implementations in many different 
operating systems that use multiple sessions, so there is no ordering at the 
iSCSI level, and whatever ordering is required (if any) is instead implemented 
at higher layers in the requesting OS.

 
 Hello Sagi,
 
 Which command ordering requirement are you referring to ? The Linux storage 
 stack does not guarantee that block layer or SCSI commands will be processed 
 in the same order as these commands have been submitted.

Neither does SCSI, in fact.  The ordering rules of the SCSI standard are worth 
studying.  They are a lot weaker than most people expect.  A particularly 
interesting case is multiple concurrent writes with overlapping block ranges.

paul

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: SHA-1 hashing Algorithm for CHAP

[Paul Koning]

What is SCST?   

Various crypto protocols indeed uses SHA-1 (typically in more complex form like 
HMAC) for message authentication.  And each of them will obviously have some 
identifier for that.  But that has nothing to do with CHAP.  For CHAP in iSCSI, 
you have to look in the iSCSI RFC, and you will find in there only a single 
identifier, which is for CHAP using MD5.

It would certainly be possible to define CHAP using SHA-1 (or for that matter 
SHA-2) but that hasn’t been done and there hasn’t been a significant push for 
it.  While MD5 has issues, those do not affect its use in CHAP.

paul

 On Jan 3, 2015, at 4:15 AM, Tejas vaykole tejas.vaykol...@gmail.com wrote:
 
 Hello,
 I am looking at the SCST target code, where it looks like it supports the 
 SHA-1 Algorithim for message digest generation.The number assigned to SHA-1 
 is '7'
 
 Thanks.
 Tejas
 
 On Monday, September 15, 2014 11:30:52 AM UTC+5:30, Uli wrote:
  Tejas vaykole tejas.v...@gmail.com schrieb am 11.09.2014 um 12:22 in 
 Nachricht e87c916b-0b75-4570-b690-71197a5c2...@googlegroups.com: 
  Hello, 
  
  I am trying out with the open-iscsi initiator.I see that the initiator uses 
  MD5 algorithm for CHAP. 
  I need help in configuring the initiator to use SHA-1 hashing Algorithm for 
  CHAP. 
 
 Whcih algorithm number has been assigned to SHA-1 for CHAP? Ic ould not find 
 it. 
 
  
  Thanks. 
  Tejas 

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Getting log-message Login authentication failed with target .. during iSCSI login-redirect

[Paul Koning]

EqualLogic arrays always do a redirect, because you connect to the group 
address and you are redirected by the connection balancer to a specific 
interface IP address.

The initiator is wrong to call code 0101 a “login error”.  The RFC is perfectly 
clear that redirect is NOT an error condition.  But it looks like it’s just a 
confusing message, nothing more.

If you’re seeing actual failures to connect, you should look for other messages 
that explain that; the redirect isn’t the explanation.  Real connection 
failures should also come with event messages on the array that report some 
sort of error, for example an access control reject.

paul

 On Dec 9, 2014, at 7:28 AM, neilcavend...@gmail.com wrote:
 
 Hi guys,
 
 I am currently getting a simular error
 Login to iSCSI target 
 iqn.2001-05.com.equallogic:0-8a0906-ee861180b-5e40001a1484fc4b-01 on 
 vmhba39 @ vmk4 failed. Target returned login error of: 0101.
 
 These drives used to be fine on this host. 
 
 When looking in static discovery I can see the target. We are getting this 
 for a few volumes too. It is happening to random volumes over random hosts. 
 
 Other hosts are connecting to this LUN with out any issues.
 
 Any help here would be great. 
 
 
 On Wednesday, July 30, 2014 7:41:03 AM UTC+1, KUMAR NITISH wrote:
 Hi all,
 
 I am using Dell EqualLogic array as target. When I make session with this 
 target, I am getting the logs as given below : 
 
 login response status 0101
 Login authentication failed with target 
 iqn.2001-05.com.equallogic:0-8a0906-964f1f903-d850018d2a253d5f-nitishk521
 ..
 ..
 login response status 
 Login Success: 
 iqn.2001-05.com.equallogic:0-8a0906-964f1f903-d850018d2a253d5f-nitishk521 
 if=default addr=10.115.178.29:3260 http://10.115.178.29:3260/ (TPGT:1 
 ISID:0x1)
 
 Why log Login authentication failed with target shows on iSCSI 
 login-redirect..?
 I think It's a bug and It should show the proper message.
 
 Regards,
 Nitish
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to open-iscsi+unsubscr...@googlegroups.com 
 mailto:open-iscsi+unsubscr...@googlegroups.com.
 To post to this group, send email to open-iscsi@googlegroups.com 
 mailto:open-iscsi@googlegroups.com.
 Visit this group at http://groups.google.com/group/open-iscsi 
 http://groups.google.com/group/open-iscsi.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: bulk writes in iSCSI

[Paul Koning]

On Nov 4, 2014, at 11:22 PM, shivraj dongawe shivraj...@gmail.com wrote:

 Dear Ulrich,
 
 Is there any concrete implementation available for scatter/gather 
 mechanism ?
 If available, how could we use with iSCSI initiator and target 
 combination?
 
 Thanks and Regards
 
 Shivraj K Dongawe

You may be talking about different things.

Scatter-gather is an OS service.  It takes a single I/O request (single SCSI 
operation) but splits the buffer up into several parts.  From the SCSI point of 
view you still see a single request: it addresses a single starting LBA and 
length.

I think Shrivraj was talking about a different notion that has been discussed a 
bit: a single SCSI command that combines several starting LBA/length pairs.  I 
don’t see any point in that; you can achieve the same result simply by queueing 
up multiple operations.  There might be a slight difference in network and I/O 
system overhead, but I can’t see a good reason to expect it to be significant.  
And the complexity of such a “multiple I/O operation” command would be 
substantial.

In any case, if such a thing were done it would be in SCSI, not iSCSI; it would 
be transparent to iSCSI.

paul


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: SHA-1 hashing Algorithm for CHAP

[Paul Koning]

I have never seen a spec for CHAP with any other hash algorithms.  No spec, so 
no implementations.

paul

On Sep 11, 2014, at 6:22 AM, Tejas vaykole tejas.vaykol...@gmail.com wrote:

 Hello,
 
 I am trying out with the open-iscsi initiator.I see that the initiator uses 
 MD5 algorithm for CHAP.
 I need help in configuring the initiator to use SHA-1 hashing Algorithm for 
 CHAP.
 
 Thanks.
 Tejas

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: SHA-1 hashing Algorithm for CHAP

[Paul Koning]

On Sep 15, 2014, at 1:19 PM, Mike Christie micha...@cs.wisc.edu wrote:

 On 09/11/2014 05:22 AM, Tejas vaykole wrote:
 Hello,
 
 I am trying out with the open-iscsi initiator.I see that the initiator
 uses MD5 algorithm for CHAP.
 I need help in configuring the initiator to use SHA-1 hashing Algorithm
 for CHAP.
 
 
 We only support MD5. The API use is hard coded, so there is no simple
 config step. You would have to write the code.
 
 What target are you using?

I don't think it matters;  there is no CHAP other than MD5 CHAP in the iSCSI 
standard.  See RFC 7143, page 228.  So there are *no* conforming 
implementations of CHAP for any other hash.

paul


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Getting log Login authentication failed with target .. during login-redirect

[Paul Koning]

On Jul 30, 2014, at 2:19 AM, KUMAR NITISH csnitish...@gmail.com wrote:

 Hi all,
 
 I am using Dell EqualLogic array as target. When I make session with this 
 target, I am getting logs as given below :
 
 login response status 0101
 Login authentication failed with target 
 iqn.2001-05.com.equallogic:0-8a0906-964f1f903-d850018d2a253d5f-nitishk521
 ...
 ..
 login response status 
 Login Success: 
 iqn.2001-05.com.equallogic:0-8a0906-964f1f903-d850018d2a253d5f-nitishk521 
 if=default addr=10.115.178.29:3260 (TPGT:1 ISID:0x1)
 
 
 Since login response status 0101 is for iscsi login-redirect , so why  
 Login authentication failed with target  message is coming..?
 I think It's a bug and It should show the proper log message.

You're right.  The RFC makes it clear that redirect is NOT an error.  It is 
incorrect for a message that reports a redirect to describe it as an error 
condition or a failure.  And in particular, it's clearly not an authentication 
failure.

paul

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Bad IPv6 address

[Paul Koning]

On Apr 9, 2011, at 12:33 AM, Mike Christie wrote:

 On 04/08/2011 07:52 PM, Paul Koning wrote:
 What made me look at this is the fact that I was getting errors connecting 
 to this address.  But now that I'm trying it again, it works just fine.  So 
 it's clearly a false alarm, sorry about that.
 
 
 Ah, if you are having problems it might be a bug or just laziness on the 
 iscsiadm side.

No, I was trying some other commands, like telnet or ping6, and must have made 
some dumb mistakes because it looked like I was having connectivity issues.  
Either that or my network was flaky.  Nothing to do with iscsi after all.

paul


-- 
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.

Bad IPv6 address

[Paul Koning]

I'm not sure if this is the right place to report this...

On my Linux system, when I have a connection to a target with IPv6, the address 
shown in /sys/class/iscsi_session/device/connection*/target_address is invalid. 
 For example, I've seen fc00:00:00:00:10:127:137:101 which is not a valid 
address (wrong number of bytes).

I can work around this by padding each component to 4 bytes, but that seems 
like a kluge.

I see this in Linux 2.6.18 (RHEL5).  Is this an old bug that's been fixed?

paul

-- 
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: [PATCH] iscsi: Simplify serial number comparisons

[Paul Koning]

On Apr 8, 2011, at 1:22 PM, Rustad, Mark D wrote:

 Ulrich,
 
 On Apr 7, 2011, at 11:35 PM, Ulrich Windl wrote:
 
 I just wonder how safe the code is:
 
 Doesn't the difference of two unsigned ints give an unsigned value? The 
 assigning an unsigned int to a signed int will definitely reduce the range...
 
 Actually, that isn't true. There are 2^32 possible values either way. The 
 only difference is the interpretation.
 
 I feel that 
 s32 diff = (s32) n1 - (s32) n2;
 
 Adding the casts does basically nothing here. They serve no purpose. In fact, 
 the original expresses the intent perfectly: subtract two unsigned integers 
 and treat the result as signed. That is precisely what is wanted. I used the 
 local variable, instead of casting, to be as crystal clear about that as 
 possible.

Actually, casting n1 and n2 to signed is a bad idea.  From what I remember, 
unsigned arithmetic is defined to be free of overflow; signed arithmetic can 
have overflow checks if the compiler and/or hardware chooses to do that.  The 
whole idea here is to rely on the wrapping properties of two's complement 
arithmetic modulo 2^n; what you really do *not* want is an overflow trap when 
that wrap occurs.   Instead you want to do the wrap silently, which is what an 
unsigned subtract does.

paul

-- 
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: iSCSI over WAN

[Paul Koning]

You might try supplying the target IP address manually instead of using the one 
obtained by discovery.

paul

On Mar 10, 2011, at 3:24 PM, ravi brounstein wrote:

 the server side is NAT actually. soi am hitting snags as it scans the wan ip, 
 finds the target, but as a NAT ip (local) not WAN ... so when I try to 
 connect it fails.
 
 Thank You,
 
 Ravi Brounstein
 Helpdesk Team
 Deus Machine, LLC
 http://www.deusmachine.com
 Tel. 877.840.6024 x 101
 
 On Mar 10, 2011, at 12:13 PM, Paul Koning paul_kon...@dell.com wrote:
 
 iSCSI over WAN doesn't make much sense.  
 
 You're right, the discovery machinery sends IP addresses, which won't work 
 if the target is behind NAT.  If you can tell the client to connect 
 directory to a configured target IP address, that might work.
 
 It sounds like your client side has NAT; I don't see why that would be a 
 problem.
 
 Still, you might want to change to some other protocol that's optimized for 
 WAN use.  While in theory nothing prevents iSCSI from working there, it was 
 certainly never considered a reasonable scenario.
 
   paul
 
 On Mar 9, 2011, at 6:00 PM, ravi brounstein wrote:
 
 Hey there,
 
 I have seen many places offering iSCSI storage over WAN.
 
 Currently I am using openfiler, and my question is what must be done
 to make iSCSI work in this way?
 
 Currently what I experience is that the iSCSI target shows up as the
 LAN address (I am behind NAT) so it fails to connect at the WAN
 address.
 

-- 
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: iSCSI over WAN

[Paul Koning]

iSCSI over WAN doesn't make much sense.  

You're right, the discovery machinery sends IP addresses, which won't work if 
the target is behind NAT.  If you can tell the client to connect directory to a 
configured target IP address, that might work.

It sounds like your client side has NAT; I don't see why that would be a 
problem.

Still, you might want to change to some other protocol that's optimized for WAN 
use.  While in theory nothing prevents iSCSI from working there, it was 
certainly never considered a reasonable scenario.

paul

On Mar 9, 2011, at 6:00 PM, ravi brounstein wrote:

 Hey there,
 
 I have seen many places offering iSCSI storage over WAN.
 
 Currently I am using openfiler, and my question is what must be done
 to make iSCSI work in this way?
 
 Currently what I experience is that the iSCSI target shows up as the
 LAN address (I am behind NAT) so it fails to connect at the WAN
 address.

-- 
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: Serial number comparison improvement

[Paul Koning]

On Mar 3, 2011, at 4:27 PM, Rustad, Mark D wrote:

 Folks,
 
 I noticed some code in libiscsi used for comparing serial numbers that I 
 think can be improved. Specifically this:
 
 /* Serial Number Arithmetic, 32 bits, less than, RFC1982 */
 #define SNA32_CHECK 2147483648UL
 
 static int iscsi_sna_lt(u32 n1, u32 n2)
 {
return n1 != n2  ((n1  n2  (n2 - n1  SNA32_CHECK)) ||
(n1  n2  (n2 - n1  SNA32_CHECK)));
 }
 
 /* Serial Number Arithmetic, 32 bits, less than, RFC1982 */
 static int iscsi_sna_lte(u32 n1, u32 n2)
 {
return n1 == n2 || ((n1  n2  (n2 - n1  SNA32_CHECK)) ||
(n1  n2  (n2 - n1  SNA32_CHECK)));
 }
 
 I think can better be done as:
 
 /* Serial Number Arithmetic, 32 bits, less than, RFC1982 */
 static int iscsi_sna_lt(u32 n1, u32 n2)
 {
   s32 diff = n1 - n2;
 
   return diff  0;
 }
 
 /* Serial Number Arithmetic, 32 bits, less than, RFC1982 */
 static int iscsi_sna_lte(u32 n1, u32 n2)
 {
   s32 diff = n1 - n2;
 
return diff = 0;
 }
 
 I think that this is both much clearer and should generate better code. I 
 have run a test comparing the two implementations, and they only differ on 
 numbers that are 2^31 apart, i.e. 0 and 0x8000 and other pairs similarly 
 spaced. According to RFC1982, these cases are arbitrary anyway.

Makes sense to me.  FWWI, RFC 1982 is wrong when it discusses that case: it 
claims that avoiding this indeterminacy would have the drawback that x  y does 
not necessarily imply x+1  y+1.  But that's clearly not true, and its own 
examples make that obvious.

paul

-- 
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: iSCSI SAN on copper 10Gbe

[Paul Koning]

10G is 10G -- so long as the cabling has been correctly built so the error rate 
is acceptably low, the performance will be the same as for any other PHY.

paul

On Aug 13, 2010, at 1:06 PM, Valerio wrote:

 Has anyone built an iSCSI SAN on 10Gbe copper and willing to share
 read/write performance numbers?
 
 Thanks,
 
 Valerio
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To post to this group, send email to open-is...@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-is...@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: Frequent Connection Errors with Dell Equallogic RAID

[Paul Koning]

 Evan == Evan Broder [EMAIL PROTECTED] writes:

 Evan Looking at the RAID configuration, we have the Group IP
 Evan address set to 10.5.128.128, and the member NIC's IP address
 Evan set to 10.5.128.129. The persistent portal os 10.5.128.128 on
 Evan all four servers, and the current portal is 10.5.128.129 on all
 Evan servers. It doesn't change after one of the connection errors.

That suggests the load balancer is not involved here.

You might check the event logs on the array to see if there are any
messages there around the same time.  

 paul


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---