iSCSI packet generator

[Bobby]

Hi

I have two virtual machines. One is a client and other is a sever (SAN). I am using Wireshark to  analyze the iSCSI protocols between them.

Someone recommended me, in addition to a packet analyzer, I can also use a packet generator. Any good packet generator for iSCSI client/server model?

Thanks

[Donald Williams]

Hello, 

 Can you provide a little more info?   iSCSI is for storage, so unless your 'server' is running an iSCSI target service there won't be 'iSCSI' traffic to monitor.  

 If you do have an iSCSI service running then providing a disk via that service to the 'client' then doing normal I/O to that iSCSI disk will provide all the traffic you will typically need.  I.e. discovering the device, formatting the disk, doing writes and reads, etc.  

 What is it that you are trying to do?   iSCSI is the transport for SCSI commands over a network.   You can use SCSI tools to generate SCSI commands to that disk, then the iSCSI initiator on the 'client' will create the respective iSCSI packets. 

 Regards,

Don 

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/8a89dcdb-8fae-4c97-9a76-db621b01bcaf%40googlegroups.com.

[The Lee-Man]

Your question is not clear, but I'm guessing  you are asking if you can use some sort of software to inject iSCSI packets into your client/server stream, e.g. so that you can simulate errors and see how your software handles them?

If so, then the answer is no, there is nothing I know of.

Such "bad command injection" can be done with fancy hardware analyzers. A good (expensive) network analyzer can (I believe) inject bad packets of any type.See https://www.firewalltechnical.com/packet-injection-tools/

It sound like none of this is directly related to open-iscsi, though.

[Bobby]

Hi Donald,

Hi The Lee-man,

Thanks for the reply. Both replies were helpful and both replies actually clarified my concepts. And I realized, the question was not clear....You were kind enough to reply in detail even when the question of was not clear !

The Lee-man, your guess was right. I was thinking something like that and I realized it makes no sense.

Donald: Yes, you are right. I took this point of yous "then doing normal I/O to that iSCSI disk will provide all the traffic you will typically need"....the wireshark showed me ! 

I'm a novice in Open-iSCSI yet very much interested in it. Please excuse my simple questions. It is written, Open-iSCSI acts as "kernel driver" between "block layer" and "network layer". Therefore following two questions:

- Linux block layer perform IO scheduling IO submissions to storage device driver. If there is a physical device, the block layer interacts with it through SCSI mid layer and SCSI low level drivers. So, how *actually* a software initiator (Open-iSCSI) interacts with "block layer"?  I will be really grateful if you can explain me. 

- What confuses me, where does the "disk driver" comes into play?

Thanks :-)

[Bobby]

Hi Donald,

Hi Lee-man,

Thanks for the reply. Both replies were helpful and both replies actually clarified my concepts. And I realized, the question was not clear....You were kind enough to reply in detail even when the question of was not clear !

The Lee-man, your guess was right. I was thinking something like that and I realized it makes no sense.

Donald: Yes, you are right. I took this point of yous "then doing normal I/O to that iSCSI disk will provide all the traffic you will typically need"....the wireshark showed me ! 

I'm a complete novice in Open-iSCSI yet very much interested in it. Please excuse my simple questions. It is written, Open-iSCSI acts as "kernel driver" between "block layer" and "network layer". Therefore following two questions:

- Linux block layer perform IO scheduling IO submissions to storage device driver. If there is a physical device, the block layer interacts with it through SCSI mid layer and SCSI low level drivers. So, how *actually* a software initiator (Open-iSCSI) interacts with "block layer"?  I will be really grateful if you can explain me. 

- What confuses me, where does the "disk driver" comes into play?

Thanks :-)

On Monday, November 4, 2019 at 2:32:00 PM UTC+1, Donald Williams wrote:

Hello, 

 Can you provide a little more info?   iSCSI is for storage, so unless your 'server' is running an iSCSI target service there won't be 'iSCSI' traffic to monitor.  

 If you do have an iSCSI service running then providing a disk via that service to the 'client' then doing normal I/O to that iSCSI disk will provide all the traffic you will typically need.  I.e. discovering the device, formatting the disk, doing writes and reads, etc.  

 What is it that you are trying to do?   iSCSI is the transport for SCSI commands over a network.   You can use SCSI tools to generate SCSI commands to that disk, then the iSCSI initiator on the 'client' will create the respective iSCSI packets. 

 Regards,

Don 

On Mon, Nov 4, 2019 at 5:49 AM Bobby <italien...@gmail.com> wrote:

Hi

I have two virtual machines. One is a client and other is a sever (SAN). I am using Wireshark to  analyze the iSCSI protocols between them.

Someone recommended me, in addition to a packet analyzer, I can also use a packet generator. Any good packet generator for iSCSI client/server model?

Thanks

--
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-...@googlegroups.com.

[Ulrich Windl]

Hi!

Just a note of curiosity: Several years ago I wanted to test some RAID configurations, but had no server with enough disks. However the server had a lot of RAM (by that time). So I ended with creating a few small ramdisks which I exported as iSCSI devices. The host was happy with those "disks".
In the meantime the devicemapper can even inject "I/O errors", so maybe you can build a useful scenario for some basic tests. Like this:
---
DEV=bad_disk
dmsetup create "$DEV" <<EOF
0 8 zero
8 1 error
9 7 zero
16 1 error
17 255 zero
EOF
---

Regards,
Ulrich

>>> Bobby <italien...@gmail.com> schrieb am 06.11.2019 um 22:49 in Nachricht
<0c2592cf-ad61-4fe4...@googlegroups.com>:

> Hi Donald,
> Hi The Lee-man,
>
> Thanks for the reply. Both replies were helpful and both replies actually
> clarified my concepts. And I realized, the question was not clear....You
> were kind enough to reply in detail even when the question of was not clear
> !
>

> *The Lee-man*, your guess was right. I was thinking something like that and

> I realized it makes no sense.
>

> *Donald*: Yes, you are right. I took this point of yous "*then doing normal

> I/O to that iSCSI disk will provide all the traffic you will typically

> need*"....the

> wireshark showed me !
>
> I'm a novice in Open-iSCSI yet very much interested in it. Please excuse my

> simple questions. It is written, Open-iSCSI acts as "*kernel driver*"
> between "*block layer*" and "*network layer*". Therefore following two

> questions:
>
> - Linux block layer perform IO scheduling IO submissions to storage device
> driver. If there is a physical device, the block layer interacts with it
> through SCSI mid layer and SCSI low level drivers. So, how *actually* a

> software initiator (*Open-iSCSI*) interacts with "*block layer*"? I will

> be really grateful if you can explain me.
>

> - What confuses me, where does the "*disk driver*" comes into play?

>
> Thanks :-)
>
>
> On Monday, November 4, 2019 at 5:43:24 PM UTC+1, The Lee-Man wrote:
>>
>> On Monday, November 4, 2019 at 2:49:08 AM UTC-8, Bobby wrote:
>>>
>>> Hi
>>>
>>> I have two virtual machines. One is a client and other is a sever (SAN).
>>> I am using Wireshark to analyze the iSCSI protocols between them.
>>>
>>> Someone recommended me, in addition to a packet analyzer, I can also use
>>> a packet generator. Any good packet generator for iSCSI client/server model?
>>>
>>> Thanks
>>>
>>

>> Your question is not clear, but I'm *guessing* you are asking if you can

>> use some sort of software to inject iSCSI packets into your client/server
>> stream, e.g. so that you can simulate errors and see how your software
>> handles them?
>>
>> If so, then the answer is no, there is nothing I know of.
>>
>> Such "bad command injection" can be done with fancy hardware analyzers. A
>> good (expensive) network analyzer can (I believe) inject bad packets of any
>> type.See https://www.firewalltechnical.com/packet-injection-tools/
>>
>> It sound like none of this is directly related to open-iscsi, though.
>>
>

> --
> 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+...@googlegroups.com.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/open-iscsi/0c2592cf-ad61-4fe4-8006-63edabe4
> af7f%40googlegroups.com.

[Bobby]

Hi Ulrich,

Thanks for the hint. Can you please help me regarding following two questions. 

- Linux block layer perform IO scheduling IO submissions to storage device driver. If there is a physical device, the block layer interacts with it through SCSI mid layer and SCSI low level drivers. So, how *actually* a software initiator (Open-iSCSI) interacts with "block layer"? 

- What confuses me, where does the "disk driver" comes into play?

Thanks :-)

[Donald Williams]

Hello, 

 

 iSCSI is just a transport method for SCSI commands.  Same as Fibre Channel, SAS, etc.. 

 When the network takes in the iSCSI packets, the SCSI commands and data are separated and they go to their respective devices or 'disks' in this case. 

 Regards 

Don

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/1972273e-83e5-4e7f-9c76-00d0deb31185%40googlegroups.com.

[The Lee-Man]

In an iSCSI connection (session), there is the initiator and the target. I assume you are talking about the initiator.

On the initiator, the "magic" is done by the kernel, in particular the iSCSI initiator code in the kernel, specifically by the scsi_transport_iscsi.c in drivers/scsi. When an iSCSI connection is made, the code creates a new "host" object, and then tests the device at the other end of the connection. If it's a disc drive, then an instance of sd is created (the disc driver). If the device is tape, a tape driver is instantiated (st). Unrecognized devices still get a generic SCSI device node, I believe.

So, in this way, iSCSI is acting like an adapter driver, which plugs into the SCSI mid-layer.

You can run "sudo journalctl -xe --follow" in one window, then log into an existing target in another (I used "sudo iscsiadm -m node -l"), and you should see this kind of output from journalctl:

...

 

Nov 09 10:46:59 linux-dell kernel: iscsi: registered transport (tcp)
Nov 09 10:46:59 linux-dell kernel: scsi host3: iSCSI Initiator over TCP/IP
Nov 09 10:46:59 linux-dell iscsid[13175]: iscsid: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.linux-dell.x8664:sn.2a6e21b1b53c, portal: 192.168.20.3,3260] through [iface: default] is operational now
Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: Direct-Access     LIO-ORG  test-disc        4.0  PQ: 0 ANSI: 5
Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: alua: supports implicit and explicit TPGS
Nov 09 10:46:59 linux-dell kernel: scsi 3:0:0:0: alua: device naa.6001405de01c6e7933b414e901e22b0f port group 0 rel port 1
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: Attached scsi generic sg1 type 0
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB)
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Write Protect is off
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 10 08
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
Nov 09 10:46:59 linux-dell kernel: iSCSI/iqn.1996-04.de.suse:01:54cab487975b: Unsupported SCSI Opcode 0xa3, sending CHECK_CONDITION.
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Optimal transfer size 8388608 bytes
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: [sdb] Attached SCSI disk
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: alua: transition timeout set to 60 seconds
Nov 09 10:46:59 linux-dell kernel: sd 3:0:0:0: alua: port group 00 state A non-preferred supports TOlUSNA

   ...

[Bobby]

Perfect ! After this reply, I had to dig deeper and now it makes sense....thanks a lot The Lee-Man for explaining it so effectively...

[Bobby]

Like above, can you please give me more hints/clues in which other code(s) I need to see. Which part of this gigantic MQ-Block layer code base to see to understand the complete data flow? I am particularly interested in Hash , Map data structures. 

[The Lee-Man]

On Tuesday, December 10, 2019 at 4:20:28 AM UTC-8, Bobby wrote:

Like above, can you please give me more hints/clues in which other code(s) I need to see. Which part of this gigantic MQ-Block layer code base to see to understand the complete data flow? I am particularly interested in Hash , Map data structures. 

No, not really.

There are many great resources for learning about the kernel and its drivers, and the block layer. For example, join lwn.net and checkout https://lwn.net/Articles/736534/

And there are many great books, such as Linux Kernel Development.