discoverable setting shall only be store when changed via Discoverable
property and not when discovery client set it as that be considered
temporary just for the lifetime of the discovery.
Some PTS clients do not send all the mandatory apparams
when retrieving the phonebook. Clients such as car multimedia systems
cannot be fixed, therefore working around this issue by inserting
default apparams which makes these clients work as well.
Modernize PBAP phonebook-ebook plugin for newer libebook version
of the Evolution Data Server.
The ebook plugin was introduced during GSoC 2011 [1] and allows
BlueZ to share contacts stored in the Evolution Data Server to
connected clients such as car multimedia systems.
With the rise of Mobile Linux thanks to the PinePhone and Librem 5,
this plugin was modernized to compile with newer libebook versions
because the API was changed [2].
[1] http://www.bluez.org/gsoc-eds-backend-of-phonebook-access-profilepbap/
[2] https://wiki.gnome.org/Apps/Evolution/ESourceMigrationGuide
This patch adds a new UUID for the quality report experimental
feature. When reading the experimental features, it checks if
the new feature is supported by the controller and stores the
value in the quality_report_supported flag of the adapter.
The quality_report_supported flag could be used by the bluetoothd
to determine if the quality report feature can be enabled.
Reviewed-by: Miao-chen Chou <mcchou@chromium.org>
In probe_service, if the service already exists in device->services, it
returns the service. This might cause dev_probe and device_probe_profile
to add a duplicate service into device->services. When removing the
device, a double-free error might occur.
This patch changes the logic of probe_service so that the same service
will not be added to a device.
The spec says LE Set Random Address cannot be used when scan is enabled
or with legacy advertising:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E
page 2480
'If the Host issues this command when any of advertising (created
using legacy advertising commands), scanning, or initiating are
enabled, the Controller shall return the error code Command
Disallowed (0x0C).'
own_addr_type 0x01 and 0x03 shall check that a random address has
properly been set:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E
page 2496:
'If LE_Scan_Enable is set to 0x01, the scanning parameters'
Own_Address_Type parameter is set to 0x01 or 0x03, and the random
ddress for the device has not been initialized, the Controller shall
return the error code Invalid HCI Command Parameters (0x12).'
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E
page 2614:
'If Enable is set to 0x01, the scanning parameters' Own_Address_Type
parameter is set to 0x01 or 0x03, and the random address for the
device has not been initialized, the Controller shall return the
error code Invalid HCI Command Parameters (0x12).'
Race conditions with the cmd-sync changes can cause fail status codes to
be different than originally expected. New test parameter fail_tolerant
allows a trivial fail-code mismatches to "Pass" while also warning that
the status wasn't exactly as expected.
When channel_free is called and we are waiting for a command response
from the peer, bluez NULL the setup->session but would not free its
setup_cb. Since setup_cb holds a ref of setup, the setup wouldn't be
freed and if service_removed is called after channel_free, a2dp_cancel
tries to abort the ongoing avdtp commands, which accesses the
setup->session and triggers a crash.
This change finalizes all avdtp commands before assigning setup->session
to NULL in channel_free.
Crash stack trace:
0x000059f01943e688 (bluetoothd -avdtp.c:3690)
avdtp_abort
0x000059f01943928a (bluetoothd -a2dp.c:3069)
a2dp_cancel
0x000059f0194377fa (bluetoothd -sink.c:324)
sink_unregister
0x000059f01948715a (bluetoothd -service.c:177)
service_remove
0x000059f01948d77c (bluetoothd -device.c:5346)
device_remove
0x000059f019476d14 (bluetoothd -adapter.c:7202)
adapter_remove
0x000059f019476c3e (bluetoothd -adapter.c:10827)
adapter_cleanup
0x000059f01949d8d7 (bluetoothd -main.c:1114) main
0x0000787b36185d74 (libc.so.6 -libc-start.c:308)
__libc_start_main
0x000059f019433e39 (bluetoothd + 0x00026e39) _start
0x00007fff2d2c0127
Reviewed-by: Archie Pusaka <apusaka@chromium.org>
own_addr_type 0x01 and 0x03 shall check that a random address has
properly been set and in case of 0x03 the resolving list actually
contains the irk of the identity address:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E
page 2596
'If the advertising set's Own_Address_Type parameter is set to 0x01
and the random address for the advertising set has not been
initialized, the Controller shall return the error code Invalid HCI
Command Parameters (0x12).'
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E
page 2597
'If the advertising set's Own_Address_Type parameter is set to 0x03,
the controller's resolving list did not contain a matching entry, and
the random address for the advertising set has not been initialized,
the Controller shall return the error code Invalid HCI Command
Parameters (0x12).'
The time check in device lost timeout could cause DeviceLost never being
reported because of the following reasons:
1. Timer created in timeout_add_seconds, which calls
g_timeout_add_seconds_full internally, can be fired one second
earlier than |timeout| seconds.
2. When handle_device_lost_timeout is invoked early, time diff between
|curr_time| and |last_seen| could be less than |low_rssi_timeout|. In
this case, since handle_device_lost always returns FALSE, the
timer will be removed, but DeviceLost has not been reported yet.
3. If we never receives any advertisement from that peer since then,
DeviceLost will never be reported.
We can remove the checking in handle_device_lost_time because we restart
or remove the timer whenever an advertisement is received.
Reviewed-by: apusaka@chromium.org
Reviewed-by: mcchou@chromium.org
Reviewed-by: mmandlik@chromium.org
If a process tries to register a profile implementation that is already
registered, RegisterProfile should fail.
This should help address issues when two instances of PulseAudio are
running at the same time, and the second instance tries to register an
audio profile implementation that has already been registered by the
first instance. Two situations where this may happen is when more than
one user is logged in, or during the transition between the GDM session
and the user session, when PulseAudio gets started on the new session
before the old session has been fully terminated.
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/303https://gitlab.gnome.org/GNOME/gdm/-/issues/486
This patch clean up the queue for connection before closing the test to
prevent the potential memory leak.
==50== 32 bytes in 1 blocks are definitely lost in loss record 18 of 32
==50== at 0x483A809: malloc (vg_replace_malloc.c:307)
==50== by 0x14A37E: btd_malloc (util.c:33)
==50== by 0x149D9D: queue_new (queue.c:47)
==50== by 0x13B3C0: btdev_create (btdev.c:6042)
==50== by 0x13178E: create_vhci (hciemu.c:229)
==50== by 0x13178E: hciemu_new_num (hciemu.c:403)
==50== by 0x130E2C: read_index_list_callback (mgmt-tester.c:357)
==50== by 0x14AD91: request_complete (mgmt.c:264)
==50== by 0x14BD34: can_read_data (mgmt.c:356)
==50== by 0x14E794: watch_callback (io-glib.c:157)
==50== by 0x48B578E: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6400.6)
==50== by 0x48B5B17: ??? (in /usr/lib64/libglib-2.0.so.0.6400.6)
==50== by 0x48B5E32: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.6400.6)
==50==
==50== 32 bytes in 1 blocks are definitely lost in loss record 19 of 32
==50== at 0x483A809: malloc (vg_replace_malloc.c:307)
==50== by 0x14A37E: btd_malloc (util.c:33)
==50== by 0x149D9D: queue_new (queue.c:47)
==50== by 0x13B3C0: btdev_create (btdev.c:6042)
==50== by 0x1318F7: hciemu_client_new (hciemu.c:332)
==50== by 0x1318F7: hciemu_new_num (hciemu.c:412)
==50== by 0x130E2C: read_index_list_callback (mgmt-tester.c:357)
==50== by 0x14AD91: request_complete (mgmt.c:264)
==50== by 0x14BD34: can_read_data (mgmt.c:356)
==50== by 0x14E794: watch_callback (io-glib.c:157)
==50== by 0x48B578E: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6400.6)
==50== by 0x48B5B17: ??? (in /usr/lib64/libglib-2.0.so.0.6400.6)
==50== by 0x48B5E32: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.6400.6)
When toggling experimental features it may cause the old value to still
be in effect since it was read after read info which upon completion
would attempt to call adapter_register without first updating the
experimental features which could affect the likes of advertising
instances when LL Privacy is enabled.
The Patterns property description was not as clear as it could be. This
expands the text a bit, replaces the C enum value 0x01 with the D-Bus
property string value "or_patterns" and improves the grammar in a few
places.
UnregisterApplication is not doing anything since the apps queue is
never initialized which results in not finding any application when
unregistering.
Fixes: https://github.com/bluez/bluez/issues/126
The kernel will always send exactly one event, but the size of the
passed struct will depend on the length of the submitted read() and the
kernel version. i.e. the interface can be extended and we need to expect
for a read to be longer than expected if we ask for it.
Fix this by only requesting the needed length and explicitly check the
length against the V1 version of the structure to make the code a bit
more future proof in case the internal copy of the struct is updated to
contain new fields.
Based on the SPEC 5.2 Vol 4, Part E, Section 7.8.54, the
LE_Set_Extended_Advertising_Data_Command may be issued after an
advertising set identifed by the Advertising_Handle has been created
using the HCI_LE_Set_Extended_Advertising_Parameters command.
This patch fixes size comparison and variable misassignment.
Reviewed-by: Alain Michaud <alainm@chromium.org>
Reviewed-by: Michael Sun <michaelfsun@google.com>
A new flag was added to the kernel implementation of the Device Found
event, but had not been added to the parser leading to an "Unknown device
flag" error in btmon.
Reviewed-by: Yu Liu <yudiliu@google.com>
This checks if an outstanding call to AcquireWrite is already in
progress. If so, the write request is placed into the queue, but
AcquireWrite is not called again. When a response to AcquireWrite is
received, acquire_write_reply sends all queued writes over the acquired
socket.
Making multiple simultaneous calls to AcquireWrite makes no sense,
as this would open multiple socket pairs and only the last returned
socket would be used for further writes.
This fixes the calculation of available buffer space in
bt_gatt_server_send_notification and sends pending notifications
immediately when there is no more room to add a notification.
Previously there was a buffer overflow caused by incorrect calculation
of available buffer space: data->offset can equal data->len
from a previous call to this function, leading
(data->len - data->offset) to underflow after data->offset += 2.
