ux下USB抓包工具UsbMon的使用和包数据格式解析
一、UsbMon的使用步骤
1、挂载debugfs
2、加载usbmon模块
3、确认usbmon是否可用
4、确认usb设备挂在哪条总线
5、使用usbmon抓取通讯数据包
二、UsbMon抓取的数据包格式解析
一、UsbMon的使用步骤
一般linux内核提供了usbmon这个工具，想要启用UsbnMon，必须挂载debugfs并加载usbmon模块；之后确认usbmon是否可用及USB设备所在总线分支，最后使用usbmon抓包并分析；
对应步骤命令如下:
1、挂载debugfs
# mount -t debugfs none_debugs /sys/kernel/debug (这个也可以在内核配置中直接使能挂载)；
2、加载usbmon模块
# modprobe usbmon （如果usbmon已编译到内核，本步骤可以忽略，至于modprobe的作用，请参见该博客
3、确认usbmon是否可用
# ls /sys/kernel/debug/usb/usbmon
# 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
说明:
①、数字后面的s/t/u表示抓包保存的数据格式；我们使用u格式，其他2项忽略即可；
②、数字1/2/3分别表示所在的当前平台所拥有的USB总线，调试的usb设备挂在哪条总线下，就用哪个; 那么0数字表示什么含义呢？它表示抓所有总线上的包;
4、确认usb设备挂在哪条总线
运行”cat /proc/bus/usb/devices”, 就会发现设备T开头的行.T行有1个bus字段, Bus=03 说明它在bus3口上；如下所示：
T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0557 ProdID=2004 Rev= 1.00
S: Manufacturer=ATEN
S: Product=UC100KM V2.00
5、使用usbmon抓取通讯数据包
# cat /sys/kernel/debug/usb/usbmon/3u > /tmp/usbmon_log.txt
（将抓取到的数据保存在 /tmp/usbmon_log.txt中）
二、UsbMon抓取的数据包格式解析
可以参见这篇文章详解usbmon抓取的log各字段的含义
类似: ffff9bbbaf235b00 1482700625 C Ii:3:001:1 0:2048 1 = 04的字段解析以及Co/Ci / Ii/Io等含义参见以下网址： USB抓包usbmon
---
URB传输异常
urb传输异常就有很多种了，下面列举一下常见的错误对应的status：
注：下面的usb status状态码在 linux-x.x.x/Documentation/usb/error-codes.txt 这个文件中有详细的说明，可以参考一下。
-EINPROGRESS (-115)
这个字段前面已经说过了，它出现在URB submission的时候，表示这个URB的控制权交给了usb控制器，将由usb控制器处理，这个并不是真正的错误。
-EPROTO (-71)
有两种原因会导致这个错误：
A bitstuff error happened during the transfer
No response packet was received in time by the hardware
这个错误经常发生在usb设备枚举失败时，下图就是EC25模块在客户树莓派上枚举失败对应的log，URB的status字段为-71
-EILSEQ (-84)
这个错误不太常见，具体可以参考error-codes.txt
-ECOMM (-70)
对于IN URB，在数据传输中，接收USB设备数据的速度 > 将数据写入内存中的速度
-ENOSR (-63)
在OUT URB数据传输中，数据不能从系统内存中获取的足够快，以便可以跟上请求的usb的数据速率
-EPIPE (-32)
这个表明usb管道"不通"，批量端点可能会设置了halt条件，设置了这种条件的端点必然会堵塞管道，可以使用usb_clear_halt()清除halt
-EOVERFLOW (-75)
当发送给端点的数据包长度大于端点特定的数据包长度时会出现这个错误，从错误码也能看出来，数据“溢出了“
ENODEV (-19)
usb设备已经从系统中移除，但是hub没有及时检测到usb设备的断开，驱动仍然提交URB，就会导致这个错误发生。
Note： -EPROTO、-EILSEQ、-EOVERFLOW一般是由于usb设备、设备固件或usb数据线出问题导致的。
URB从usb控制器中"unlinked"
"unlinked"发生下下面的场景下：
（1）驱动中调用 usb_unlink_urb( ) 或 usb_kill_urb( ) 主动取消一个已经提交给usb控制器的URB
调用 usb_unlink_urb( ) 之后，URB的status值为-104（ECONNRESET）
调用 usb_kill_urb( ) 之后，URB的status值为-2（ENOENT）
（2）当URB已经提交给某个usb设备，但该设备被remove了，硬件断开了，比如将模块从主机上拔掉，这种情况下URB的status字段就为-108（ESHUTDOWN）
下面举几个例子：
使用 busybox microcom /dev/ttyUSB2 命令打开模块的AT口（open /dev/ttyUSB2），什么都不输入，然后 ctrl+x 退出 microcom（close /dev/ttyUSB2），相应的usbmon log如下：
可以看到，当主动退出microcom时，相应的URB的status字段值为-2，对应到串口驱动中就是调用了usb_wwan_close()中的usb_kill_urb()
对应的E（submission error）是在回调函数重新提交URB产生的，此时串口已经close，再去提交就产生了错误。
后面URB的status字段为-1（EPERM），这里分析usb_submit_urb() 的代码，可以看到-1是 usb_submit_urb()的返回值
usb_submit_urb
return usb_hcd_submit_urb;
同样使用 busybox microcom /dev/ttyUSB2 命令打开模块的AT口，然后此时拔掉EVB板，断开usb设备，对应的usbmon log如下，可以比较和前面的区别：
-108（ESHUTDOWN）是usb物理层断开URB对应的status
下面再看一下模块autosuspend过程中的usbmon log：
echo auto > /sys/bus/usb/devices/3-2.1/power/control 使用模块的autosuspend
ffff8800ba722240 2220899617 S Ci:3:009:0 s 80 00 0000 0000 0002 2 <
ffff8800ba722240 2220901604 C Ci:3:009:0 0 2 = 0000
ffff8800b7da3a40 2220901706 S Ii:3:009:5 -115:256 10 <
ffff8800b7da2180 2220901759 S Bi:3:009:4 -115 4096 <
ffff8800b7da2240 2220901798 S Bi:3:009:4 -115 4096 <
ffff8800b7da2f00 2220901824 S Bi:3:009:4 -115 4096 <
ffff8800b7da2d80 2220901850 S Bi:3:009:4 -115 4096 <
ffff8800ba722240 2220901891 S Co:3:009:0 s 21 22 0003 0002 0000 0
ffff8800ba722240 2220902834 C Co:3:009:0 0 0
ffff8800b7da3a40 2220905343 C Ii:3:009:5 0:256 10 = a1200000 02000200 0000
ffff8800b7da3a40 2220905360 S Ii:3:009:5 -115:256 10 <
ffff8800b7da2180 2223569116 C Bi:3:009:4 -2 0 // ① 这里等待了2s（2223, 569116 - 2220, 905360），然后进入了autosuspend ② -2是这个URB在suspend函数中被usb_kill_urb()取消了
ffff8800b7da2180 2223569160 S Bi:3:009:4 -115 4096 <
ffff8800b7da2180 2223569172 E Bi:3:009:4 -1 0 // 这里和前面出现的原因相同，模块已经进入autosuspend，回调函数中又去提交这个URB
ffff8800b7da2240 2223569519 C Bi:3:009:4 -2 0
ffff8800b7da2240 2223569523 S Bi:3:009:4 -115 4096 <
ffff8800b7da2240 2223569528 E Bi:3:009:4 -1 0
ffff8800b7da2f00 2223569776 C Bi:3:009:4 -2 0
ffff8800b7da2f00 2223569810 S Bi:3:009:4 -115 4096 <
ffff8800b7da2f00 2223569815 E Bi:3:009:4 -1 0
ffff8800b7da2d80 2223570119 C Bi:3:009:4 -2 0
ffff8800b7da2d80 2223570159 S Bi:3:009:4 -115 4096 <
ffff8800b7da2d80 2223570167 E Bi:3:009:4 -1 0
ffff8800b7da3a40 2223571635 C Ii:3:009:5 -2:256 0
ffff8800ba722540 2223571783 S Co:3:009:0 s 00 03 0001 0000 0000 0
ffff8800ba722540 2223572943 C Co:3:009:0 0 0
ffff8800ba722540 2223573179 S Co:3:003:0 s 23 03 0002 0001 0000 0 // 这里是hub发出的，Port1：PORT_SUSPEND
ffff8800ba722540 2223574608 C Co:3:003:0 0 0
原文链接：https://blog.csdn.net/weijuban5324/article/details/105817537
---
原文链接：https://blog.csdn.net/hdmsfhfg1/article/details/106187648/