scsi traffic sniffing

scsi traffic sniffing

[Jonathan Nell]

Is there any way to sniff the traffic of a scsi device? I need to
debug a firmware update and need to see the traffic being passed to
the drive

Re: scsi traffic sniffing

[谢纲]

On Tue, Sep 1, 2009 at 2:13 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
> Is there any way to sniff the traffic of a scsi device? I need to
> debug a firmware update and need to see the traffic being passed to
> the drive
You may hook the queue_command function of the scsi host. It can sniff
all scsi request to scsi host driver.
Thanks,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Xie Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi traffic sniffing

[Stefan Richter]

谢纲 wrote:
> On Tue, Sep 1, 2009 at 2:13 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
>> Is there any way to sniff the traffic of a scsi device? I need to
>> debug a firmware update and need to see the traffic being passed to
>> the drive
> You may hook the queue_command function of the scsi host. It can sniff
> all scsi request to scsi host driver.

Actually you can switch on logging of commands and status (though not of 
data) at runtime by something like
# echo $BITMASK > /sys/module/scsi_mod/parameters/scsi_logging_level
or
# echo $BITMASK > /proc/sys/dev/scsi/logging_level
provided that the kernel's SCSI core was compiled with 
CONFIG_SCSI_LOGGING=y.

Bitmask values can be constructed as in 
linux/drivers/scsi/scsi_logging.h.  Long ago I made a note that 9216 as 
bitmask was useful for my purposes, but don't ask me what that means.

For data logging, you have to modify the SCSI low-level driver or SCSI 
core indeed.

However, all this applies only if the firmware updater actually runs on 
a Linux initiator, not e.g. on an MS Windows initiator.  In the latter 
case, you need a debug driver which hooks into Windows' SCSI stack, or 
some sort of bus analyzer.
-- 
Stefan Richter
-=====-==--= =--= ----=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi traffic sniffing

[谢纲]

On Tue, Sep 1, 2009 at 6:40 PM, 谢纲<xiegang112@gmail.com> wrote:
> On Tue, Sep 1, 2009 at 2:13 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
>> Is there any way to sniff the traffic of a scsi device? I need to
>> debug a firmware update and need to see the traffic being passed to
>> the drive
> You may hook the queue_command function of the scsi host. It can sniff
> all scsi request to scsi host driver.
> Thanks,

I developed a tool to dump all the SCSI cmds to SCSI device. The idea
is, every SCSI host controller driver should give the queue_command
fucntion. This is the entrance for SCSI request to SCSI host
controller driver. I replace this function with my own dump methord
and after dump, I restore this function.

I do't know if it's what you need.

Thanks,
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Xie Gang
>



-- 
Xie Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi traffic sniffing

[Jonathan Nell]

2009/9/2 谢纲 <xiegang112@gmail.com>:
> On Tue, Sep 1, 2009 at 6:40 PM, 谢纲<xiegang112@gmail.com> wrote:
>> On Tue, Sep 1, 2009 at 2:13 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
>>> Is there any way to sniff the traffic of a scsi device? I need to
>>> debug a firmware update and need to see the traffic being passed to
>>> the drive
>> You may hook the queue_command function of the scsi host. It can sniff
>> all scsi request to scsi host driver.
>> Thanks,
>
> I developed a tool to dump all the SCSI cmds to SCSI device. The idea
> is, every SCSI host controller driver should give the queue_command
> fucntion. This is the entrance for SCSI request to SCSI host
> controller driver. I replace this function with my own dump methord
> and after dump, I restore this function.
>
> I do't know if it's what you need.

That would be great! Could you send the code to me? How does your tool
hook into queue_command?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi traffic sniffing

[谢纲]

2009/9/2 Jonathan Nell <crtrn13@gmail.com>:
> 2009/9/2 谢纲 <xiegang112@gmail.com>:
>> On Tue, Sep 1, 2009 at 6:40 PM, 谢纲<xiegang112@gmail.com> wrote:
>>> On Tue, Sep 1, 2009 at 2:13 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
>>>> Is there any way to sniff the traffic of a scsi device? I need to
>>>> debug a firmware update and need to see the traffic being passed to
>>>> the drive
>>> You may hook the queue_command function of the scsi host. It can sniff
>>> all scsi request to scsi host driver.
>>> Thanks,
>>
>> I developed a tool to dump all the SCSI cmds to SCSI device. The idea
>> is, every SCSI host controller driver should give the queue_command
>> fucntion. This is the entrance for SCSI request to SCSI host
>> controller driver. I replace this function with my own dump methord
>> and after dump, I restore this function.
>>
>> I do't know if it's what you need.
>
> That would be great! Could you send the code to me? How does your tool
> hook into queue_command?
The code could be found at
http://blog.chinaunix.net/u/15278/showart_1966962.html. You need do
some modification according your kernel.
It's very simple to hook the queue_command. I just backup the original
function pointer somewhere and after dump, I restore it. Pls refer the
code for detail.

Thanks,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Xie Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi traffic sniffing

[Jonathan Nell]

>>>
>>> I developed a tool to dump all the SCSI cmds to SCSI device. The idea
>>> is, every SCSI host controller driver should give the queue_command
>>> fucntion. This is the entrance for SCSI request to SCSI host
>>> controller driver. I replace this function with my own dump methord
>>> and after dump, I restore this function.
>>>
>>> I do't know if it's what you need.
>>
>> That would be great! Could you send the code to me? How does your tool
>> hook into queue_command?

> The code could be found at
> http://blog.chinaunix.net/u/15278/showart_1966962.html. You need do
> some modification according your kernel.
> It's very simple to hook the queue_command. I just backup the original
> function pointer somewhere and after dump, I restore it. Pls refer the
> code for detail.
>

This is great - thanks! I assume I can just modify this slightly to
dump the data as well (and not just the cmd)?

Re: scsi traffic sniffing

[Xie Gang]

On Wed, Sep 2, 2009 at 2:48 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
>>>>
>>>> I developed a tool to dump all the SCSI cmds to SCSI device. The idea
>>>> is, every SCSI host controller driver should give the queue_command
>>>> fucntion. This is the entrance for SCSI request to SCSI host
>>>> controller driver. I replace this function with my own dump methord
>>>> and after dump, I restore this function.
>>>>
>>>> I do't know if it's what you need.
>>>
>>> That would be great! Could you send the code to me? How does your tool
>>> hook into queue_command?
>
>> The code could be found at
>> http://blog.chinaunix.net/u/15278/showart_1966962.html. You need do
>> some modification according your kernel.
>> It's very simple to hook the queue_command. I just backup the original
>> function pointer somewhere and after dump, I restore it. Pls refer the
>> code for detail.
>>
>
> This is great - thanks! I assume I can just modify this slightly to
> dump the data as well (and not just the cmd)?
Of course, when you get the scsi cmd, you can get the request where
data lives in.
BTW, I don't use this driver under heavey load. There might be some
performance issue. You can kick off the filter part.

Thanks,
Gang
>



-- 
Xie Gang

Re: scsi traffic sniffing

[Jonathan Nell]

>> This is great - thanks! I assume I can just modify this slightly to
>> dump the data as well (and not just the cmd)?
> Of course, when you get the scsi cmd, you can get the request where
> data lives in.
> BTW, I don't use this driver under heavey load. There might be some
> performance issue. You can kick off the filter part.
>
> Thanks,
> Gang
>>

Hmmm kills my pc when loaded into my kernel (2.6.30)... What kernel
version did you last use this with?

Re: scsi traffic sniffing

[Xie Gang]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Wed, Sep 2, 2009 at 3:50 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
>>> This is great - thanks! I assume I can just modify this slightly to
>>> dump the data as well (and not just the cmd)?
>> Of course, when you get the scsi cmd, you can get the request where
>> data lives in.
>> BTW, I don't use this driver under heavey load. There might be some
>> performance issue. You can kick off the filter part.
>>
>> Thanks,
>> Gang
>>>
>
> Hmmm kills my pc when loaded into my kernel (2.6.30)... What kernel
> version did you last use this with?
O, it's my bad. I don't update the codes.
Pls try the new attached. It works on the  RHEL5 2.6.18-128.el5.
Thanks,
>



-- 
Xie Gang

[-- Attachment #2: scsidump.tar --]
[-- Type: application/x-tar, Size: 51200 bytes --]

Re: scsi traffic sniffing

[Jonathan Nell]

>> Hmmm kills my pc when loaded into my kernel (2.6.30)... What kernel
>> version did you last use this with?
> O, it's my bad. I don't update the codes.
> Pls try the new attached. It works on the  RHEL5 2.6.18-128.el5.

Thanks Xie but still causes a system crash unfortunately...

...I think that maybe the easiest way would be to rebuild the kernel
with aptly-placed prink()s.
But where's the best place to dump? I inserted into
scsi_lib.c:scsi_execute() and that does dump commands, but doesn't
seem to give me what I want. Just to clarify, I am running a dvd-drive
firmware update in a vmware VM (windows xp guest). I have the
dvd-drive (/dev/sr1) connected in the VM as a scsi device. I would
like to print out ALL traffic to /dev/sr1 - whether generated in the
VM or not - and i need both the cmds and the data in both directions.
I'm just not familiar with the scsi kernel code and there's quite a
lot of things going on there so if anyone could tell me where the best
place to put my printk()s in the kernel code would be - that would be
great!
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi traffic sniffing

[Grant Grundler]

On Mon, Aug 31, 2009 at 11:13 PM, Jonathan Nell<crtrn13@gmail.com> wrote:
> Is there any way to sniff the traffic of a scsi device? I need to
> debug a firmware update and need to see the traffic being passed to
> the drive

The ideal tool is a protocol analyzer for whatever transport the SCSI
device is attached to.
Here's the slide deck from a talk I once gave at OLS outlining the HW
debug tools:
    http://iou.parisc-linux.org/ols_2001/slides/generated/

(and "SCSI" in that slide deck often means Parallel SCSI transport.)

Using the scsi_logging hooks described by Stefan Richter are often enough
to understand where in the process something is failing.

hth,
grant

Re: scsi traffic sniffing

[Grant Grundler]

+linux-scsi

On Tue, Sep 1, 2009 at 9:17 AM, Jonathan Nell<crtrn13@gmail.com> wrote:
> 2009/9/1 Grant Grundler <grundler@google.com>:
>> The ideal tool is a protocol analyzer for whatever transport the SCSI
>> device is attached to.
>> Here's the slide deck from a talk I once gave at OLS outlining the HW
>> debug tools:
>>    http://iou.parisc-linux.org/ols_2001/slides/generated/
>>
>> (and "SCSI" in that slide deck often means Parallel SCSI transport.)
>>
>> Using the scsi_logging hooks described by Stefan Richter are often enough
>> to understand where in the process something is failing.
>>
>> hth,
>> grant
>>
>
> Unfortunately I need a data dump as well so the scsi_logging hooks
> aren't going to do the job I believe.

IMHO, if a data dump is needed, a logic analyzer is probably the right tool.
Which transport is being used here?

Folks might have suggestions on tools that are available. Often those can
be rented for a few days/week at a time.


> My next though was to wrap the
> SG_IO ioctl call (i.e. trap it in the kernel) and have that dump the
> data from (struct sg_io_hdr).dxferp. (The ioctl sniffer would be
> useful anyway for other things).

The drawback here is it only tells you what data is being handed to
the interface card, not what data is sent to the device or how it is
sent exactly (framing, timing, etc).


> Having issues with doing the kernel trap in the newer kernel versions
> though (trying on 2.6.30). The syscall table is now read-only but for
> some reason my set_memory_rw() call is failing... Any ideas how to do
> this properly?

Nope, sorry. At least not offhand.

cheers,
grant

>
> Here are the relevant bits of code:
>
> unsigned long **find_sys_call_table(void)
> {
>   unsigned long **sctable;
>   unsigned long ptr;
>
>   sctable = NULL;
>   for (ptr = (unsigned long)&unlock_kernel;
>        ptr < (unsigned long)&loops_per_jiffy;
>        ptr += sizeof(void *))
>   {
>      unsigned long *p;
>      p = (unsigned long *)ptr;
>      if (p[__NR_close] == (unsigned long) sys_close)
>      {
>         sctable = (unsigned long **)p;
>         return &sctable[0];
>      }
>   }
>   return NULL;
> }
>
> static int __init scsisniff_init_module(void)
> {
>        if ( (sys_call_table = find_sys_call_table()) ) {
>            real_ioctl = (int(*)(unsigned int fd, unsigned int cmd,
> unsigned long arg))sys_call_table[__NR_ioctl];
>
>                if ( set_memory_rw( (unsigned
> long)sys_call_table[__NR_ioctl], 1 ) )
>                        printk( "set_memory_rw: succeeded\n" );
>                else {
>                        printk( "set_memory_rw: failed!\n" );
>                      return -1;
>                }
>
>                sys_call_table[__NR_ioctl] = (unsigned long)my_ioctl;
>        }
>        else {
>                return -1;
>        }
>      return 0;
> }
>
> This gives me a lovely OOPS:
>
> [   71.143742] WARNING: at arch/x86/mm/pageattr.c:833
> change_page_attr_set_clr+0x1a0/0x400()
> [   71.143745] Modules linked in: scsi_sniff(+) i915 binfmt_misc drm
> i2c_algo_bit bridge stp bnep lp snd_hda_codec_analog snd_hda_intel
> snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm
> snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
> snd_seq snd_timer snd_seq_device video snd psmouse tpm_infineon tpm
> ppdev soundcore serio_raw pcspkr intel_agp tpm_bios output heci(C)
> iTCO_wdt iTCO_vendor_support parport_pc parport snd_page_alloc floppy
> usbhid usb_storage e1000e
> [   71.143768] Pid: 3378, comm: insmod Tainted: G         C
> 2.6.30.4custom-1.0 #6
> [   71.143769] Call Trace:
> [   71.143773]  [<ffffffff802da6d5>] ? __vunmap+0xc5/0x110
> [   71.143775]  [<ffffffff80235200>] ? change_page_attr_set_clr+0x1a0/0x400
> [   71.143778]  [<ffffffff8024edf8>] warn_slowpath_common+0x78/0xd0
> [   71.143780]  [<ffffffff8024ee5f>] warn_slowpath_null+0xf/0x20
> [   71.143783]  [<ffffffff80235200>] change_page_attr_set_clr+0x1a0/0x400
> [   71.143785]  [<ffffffffa0274050>] ? my_ioctl+0x0/0x120 [scsi_sniff]
> [   71.143789]  [<ffffffff802a6dcd>] ? marker_update_probe_range+0x1dd/0x2d0
> [   71.143791]  [<ffffffffa0277000>] ? scsisniff_init_module+0x0/0xf4
> [scsi_sniff]
> [   71.143793]  [<ffffffff80235b9a>] set_memory_rw+0x2a/0x30
> [   71.143796]  [<ffffffff802ff000>] ? sys_fcntl+0x180/0x420
> [   71.143798]  [<ffffffffa02770bb>] scsisniff_init_module+0xbb/0xf4
> [scsi_sniff]
> [   71.143801]  [<ffffffff8020a04c>] do_one_initcall+0x3c/0x180
> [   71.143804]  [<ffffffff8026b7f3>] ? __blocking_notifier_call_chain+0x63/0x80
> [   71.143807]  [<ffffffff8027dc0d>] sys_init_module+0xad/0x200
> [   71.143810]  [<ffffffff80210fc2>] system_call_fastpath+0x16/0x1b
> [   71.143812] ---[ end trace 5b3efe312296b587 ]---
> [   71.143958] set_memory_rw: failed!
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi traffic sniffing

[Ric Wheeler]

On 09/01/2009 12:48 PM, Grant Grundler wrote:
> +linux-scsi
>
> On Tue, Sep 1, 2009 at 9:17 AM, Jonathan Nell<crtrn13@gmail.com>  wrote:
>    
>> 2009/9/1 Grant Grundler<grundler@google.com>:
>>      
>>> The ideal tool is a protocol analyzer for whatever transport the SCSI
>>> device is attached to.
>>> Here's the slide deck from a talk I once gave at OLS outlining the HW
>>> debug tools:
>>>     http://iou.parisc-linux.org/ols_2001/slides/generated/
>>>
>>> (and "SCSI" in that slide deck often means Parallel SCSI transport.)
>>>
>>> Using the scsi_logging hooks described by Stefan Richter are often enough
>>> to understand where in the process something is failing.
>>>
>>> hth,
>>> grant
>>>
>>>        
>> Unfortunately I need a data dump as well so the scsi_logging hooks
>> aren't going to do the job I believe.
>>      
> IMHO, if a data dump is needed, a logic analyzer is probably the right tool.
> Which transport is being used here?
>
> Folks might have suggestions on tools that are available. Often those can
> be rented for a few days/week at a time.
>    

You can get specific analyzers for storage protocols (Fibre channel, 
s-ata, SAS, etc). They can be pricey (especially if you need to monitor 
multiple devices with a multi-port analyzer)

ric

>
>    
>> My next though was to wrap the
>> SG_IO ioctl call (i.e. trap it in the kernel) and have that dump the
>> data from (struct sg_io_hdr).dxferp. (The ioctl sniffer would be
>> useful anyway for other things).
>>      
> The drawback here is it only tells you what data is being handed to
> the interface card, not what data is sent to the device or how it is
> sent exactly (framing, timing, etc).
>
>
>    
>> Having issues with doing the kernel trap in the newer kernel versions
>> though (trying on 2.6.30). The syscall table is now read-only but for
>> some reason my set_memory_rw() call is failing... Any ideas how to do
>> this properly?
>>      
> Nope, sorry. At least not offhand.
>
> cheers,
> grant
>
>    
>> Here are the relevant bits of code:
>>
>> unsigned long **find_sys_call_table(void)
>> {
>>    unsigned long **sctable;
>>    unsigned long ptr;
>>
>>    sctable = NULL;
>>    for (ptr = (unsigned long)&unlock_kernel;
>>         ptr<  (unsigned long)&loops_per_jiffy;
>>         ptr += sizeof(void *))
>>    {
>>       unsigned long *p;
>>       p = (unsigned long *)ptr;
>>       if (p[__NR_close] == (unsigned long) sys_close)
>>       {
>>          sctable = (unsigned long **)p;
>>          return&sctable[0];
>>       }
>>    }
>>    return NULL;
>> }
>>
>> static int __init scsisniff_init_module(void)
>> {
>>         if ( (sys_call_table = find_sys_call_table()) ) {
>>             real_ioctl = (int(*)(unsigned int fd, unsigned int cmd,
>> unsigned long arg))sys_call_table[__NR_ioctl];
>>
>>                 if ( set_memory_rw( (unsigned
>> long)sys_call_table[__NR_ioctl], 1 ) )
>>                         printk( "set_memory_rw: succeeded\n" );
>>                 else {
>>                         printk( "set_memory_rw: failed!\n" );
>>                       return -1;
>>                 }
>>
>>                 sys_call_table[__NR_ioctl] = (unsigned long)my_ioctl;
>>         }
>>         else {
>>                 return -1;
>>         }
>>       return 0;
>> }
>>
>> This gives me a lovely OOPS:
>>
>> [   71.143742] WARNING: at arch/x86/mm/pageattr.c:833
>> change_page_attr_set_clr+0x1a0/0x400()
>> [   71.143745] Modules linked in: scsi_sniff(+) i915 binfmt_misc drm
>> i2c_algo_bit bridge stp bnep lp snd_hda_codec_analog snd_hda_intel
>> snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm
>> snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
>> snd_seq snd_timer snd_seq_device video snd psmouse tpm_infineon tpm
>> ppdev soundcore serio_raw pcspkr intel_agp tpm_bios output heci(C)
>> iTCO_wdt iTCO_vendor_support parport_pc parport snd_page_alloc floppy
>> usbhid usb_storage e1000e
>> [   71.143768] Pid: 3378, comm: insmod Tainted: G         C
>> 2.6.30.4custom-1.0 #6
>> [   71.143769] Call Trace:
>> [   71.143773]  [<ffffffff802da6d5>] ? __vunmap+0xc5/0x110
>> [   71.143775]  [<ffffffff80235200>] ? change_page_attr_set_clr+0x1a0/0x400
>> [   71.143778]  [<ffffffff8024edf8>] warn_slowpath_common+0x78/0xd0
>> [   71.143780]  [<ffffffff8024ee5f>] warn_slowpath_null+0xf/0x20
>> [   71.143783]  [<ffffffff80235200>] change_page_attr_set_clr+0x1a0/0x400
>> [   71.143785]  [<ffffffffa0274050>] ? my_ioctl+0x0/0x120 [scsi_sniff]
>> [   71.143789]  [<ffffffff802a6dcd>] ? marker_update_probe_range+0x1dd/0x2d0
>> [   71.143791]  [<ffffffffa0277000>] ? scsisniff_init_module+0x0/0xf4
>> [scsi_sniff]
>> [   71.143793]  [<ffffffff80235b9a>] set_memory_rw+0x2a/0x30
>> [   71.143796]  [<ffffffff802ff000>] ? sys_fcntl+0x180/0x420
>> [   71.143798]  [<ffffffffa02770bb>] scsisniff_init_module+0xbb/0xf4
>> [scsi_sniff]
>> [   71.143801]  [<ffffffff8020a04c>] do_one_initcall+0x3c/0x180
>> [   71.143804]  [<ffffffff8026b7f3>] ? __blocking_notifier_call_chain+0x63/0x80
>> [   71.143807]  [<ffffffff8027dc0d>] sys_init_module+0xad/0x200
>> [   71.143810]  [<ffffffff80210fc2>] system_call_fastpath+0x16/0x1b
>> [   71.143812] ---[ end trace 5b3efe312296b587 ]---
>> [   71.143958] set_memory_rw: failed!
>>
>>      
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: scsi traffic sniffing

[Bart Van Assche]

On Tue, Sep 1, 2009 at 8:13 AM, Jonathan Nell <crtrn13@gmail.com> wrote:
> Is there any way to sniff the traffic of a scsi device? I need to
> debug a firmware update and need to see the traffic being passed to
> the drive

One possible approach is to access the device via iSCSI and to capture
the iSCSI traffic with a network analyzer, e.g. Wireshark. You will
have to install and configure iSCSI target software before you can do
this.

Bart.