View source for Bus snooping/sniffing

Purpose and relevance to development work -- description coming soon

==PCI / PCIe == 
===Snooping Utilities:===
* BTSpy [http://btwincap.sourceforge.net/custom.html] - Windows based snoop for BT8x8 based devices
* Dscaler's RegSpy [http://www.dscaler.com/] - Windows based; contains the ability to snoop the registers of [[Interface chipsets|PCI / PCIe interface chipsets]] ... also see [http://marc.info/?l=linux-dvb&m=122823618002379&w=2 this note]

==USB ==
===Snooping Utilities:===
* [[usbsnoop]] - a Windows based utility for sniffing/monitoring communications traffic for a USB device.  Note: In case usbsnoop/SniffUSB doesn't work for you, here are a few time limited apps that should work under Vista:
** [http://www.hhdsoftware.com/Family/usb-monitor.html USB Monitor] - 14-day trial period
** [http://www.usblyzer.com/ USBlyzer] - fully functional evaluation version for 33 days
* SnoopyPro - Windows based snoop for USB device communications traffic
* usbsnoop/SniffUSB - Windows based snoop for USB device communications traffic
* usbmon - Linux kernel module which can snoop USB device communications traffic
** Wireshark - logs usbmon output, via libpcap
** USBMon - logs usbmon output

===Log parsers, format etc===

* [[usbmon2usbsnoop]]
* [[http://linuxtv.org/hg/v4l-dvb/raw-file/tip/v4l2-apps/util/parse_em28xx.pl em28xx log parser]]
...

===Snooping Procedures:===
* Use a Snopping utility to get the log. 
* Group URB transactions into a shorter log by using a parser
* Identify the URB transactions at the control endpoint. URB transactions look like those:

40 02 00 00 ba 00 03 00 >>> 20 11 00

{| class="wikitable" 
|+'''URB fields'''
|-
| Byte || Meaning
|-
| 1 || {| bit 7 = 1 - IN / 0 - OUT
bit 6 = 1 - Vendor Class
|-
| 2 || URB Request
|-
| 3-4 || URB Value in big endian 
|-
| 5-6 || URB Index in big endian 
|-
| 7-8 || URB message size in big endian 
|-
|}

For example, let's analyse the folowing URB's:

{| class="wikitable" 
|+'''control URB examples '''
|-
| URB sequence log (URB setup + URB IN or OUT) || Byte 1 || Byte 2 || Bytes 3-4 || Bytes 5-6 || Bytes 7-8 || Message
|-
| 40 00 00 00 08 00 01 00 >>> 3d || USB OUT,  Vendor Class || Req = 0x00 || Value = 0x0000 || Index = 0x0008 || Size = 0x0001 || { 0x3d }
|-
| 40 02 00 00 ba 00 03 00 >>> 20 11 00 || USB OUT, Vendor Class || Req = 0x02 || Value = 0x0000 || Index = 0x00ba || Size = 0x0003 ||{ 0x20, 0x11, 0x00 }
|-
| c0 00 00 00 15 00 01 00 <<< 00 || USB IN, Vendor Class || Req = 0x00 || Value = 0x0000 || Index = 0x0015 || Size = 0x0001 || { 0x00 }
|}


After getting the log, you should analyse and understand the meaning of each of URB fields on your device.

For example, in the case of [[Em28xx Devices | em28xx]], Req is used to indicate internal registers or I2C, Value is always 0 and Index indicates what device register is being used.

On em28xx, the [[http://linuxtv.org/hg/v4l-dvb/raw-file/tip/v4l2-apps/util/parse_em28xx.pl em28xx log parser]] could be used in order to proccess the URBs and the driver dmesg dumps (in the compact format as shown above) and print them into a more human way, generating C like statements that can be added at em28xx source code (with a few adaptations, in the case of i2c messages):

  em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x3d);
  i2c_master_send(0xba>>1, { 20 11 00  }, 0x03);
  em28xx_read_reg(dev, EM28XX_R15_RGAIN);         /* read 0x00 */

===Command Playback Utilities:===
* usb-robot - plays back USB Snoopy capture logs
* usbreplay - plays back usbsnoop capture logs

==i2c==
* i2c Tools: see [http://www.lm-sensors.org/wiki/I2CTools here] and [http://www.lm-sensors.org/wiki/i2cToolsDocumentation here]
* http://en.wikipedia.org/wiki/I2C#Development_Tools
* also see [http://www.spinics.net/lists/linux-dvb/msg16845.html this thread]

==External Links==
* [[Wikipedia:Bus sniffing|Wikipedia's Bus sniffing article]]; note that the [[Wikipedia:Cache coherency|Cache coherency]] article is a probably a little less vague or more enlightening
[[Category:Development]]