我有一个通过以下命令在Linux上运行的Bluetooth RFCOMM服务:
sdptool add --channel 1 SP
rfcomm watch hci0 1 "$COMMAND" {}
# ^ here
$COMMAND
将二进制数据写入作为参数传递的文件。我已经通过执行以下操作测试了它的行为:FIFO=$(tempfile)
mkfifo "$FIFO"
"$COMMAND" "$FIFO" &
cat "$FIFO" | hexdump -C # <- output is correct
但是,当通过SPP/RFCOMM发现(UUID
00001101-0000-1000-8000-00805F9B34FB
)从其他设备连接到服务时,我看到流中的0x0A
(LF
)的每个实例都替换为0x0D
0x0A
(CR
LF
)。问题不在接收端,因为我尝试连接到也发送二进制数据的硬件串行设备,并且在那里没有发生转换。它必须是执行替换的第一个代码段(在# ^ here
行上方)中的命令。为什么
rfcomm
工具执行此替换,我该如何禁用它? 最佳答案
似乎您被TTY的线路纪律所咬(请记住rfcomm
不会创建fifo,而是tty)。
您可以尝试将TTY更改为原始模式,即没有任何魔力。最简单的方法是使用stty --file <tty> raw
。我不知道rfcomm
是否会在其命令行中接受多个命令,但是您可以使用脚本轻松地进行操作:
command_raw
#!/bin/bash
stty --file "$1" raw
"$COMMAND" "$1"
然后运行:
sdptool add --channel 1 SP
rfcomm watch hci0 1 ./command_raw {}
如果您有要运行的命令源,也可以在C中轻松更改它:
#include <termios.h>
#include <unistd.h>
//WARNING: error checking left as an exercise to the reader!
void make_raw(int fd)
{
struct termios ios;
//Not a TTY: nothing to do
if (!isatty(fd))
return;
tcgetattr(fd, &ios);
cfmakeraw(&ios);
tcsetattr(fd, TCSANOW, &ios);
}
关于linux - 通过蓝牙/RFCOMM/SPP发送二进制数据将0x0A转换为0x0D 0x0A,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/15028953/