New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing on ubuntu 22.04 (linux mint 21) - LE Set Scan Parameters Command Disallowed #43
Comments
I'll have to look into this more. I've not been using btmon, but instead use Wireshark for most of my Bluetooth debugging. It looks like we are using the same version of Bluetooth. Comparing what's happening on your machine to mine might be easier if the sequence numbers matched up. You can see that I start receiving advertisements by sequence 11. Were there a set of hci commands 1-14 in your log? Is GoveeBTTempLogger exiting on its own after sequence 20 on your output? I can't remember why I first set the scanning parameters to 11.25msec and then issue a second scan parameters command to 500msec. It was probably something I saw happening in my pcap log from the android device. I'm running the program in a different window with the command:
and then after I hit ctrl-c on GoveeBTTempLogger:
from a separate run, here's a couple of advertisements from one of my Govee devices.
The GoveeBTTempLogger output of those messages was:
|
Sorry, I didn't think of restarting btmon between my attemps. I updated my first message with a new trace starting at #1 and GoveeBTTempLogger output. Nothing was retrieved from the bluetooth network at this point, since it is way before the |
Sorry. Just saw you edited the original issue. And you are definitely running GoveeBTTempLogger with full root privileges? Just checking more possibilities.
GoveeBTTempLogger without the sudo produces:
I've been digging through the library headers and there's not a simple reset command I can call for the HCI, so it's going to take longer to figure out how to add that command in the code. hci_send_cmd is promising, but I don't really have experience sending direct hardware control interface commands. |
@yduf If you run bluetoothctl does it go into scanning mode properly?
produces this output:
|
Yes I am running GoveeBTTempLogger with full root privileges. Not sure What you wanted to compare with the above trace. bluetoothctl (no sudo needed)
corresponding btmon traces
|
@yduf I don't really know what I was trying to see, mainly if a known program that could scan on your machine operated differently on my machine. As part of my visual studio build process, I run this command: I've now pushed a new update to my code that sends an HCI Reset, and it doesn't seem to have any detrimental issues on my development machine. Let me know how it changes the btmon output on your machine.
|
(delete previous post to clarify issue) But when doing so, it's breaking bluetooth on my system, to the point that restarting bluetooth service is not sufficient,
Notice that LocalName: is yves-huv
Notice that LocalName: is empty now $ sudo btmon
$ bluetoothctl
and dmesg keep telling: restarting bluetooth service won't fix that. |
@yduf Can you look at /usr/include/bluetooth/hci.h and see if these entries are the same as in my version:
the fact that I'm calling higher level functions in hci_lib.h should make any changes there transparent, but I'm grasping at differences now.
The master branch has the HCI_RESET removed from compiling now. |
I have check and they are exactly the same, this is are mine:
|
@wcbonner with your reset implementation and looking at bluez/lib/hci.c I got a better understanding of how to issue hci command directly. As I was hoping, doing the same seq, allows to do trigger the le scan without failure. While there is not much difference in the args used, it seems that using extended operation that are not avaible in bluetooth/hci_lib.h make it works. And no need to call reset at all. I did not do a full implementation, just the init code, so it ends on its own at step #6, just after having started the scan. $ sudo btmon
|
@yduf Can you supply the code snippet you used for the two function calls:
I was looking at the function hci_le_set_scan_enable as a model for issuing the extended scan parameters but didn't see the structure values in an easy format to know how to fill the bt_hci_cmd_le_set_ext_scan_params structure. |
Sure:
< HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6
called like this:
|
@yduf I've pushed a new version of the code that first attempts the regular le_scan and if that fails attempts the extended le_scan. I was not able to test the extended scan, and don't know if the advertisements will be recognized by my program when requested in this fashion. I initially tried replacing the standard calls with the extended calls, and that didn't work for me.
I found the definition for BT_HCI_CMD_LE_SET_EXT_SCAN_PARAMS in the monitor program, but not in the Bluetooth development headers to be able to easily recognize if it's defined at compile time. Similarly, BT_HCI_CMD_LE_SET_EXT_SCAN_ENABLE is in the monitor code. I don't really like that I'm defining the constants in my code and then basing the calls on whether they are defined. If you can find them defined in the standard headers on your machine, I'd appreciate knowing in which files they are defined. I'd also like to know if you receive LE Advertising Report (0x02) or if you now receive an extended advertising report? |
So far the same on my side, found BT_HCI_CMD_LE_SET_EXT_SCAN_PARAMS only in the monitor program. Your modification solve my bluetooth issue, as far as scanning is concerned => now scanning is succesfull. But now, Ctr-C stop the GoveeBTTempLogger (signal is caught), but it doesn't stop scanning. And I see following event continuing to come through btmon:
I need to restart bluetooth service to stop that. On a side note, while GoveeBTTempLogger says it was writing SVG. I yet have to find where ( I had a look in place mentionned in README like /var/www/html/goveebttemplogger/ ). |
@yduf New code push that hopefully uses the extended call to stop scanning properly. The default service file passes the parameter |
This one solves all bluetooth issue. Many thanks! |
Just a quick followup for completeness: So in the end, the current fix allow a smooth bt scan with no errors on my kernel & system. But events gathered are not recognized because of the different binary layout. That's the reason why I was not seeing any log or svg files. Yet I am not reopening the issue: it seems that currently I am the only one facing the original problem. With the knowledge gained from this issue, I created my own simple monitor. Thanks again for your help! PS: struct bt_hci_le_ext_adv_report {
uint16_t event_type;
uint8_t addr_type;
uint8_t addr[6];
uint8_t primary_phy;
uint8_t secondary_phy;
uint8_t sid;
uint8_t tx_power;
int8_t rssi;
uint16_t interval;
uint8_t direct_addr_type;
uint8_t direct_addr[6];
uint8_t data_len;
uint8_t data[0];
} __attribute__ ((packed)); vs the "regular" one typedef struct {
uint8_t evt_type;
uint8_t bdaddr_type;
bdaddr_t bdaddr;
uint8_t length;
uint8_t data[];
} __attribute__ ((packed)) le_advertising_info; |
@yduf This is interesting to me, and I've mostly completed my obsession with downloading historical data. I'd originally wondered if enabling extended scanning might return extended results, but without firsthand knowledge I've been hesitant to try to add the support for an unknown packet. I was just looking at https://ubuntu.com/download/raspberry-pi and it looks like I should be able to create an Ubuntu Pi on a spare sd card pretty easily. Your original post described the code you were running on and processor as:
Do you know what release you are running? |
Sure it's a close derivative of ubuntu: |
I spent a while getting Ubuntu up and running on my Pi4 and it seems to use the standard commands instead of the extended commands. Looks like I'm not going to have a system that I can test extended events anytime soon. In one window I ran the command While the other window I logged in, ran uname, and then btmon:
|
Hello,
I am facing trouble trying to make goveebttemplogger work, may be because of latest change in bluetooth stack.
The issue happens on first call of
hci_le_set_scan_parameters(device_handle, 0x01, htobs(0x0012), htobs(0x0012), 0x01, 0x00, 1000)
and it is failing with error :
Error: Failed to set scan parameters: Input/output error
due to the action being disallowed (see btmon trace below).On the other side I am able to complete a manual le scan with
bluetoothctl
on the very same host and see my Govee devices.So to me it looks very much like this issue where bluetoothctl works but not hcitools.
It seems people recommend to do a hci_reset before see 1 & 2.
Yet I don't understand how the code should be change to have a succesfull bluetooth initialisation - I tried my own code, but it fail the same. I am completely new to bluetooth stack, so can help much more.
Regards,
Yves
PS:
uname -a
Linux yves-huv 5.19.0-28-generic #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 15 12:05:40 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
$ sudo GoveeBTTempLogger output
btmon
outputThe text was updated successfully, but these errors were encountered: