Usb capture methods under Linux 1
1, arranged to enable kernel usb monitor:
make menuconfig
Device Drivers -->
USB Support -->
USB Monitor --> Select * not M
2、build kernel
sudo insmod /lib/modules/3.2.1/kernel/drivers/usb/mon/usbmon.ko
3, after starting the kernel execution
#mount -t debugfs none_debugs / sys / kernel / debug
to check whether there is a directory / SYS / Kernel / Debug / the USB / the usbmon
#ls / SYS / Kernel / Debug / the USB / the usbmon
0s 0U 1S 1T 1U 2S 2T 2U 3S 3T 3U
# CAT / SYS / Kernel / Debug / usb / Devices sure you want to monitor usb device where the bus number and device number
# selection includes: Vendor = 148f ProdID = 5370 Rev = 1.01 paragraph
# AS Follows:
# T: Bus = 01Lev = 01 the Prnt = 01 Port = 00 Cnt = 01 Dev # = 2 Spd = 480 MxCh = 0
# D: Ver = 2.00 C1s = 00 (> IFC) Sub = 00 Prot MxPS # 00 = 64 = = CFGS. 1
# P: Vendor = 148f ProdID Rev = 1.01 = 5370
# S: Manufacturer = Ralink
# S: Product = 802.11 n-the WLAN
# S: SerialNumber = 1.0
# C: * # Ifsm =. 1 Cfg # =. 1 Atr = 80 MxPwr = 450mA
# the I: * the If # = 0 the Alt = 0 # of EPs =. 5 C1s = FF Sub = FF Prot = FF Driver = rtusbSTA (Vend.)
# E: the Ad = 81 (the I) Atr = 02 (Bulk) MxPS = 512 Ivl = 0ms
# E: the Ad = 01 (O) Atr = 02 (Bulk) MxPS = 512 Ivl = 0ms
# E: the Ad = 02 (O) Atr = 02 (Bulk) MxPS = 512 Ivl = 0ms
# E: the Ad = 03 (O) Atr = 02 (Bulk) MxPS = 512 Ivl = 0ms
# E: the Ad = 04 (O) Atr = 02 (Bulk) MxPS = Ivl = 0ms 512
# Bus can be seen from the first row = 01, device number 2 is
4, save usb raw packet, if the bus number is 1, it is 1u, if the bus number is 2, it is 2U, and so on. A special case is represented 0u monitor all bus
IF (Bus == 01)
sudo CAT / SYS / Kernel / Debug / the USB / the usbmon / 1U> ./rt5370-UsbMon.txt
the else IF (Bus == 02)
sudo CAT / SYS / Kernel / Debug / usb / the usbmon / 2U> ./rt5370-UsbMon.txt
2 usb grasping packet format parsing
of the Requests the usbmon Reports Made by the Host to Peripheral-specific Drivers
the Controller the Drivers (the HCD). So, the HCD IF iS Buggy, Reported by traces at The
the usbmon May not Correspond to Bus Transactions Precisely. This IS at The Same,
Situation AS with tcpdump.
The above basic description of the usbmon major works, he would usb host drivers to send all requests hcd of (usb_submit_urb) and callback content of the request (ie a request to change the corresponding callback function: urb-> complete) are reported.
The Any text the format Data Consists of A Stream of Events, SUCH asURB submission (S),
the URB the callback (C), submission error (E). Every Event IS A text Line, Which Consists
of whitespace Separated words. Of The Number or position of words On May the depend
ON the Event type, but there iS a SET of words, Common for All types.
so here URB submission i.e. corresponding usb host drivers in usb_submit_urb (urb, mem_flags)
and URB callback even if the corresponding urb back off function: urb-> complete
so we'll see even type and in close proximity to the event type of event for the C of S, corresponding URB tag they are the same
as they are for a URB same terms.
To give three Liezi:
eea76f80 3,474,782,286 S of Ii:. 1: 003: -115. 3: 128 16 <
edda2b80 3,474,786,256 C of Ii:. 1: 006: 0. 1: = 16. 1 2fff0180 d6ef206e 1401020c 015aab73
e11c9280 3500399358 S of Co:. 1: 006 : 0 s 20 00 0000 0000 0007 7 = 370c0447 00401f
e11c9280 3500399866 C Co:1:006:0 0 7 >
Here is the list of words, from left to right:
- the URB the Tag This IS Used to the Identify URBs, and IS Normally AN in-Kernel address.
Of The the URB Structure in HEXADECIMAL, But CAN BE A Sequence Number or the any
OTHER UNIQUE String, WITHIN reason.
Usually is partitioned usb host driver in urb kernel address, allocated by the general function:
urb usb_alloc_urb = (0, mem_flags);
Due to a urb corresponds to a port, so the same port their urb tag is the same.
002e2002999116296 C Ci: 1: 008: 0 0 4 = 8d2b0000
Timestampin microseconds, a decimal number. The timestamp's resolution
depends on available clock, and so it can be much worse than a microsecond
(if the implementation uses jiffies, for example).
e002e200 2999116296Ci:1:008:0 0 4 = 8d2b0000
Note microseconds.
- Event Type. This type refers to the format of the event, not URB type.
Available types are:S - submission, C - callback, E - submission error.
e002e200 2999116296 C Ci:1:008:0 0 4 = 8d2b0000
The meaning of that is: usb host drivers urb submitted a transfer request to the linuxusb core by usb_submit_urb function, we know all the usb transfer, is host initiates the end, it must have a host drivers unsolicited submit urb action
- "Address" word (formerly a "pipe"). It consists of four fields, separated by
colons: URB type and direction, Bus number, Device address, Endpoint number.
Type and direction are encoded with two bytes in the following manner:
Ci Co Control input and output
Zi Zo Isochronous input and output
Ii Io Interrupt input and output
Bi Bo Bulk input and output
Bus number, Device address, and Endpoint are decimal numbers, but they may
have leading zeros, for the sake of human readers.
Therefore, the address field format is as follows:
URB type and direction：Bus number：Device address：Endpoint number
Liezi follows:
e002e200 2999116296 Ci of C:. 1: 008: 0. 4 0 = 8d2b0000
Means that: Control input bus number 1, the device address 008, because all transfers are controlled on the Endpoint 0, the final 0 is the natural port.
It should be noted that, because of our capture this command, only specify what is caught on the bus, the same bus but there is usually a lot of usb devices, if we just focus on a particular usb device, then I need to pay attention device address field, through this field, we can distinguish this transmission is sent out is not what we want to monitor equipment.
For example the following section usb sniffer log:
edda2b80 3500379613 C Ii:1:006:1 0:1 8 = 0e06010d 08004700
edda2b80 3500394156 S Ii:1:006:1-115:1 16 <
eea76f80 3500394226 C Ii:1:003:3 0:128 16 = a12a0000 01000800 00e1f505 00e1f505
eea76f80 3500394236 S Ii:1:003:3 -115:128 16 <
Usb. 1 below are the same bus, the bus due to a corresponding one of usb usb host controller, but a device address 006, another is 003, corresponding to the former is an interrupt usb Bluetooth dongle transmission, while the latter is the mouse usb interrupt transmission, they are connected to the usb hub under the same bus. What we really need to listen to just usb bluetooth dongle, so you can not usb mouse interference.
. - URB Status Word This IS either A Letter, or 'several' a Numbers Separated
by colons: URB Status, interval The, Start Frame, and error COUNT that Unlike at The.
"Address" Word, All Fields the Save at The Status are optional Interval IS Printed.
Only for . URBs Start Frame interrupt and isochronous iS Printed only for
isochronous URBs Error COUNT iS Printed only for isochronous callback.
Events.
the meaning here is, urb status word, there are two possibilities, one is the "letter"; one is the " digital "If the former general is the letter" s ", represents a control transfer, and if it is digital, they form the two cases:
If the transmission is interrupted in the following format: URB status: interval, pay attention to the status field only C type of event makes sense, does not mean the S types of events.
If a synchronous transmission format as follows: URB status: interval: {start frame}: {error count}
The status field is a decimal number, sometimes negative, which represents
a "status" field of the URB. This field makes no sense for submissions, but
is present anyway to help scripts with parsing. When an error occurs, the
field contains the error code.
e002e200 2999116296 C Ci:1:008:0 0 4 = 8d2b0000
Domain Status: status is the status field in the struct urb structure, the description field is a direct current usb request is executed successfully. Therefore, only when the callback was interesting.
In case of a submission of a Control packet, this field contains a Setup Tag
instead of an group of numbers. It is easy to tell whether the Setup Tag is
present because it is never a number. Thus if scripts find a set of numbers
in this word, they proceed to read Data Length (except for isochronous URBs).
If they find something else, like a letter, they read the setup packet before
reading the Data Length or isochronous descriptors.
e002e200 2999116113 S Ci:1:008:0 s c0 07 0000 1134 0004 4 <
The letter "s" is a transfer control flag
- Setup packet, if present, consists of 5 words: one of each for bmRequestType,
bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
packet was present, but not captured, and the fields contain filler.
I.e. control of the transport packet format is as follows:
the bmRequestType (Request Type): bRequest (No Request): wValue: wIndex (subscript): wLength (the length of the data field, if it is 0, indicating that no data segment)
3500399358 S of Co e11c9280:. 1: 006: 0 0000 0000 0007 00 S20. 7 = 370c0447 00401f
e11c9280 3500399866 C of Co:. 1: 006: 0. 7 0> // represents the above transmission control request was successful, and the actual transmission of seven btye data, only that state and does not correspond to a specific transmission phase control
2,000,000,000,000,007 transfer stage corresponding to the control setup, 370c0447 00401f corresponding data transfer control stage (OUT transfer), the data length of 7 bytes
- Number of isochronous frame descriptors and descriptors themselves.
If an Isochronous transfer event has a set of descriptors, a total number
of them in an URB is printed first, then a word per descriptor, up to a
total of 5. The word consists of 3 colon-separated decimal numbers for
status, offset, and length respectively. For submissions, initial length
is reported. For callbacks, actual length is reported.
. - the Data on the Submissions the For the Length, the For the this length requested the callbacks The IS,.
The this IS The Actual length.
E002e200 2999116296 Ci of C:. 1: 008: 04 = 0 8d2b0000
and follows:
edda2b80 3,500,272,851 S of Ii:. 1: 006: -115. 1 : 1 16 <
edda2b80 3500273622 C of Ii:. 1: 006: 0. 1: 000100. 1. 7 = 13,050,147
the first is a request to initiate a length of 16 bytes usb interrupt transfer request, which is generally in the field endpoint descriptor indicates that this conduit the maximum packet size supported by
the second sentence is the actual data transmission request interrupt return is only 7 bytes, corresponding urb-> actual_length field
more than two corresponding to an interrupt iN transfer
. - the Data Tag of The the usbmon On May Not Always Capture Data, the even IF length IS nonzero.
Of The Data words are Present only IF the this Tag IS '='.
E002e200 2999116296 C Ci of:. 1: 008: 0 0. 4 = 8d2b0000
Data Tag is " = ", represents a data segment," back = "sign is a specific data content
- Data words follow, in big endian hexadecimal format. Notice that they are
not machine words, but really just a byte stream split into words to make
it easier to read. Thus, the last word may contain from one to four bytes.
The length of collected data is limited and can be less than the data length
reported in the Data Length word. In the case of an Isochronous input (Zi)
completion where the received data is sparse in the buffer, the length of
the collected data can be greater than the Data Length value (because Data
Length counts only the bytes that were received whereas the Data words
contain the entire transfer buffer).
e002e200 2999116296 C Ci:1:008:0 0 4 = 8d2b0000
Examples:
An INPUT Control Transfer to GET A Port Status.
D5ea89a0 3575914555 S Ci of:. 1: 001: 0 S A3 00 0000 0003 00044 <
"A3 00 0000 0003 0004" corresponding to the setup stage of control transfer, "4" corresponding to the control transmission phase data length
5ea89a0 3575914560 C Ci: 1: 001 : 0 0 4 = 01050000
corresponding to the transmission data control data iN phase transfer, "01050000" is the data length of 4byte
An output bulk transfer to send a SCSI command 0x28 (READ_10) in a 31-byte
Bulk wrapper to a storage device at address 5:
S Bo 4,128,379,752 dd65f0e8:. 1: 005: 31 is 2 -115 00.8 million 80010a28 = 55,534,243 ad000000 00000000 000000 20000000 20.00004 million
dd65f0e8 4128379808 C Bo:. 1: 005: 0 2 31 is> // indicates a successful transmission request when the bulk, and also actual transmission a 31 byte data.
3 USB Sniffing with tcpdump
usbmon is a facility in kernel which is used to collect traces of I/O on the USB bus. usbmon collects raw text/binary which are not easily human-readable. Here, the idea is to use Wireshark as frontend to produces a human-readable representation of these data. However Wireshark does not support usbmon raw data as is, so we have to parse these data in the pcap format. tcpdump is a good candidate to capture USB data from usbmon and generate pcap traces
Prerequisite is the need for the latest tcpdump tool for the job, have compiled, you can download directly to push down on the board can be used. You can also compile your own manual. Here it is not a detail.
step:
mount -t debugfs none_debugs /sys/kernel/debug
cat /sys/kernel/debug/usb/devices 确定usb的总线号
tcpdump -D
1.eth0
2.usbmon1 (USB bus number 1)
3.usbmon2 (USB bus number 2)
4.usbmon3 (USB bus number 3)
5.any (Pseudo-device that captures on all interfaces)
6.lo
More than the red part of output, the lower your tcpdump already installed and working properly
-i -w /data/usblog.pcap & usbmon1 tcpdump
killall tcpdump
wireshark usblog.pcap // best tool to use wireshark to see it
down on a chart reference, opened what it looks like:
Reference documents:
W: \ wm8880 \ Android \ ANDROID_3.4.5 \ Trunk \ Documentation \ the USB \ usbmon.txt
http://omappedia.org/wiki/USB_Sniffing_with_tcpdump
---------------- -----
author: xiaojsj111
source: CSDN
original: https: //blog.csdn.net/xiaojsj111/article/details/14127607
copyright: This article is a blogger original article, reproduced, please attach Bowen link!