I am having the following command line in linux :
echo -n "06 0E 2b 34 02 04 01 0A 0E 10" | xxd -p -r|nc -q0 127.0.0.1 11720
Can some one help me to translate it to one or more windows commands?
Related
This is a great solution as far as it goes:
How to use bluetoothctl like hcitool lescan to report repeated proximity beacons
I want to take it one step further though: instead of printing the beacon detections to the terminal, I want to pipe each detected beacon's MAC address to a command that publishes it to a Mosquitto broker. This would be useful for adding the beacons to HomeAssistant, for example, for presence detection of a key fob attached to a person's house keys. I managed to get this idea to work by modifying the last two lines of the script above but it only publishes the first detection ... then no more. I guess somehow the scan is being turned off or aborted by trying to run the mosquitto_pub command. (something to do with interrupting the thread or subshells????)
Here are the last lines of the script with the MAC addresses of my TWO TEST BEACONS obfuscated.
You can see the full script that I modified at the link above.
) | sed --unbuffered --quiet --expression 's/^.*Device //p' \
| grep --line-buffered -E 'FF:FF::::|FF:GG::::' \
| stdbuf -oL cut -c 1-17 \
| { read topic; mosquitto_pub -d -u username -P password -m ON -t monitor/$topic; }
Note:
| stdbuf -oL cut -c 1-17 \ trims the output down to just the MAC address - e.g. FF:GG::::
The last line publishes the ON command to an unique state topic ending in the beacon's MAC address e.g. 'monitor/FF:GG::::'.
If I remove that last line the detections are added as they occur to the terminal console in an ever growing list as time goes by. But once I add the last line it only works once, then goes dead.
How can the script be made to respond to each detection, not just the first one?
And why exactly does it only respond to the first detection then hang?
The command line tools of BlueZ are not designed for this purpose, so it makes them very difficult to pipe scan results reliably. In my experience, processes die or hang, and you end up with broken pipes.
The C APIs of BlueZ are much more stable. I wrote a simple command line program in C that you could use instead of bluetoothctl for this purpose:
https://gist.github.com/davidgyoung/0a18028b4338ff6cb201fba274502662
That program must be compiled with cc scanner.c -lbluetooth -o scanner, after which you can start the scanner with just scanner. The output of the program will be something like this:
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
71:5C:23:9D:BC:7F -68 02 01 1A 02 0A 0C 0B FF 4C 00 10 06 03 1A 3B D4 B2 EB
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
4A:53:7F:64:71:EC -91 03 03 9F FE 17 16 9F FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
69:0D:FF:7B:75:65 -73 02 01 1A 02 0A 0C 0A FF 4C 00 10 05 03 1C 27 BB 63
61:39:71:E9:1D:C9 -93 02 01 1A 02 0A 18 0A FF 4C 00 10 05 01 18 3B 24 12
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
Each line above shows the MAC address of the detected bluetooth device, followed by the signal strength RSSI, then the hex bytes of the advertisement.
I use this program to pipe into other shell scripts, and have found it to be reliable over many days. Feel free to use it if helpful.
I am developing software for a commercial product that runs on a Moxa MPC-2070 panel computer (Intel Atom based) under Debian 10 (Buster) with BlueZ (5.50) bluetooth support. The application has been developed using Qt Creator. I have been struggling to find a robust and reliable method to scan for Bluetooth Low Energy devices.
Because of an extreme performance problem associated with the QBluetoothDiscoveryAgent::start() method in Qt (which I won't go into here), I am using the bluetoothctl command to perform BLE device scanning. A wrapper around bluetoothctl provides it with input commands and parses the output from bluetoothctl. Sporadically (once every 1 - 150 times) that I launch bluetoothctl to perform the BLE scan, the bluetooth daemon process (bluetoothd) crashes with a SIGSEGV.
Here is the tail of syslog after the bluetoothd crash:
[315398.536280] show_signal_msg: 8 callbacks suppressed
[315398.536293] bluetoothd[523]: segfault at a8ec8148fd ip 00007f681ba3e143 sp 00007ffc8110a858 error 4 in libdbus-1.so.3.19.11[7f681ba2f000+2e000]
[315398.536343] Code: 85 ed 74 13 0a 18 88 18 48 83 c4 08 5b 5d c3 0f 1f 84 00 00 00 00 00 f7 d3 22 18 88 18 48 83 c4 08 5b 5d c3 0f 1f 00 48 8b 07 <0f> b6 40 02 85 f0 0f
95 c0 0f b6 c0 c3 55 48 89 fd 53 89 f3 48 83
I have restarted bluetoothd with the -d flag to enable debug output via:
$ sudo bluetoothd -d &
And again ran the bluetoothctl scans in a loop until bluetoothd again crashed. The full syslog showing the bluetoothd crash can be found here: Complete syslog with bluetoothd SIGSEGV
In the above syslog, the initial bluetoothd (without -d) crash can be found at Jan 14 09:58:55.
The restart of bluetoothd with the -d flag is at Jan 14 10:03:16.
The looping use of bluetoothctl begins at Jan 14 10:06:03.
bluetoothd again SIGSEGVs at Jan 14 10:05:13.
Sometimes the bluetoothd crashes happen after only 1 or 2 bluetoothctl commands, and other times it takes many iterations before the crash occurs.
This shell script will reproduce the bluetoothd crash. It loops performing essentially the same function as my C bluetoothctl wrapper program, but without the bluetoothctl output processing. Note that this script must be run as root or by a user id which is a member of the 'bluetooth' group.
#! /bin/bash
COUNT=0
RESULT=0
while [ "${RESULT}" != "9" ]
do
COUNT=`expr ${COUNT} + 1`
echo "Loop #${COUNT}"
# uveTagScanner -s FEA0 ${#} # The compiled bluetoothctl wrapper program with output processing
# RESULT="$?"
( echo "menu scan" # Enter the bluetoothctl scan sub-menu
echo "clear" # Clear all filter parameters
echo "transport le" # Filter scanning for low-energy devices only
echo "duplicate-data off" # Disable reporting of duplicate-data
echo "back" # Exit the bluetoothctl scan sub-menu & return to main menu
echo "scan on" # Start scanning for LE devices
sleep 10 # Let scanning proceed for 10 seconds
echo "scan off" # Stop scanning for LE devices
echo "quit" # Quit the bluetoothctl command
) | bluetoothctl
done
Within my C wrapper program (uveTagScanner) which fork()/exec()s bluetoothctl and performs the output processing, I am able to detect if bluetoothd has crashed and then restart it. But this is only a band-aid solution, as it still leaves me with instances where the scanning for BLE devices does not provide the needed information.
I'm running out of ideas on how to reliably perform BLE device scanning! I could try using the BlueZ libraries and Dbus interface APIs instead of bluetoothctl, but I fear that the same bluetoothd crash would occur.
History:
I used BlueZ 5.43 to communicate with a bluetooth device:
connect FF:FF:FF:FF:FF:FF
select-attribute /org/bluez/hci/dev_ ...
write 0x54
It takes some time, but it works.
Current issue:
Now I'm using the HCI commands defined in the Bluetooth Specification to connect to my device via hcitool cmd .... Works fine.
But: I can't write an ACL Data packet via hcitool cmd to my connected device:
The ACL packet (see BT Core Spec Vol 2, Part E, 5.2.4) is sent with sudo hcitool cmd 02 40 00 08 00 04 00 04 00 12 0D 00 54
The btmon shows the error: Unknown HCI Command
Using sudo hcidump --r I see that the ACL packet is modified to 01 40 08 0B 00 08 00 04 00 04 00 12 0D 00 54.
How can I send a ACL Data packet via hcitool cmd?
Thank you,
Tom
I want to get the hexdump of a given function. Until now objdump -d a.out --start-address=0x400630 and --stop-address=0x400679 is the best solution what I have found, however I do not know how to extract only the opcodes from the output.
For example from this:
4003f0: 48 83 ec 08 sub $0x8,%rsp
4003f4: e8 73 00 00 00 callq 40046c
...
I need only this:
48 83 ec 08
e8 73 00 00 00
You could use gdb on your program and x/i will print out a range of machine instructions.
May also try to pipe in cut:
objdump -d a.out --start-address=0x400630 and --stop-address=0x400679 | cut -b 14-30
you probably need to adapt your cut range for your output.
There is a well known blog post going around on how to set a usb bluetooth 4 dongle to be an iBeacon. It boils down to this magical command:
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
The issue with this example is that it is so opaque it's hard to use it in any more general format. I've been able to break it apart a bit:
sudo hcitool -i hci0 cmd
sends an hci command to the hci0 device
0x08 0x0008
is just magic to set the ad package, other stackoverflow commands have said "just use it, don't ask
1e
is the length of the ENTIRE following data packet in bytes
02 01 1a 1a
Are flags to set up the ad packet (details on request)
ff 4c 00 ...
is the 'company specific data' that encodes the iBeacon info
What I've tried to do is replace the "FF ..." bytes with the opcodes for setting the NAME parameter "04 09 41 42 43" (which should set it to ABC) but that doesn't work.
I'm surprised the hcitool doesn't give us some examples on how to set the ad packet as this would be very useful in setting all sorts of other params (like TEMP or POWER). Has anyone else had any experience in using hcitool to set things like NAME?
Late reply, but somebody might find this useful. I found it as I was looking around for solutions myself when using hcitool.
If you use hcitool cmd --help it will tell you something like this cmd <ogf> <ocf> .... It helps to look at the Bluetooth Core Specification to find out what 0x08 and 0x0008 would be for OGF and OCF. Specifically Vol. 2, Part E, 7.8
For the LE Controller Commands, the OGF code is defined as 0x08
and for the OCF of 0x0008
Advertising_Data_Length, Advertising_Data
So basically, with 0x08 0x0008 you say you are setting (in the LE Controller) the length of the data that is sent. As for the name, since the length of the BLE advertisement packet is 31 bytes (1E), you need to send the whole 31 bytes. So if you only have ABC as the name, setting 04 09 41 42 43 is correct, but that's only five bytes. For 31 you need to add 00 26 times. Just be careful you don't add too much or too little.
Also, I wasn't under the impression that BLE ad. packets are of fixed 31 byte size, but they are at least for hcitool. It doesn't work when you specifically set the outgoing size to something smaller than 1E.
No. None of this answers is correct and clean.
1) BLE have a separate command set. "LE Set Advertising Data" command must be used (see 7.8.7 vol 2 part E).
2) LE Set Advertising Data is much complex than what explained above. There are at least 2 1-octet length fields, packet must be 32 bytes length, zero padded, but the first length byte must not be 0x1e (31) but the length of the significant used part, containing one or more headers. Each header still contains a length, one AS Type byte (0x09 for set local name) and the name.
SET LE LOCAL NAME:
hciconfig hci0 down
hciconfig hci0 up
hcitool -i hci0 cmd 0x08 0x0008 0c 0b 09 6c 69 6e 6b 6d 6f 74 69 6f 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
hciconfig hci0 leadv 0
0x0c : length of the following group of headers
0x0b : length of this header
0x09 : AD Type for complete name
rest 0x0a length is the name
Check out this answer to a similar question. It basically describes how you can download the giant Bluetooth Core Spec document, and read through all the commands that it offers you. You can use the hcitool command to execute any of these commands if you can just figure out the right format (and figure out what the commands actually do!)
Major caveat: I have not tried setting the name myself, but glancing at the spec, it looks like this is described on page 482 of the spec in section "7.3.11 Write Local Name Command". According to this the command consists of:
OCF: 0x0013
Name (up to 248 bytes)
So I would try a command like this:
hcitool -i hci0 cmd 0x08 0x0013 41 42 43
One other tip: When you issue commands like this, try running hcidump & so the command executes in the background. Then, you can enter experimental hcitool commands (or even hciconfig commands) and see annotated details about what (human readable) commands executed and what errors occurred, if any.
Using the above tip, you can also try executing hciconfig name abc to set the local name using that command line tool, while you are executing a hcidump & in the background. This should show you the proper hcitool command values to use.
It would appear you need to use two commands rather than one. The iBeacon data is contained in the "LE Set Advertising Data" data and has been mentioned elsewhere in this post. To see a BLE friendly name you can use an additional command "LE Set Scan Response Data", this requires the receiver to scan your device (rather than passively read the advertising packet). So you can combine Angelo's example with this one to set the device as an iBeacon and set the "friendly name" which is the Scan Response data
sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 00 00 00 C8 00
sudo hcitool -i hci0 cmd 0x08 0x0009 0c 0b 09 6c 69 6e 6b 6d 6f 74 69 6f 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This worked for me using an Ubuntu box with a BLE dongle and then scanning for the beacon using this android BLE scanning app