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/