Streaming Bluetooth Capture Data to Wireshark without Btsnoop Net Support Enabled
I wanted to connect Wireshark to an Android X86 VM with Bluetooth HCI snooping enabled1 and stream the data as it comes in.
Unfortunately, Android X86 doesn’t have the “Btsnoop Net” feature enabled.
And while you can manually copy the data, streaming it realtime would be superior.
The “Btsnoop Net” interface seems to be a network server sitting on tcp port 8872. Looking at the btsnoop_net.cc on Android Code Search will give you all the details, but in a nutshell —
Btsnoop net is the exact same as dumping whatever data are being
written into the
btsnoop_hci.log… to the tcp/8872 socket.
Which leads me to the…
Given the simple nature of the interface, there’s a one-liner for that:
$ adb shell su -c \ "'nc -s 127.0.0.1 -p 8872 -L system/bin/tail -f -c +0 data/misc/bluetooth/logs/btsnoop_hci.log'"
Yes, that simple2. Keep it running as long as you need it (it doesn’t output anything to the terminal).
After you have it running, you restart Wireshark – and voilà – the
Android Bluetooth Btsnoop Net Virtualbox <ip>:5555: android-bluetooth-btsnoop-net-<ip>:5555 option appears in capture interfaces.
And it works a treat. More on that later.
Side-note about streaming to wireshark
My wireshark was broken for a while (dumpcap complained it can’t save temp file), so I had to resort to this:
rm -f f mkfifo f /usr/lib/x86_64-linux-gnu/wireshark/extcap/androiddump \ --extcap-interface android-bluetooth-btsnoop-net-$ip:5555 \ --capture --fifo f & /usr/bin/dumpcap -n -i f -y SYMANTEC_FIREWALL -Z none -w - | wireshark -k -i -
but it auto-magically fixed itself after a restart3, so it’s no longer needed.
Given the nature of the solution, disconnecting and reconnecting to the
server will spit the entire
btsnoop_hci.log back at wireshark, giving you
the full backlog since you turned the “Bluetooth HCI snoop log” on.
That’s an (IMO welcome) side-effect you’ll have to live with.
Hello windows, my old friend? ↩