Hi Daniel, > An issue was found, where if a bluetooth client requests a broadcast > advertisement with scan response data, it will not be properly > registered with the controller. This is because at the time that the > hci_cp_le_set_scan_param structure is created, the scan response will > not yet have been received since it comes in a second MGMT call. With > empty scan response, the request defaults to a non-scannable PDU type. > On some controllers, the subsequent scan response request will fail due > to incorrect PDU type, and others will succeed and not use the scan > response. > > This fix allows the advertising parameters MGMT call to include a flag > to let the kernel know whether a scan response will be coming, so that > the correct PDU type is used in the first place. A bluetoothd change is > also incoming to take advantage of it. > > To test this, I created a broadcast advertisement with scan response > data and registered it on the hatch chromebook. Without this change, the > request fails, and with it will succeed. > > Reviewed-by: Alain Michaud <ala...@chromium.org> > Reviewed-by: Sonny Sasaka <sonnysas...@chromium.org> > Reviewed-by: Miao-chen Chou <mcc...@chromium.org> > Signed-off-by: Daniel Winkler <danielwink...@google.com> > --- > > include/net/bluetooth/mgmt.h | 1 + > net/bluetooth/hci_request.c | 3 ++- > net/bluetooth/mgmt.c | 1 + > 3 files changed, 4 insertions(+), 1 deletion(-)
patch has been applied to bluetooth-next tree. Regards Marcel
