> 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
> 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.
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
> 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
> 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:
> 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
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
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
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
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.
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
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
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
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
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
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
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
) 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
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
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
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
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
22 matches
Mail list logo