使用BlueZ发送BLE GATT 0x12写请求而非0x16的技术问询

我明白你在逆向工程无配对BLE设备时遇到的问题：用--char-write-req参数执行写操作时，Gatttool自动发送了0x16预备写请求，但你需要的是0x12的写命令。这其实是参数选择的问题，很容易解决。

修正后的命令 #

把你原来命令里的--char-write-req替换成--char-write（去掉-req后缀）就行：

sudo gatttool -i hci0 -b 54:6C:0E:21:F5:99 --char-write -a 0x0030 -n 110100701301000110010030721000d68c054688df413aa89fb3cfab3d6457172000053958839fa147ac53c129eafc524829bc9ed7655fe96c9f641745c4e07cf044

背后的原因 #

这里的关键是Gatttool两个写参数的差异：

• --char-write-req：这个参数对应ATT层的Write Request，如果要写入的数据长度超过当前BLE连接的MTU值，Gatttool会自动拆分数据，用Prepare Write Request（0x16） + Execute Write Request的组合来完成写入，这就是你在Wireshark里看到0x16包的原因。
• --char-write：这个参数对应ATT层的Write Command（0x12），这是无响应的写操作，不会触发预备写流程，直接尝试发送完整的写命令（如果数据长度在MTU范围内的话）。

额外的调试技巧 #

如果你想确认发送的操作码确实是0x12，可以在命令里加上-t参数开启调试输出，这样能看到底层发送的ATT包细节：

sudo gatttool -i hci0 -b 54:6C:0E:21:F5:99 -t --char-write -a 0x0030 -n 110100701301000110010030721000d68c054688df413aa89fb3cfab3d6457172000053958839fa147ac53c129eafc524829bc9ed7655fe96c9f641745c4e07cf044

在输出日志里找类似ATT: Send: 0x12 ...的内容，就能验证操作码正确了。

内容的提问来源于stack exchange，提问作者Lucas Kauffman