In the case of our products, we lack a physical RFKILL switch and do
not have the rfkill module enabled in the kernel which resulted in an
error message each time bluetoothd was started.
This commit looks at the errno code after failing to open the RFKILL
device and only logs an error if it is something other than ENOENT
(No such file or directory).
Fixes: https://github.com/bluez/bluez/issues/792
This change is required in below PTS testcase:
1. FTP/SR/SGSIT/ATTR/BV-02-C
Attribute GSIT - Bluetooth Profile Descriptor List
Current FTP version 1.2 is being deprecated and withdrawn
from BT Sig, so it is mandatory to update the version to 1.3.
No additional changes are needed for supporting the new version.
This change is required for passing below PTS testcases:
1. PBAP/PSE/PBD/BV-02-C
2. PBAP/PSE/PBD/BV-03-C
3. PBAP/PSE/PBD/BI-01-C
4. PBAP/PSE/PBD/BV-13-C
5. PBAP/PSE/PBD/BV-14-C
6. PBAP/PSE/PBD/BV-17-C
PTS sends all the GET phonebook requests without extra params.
Therefore, the PBAP server is rejecting the requests with a
'Bad Request' response.
So append 'maxlistcount' as default param in GET request to
avoid testcase failure.
This fix is required for below PTS testcase:
1. PBAP/PCE/SSM/BV-10-C
Description - Verify that the PCE does not share its
PbapSupportedFeatures bits with a legacy server.
Incase of legacy server, check for 'supported features bit'
uint_32_t value instead of directly checking the pointer
holding the attribute.
As pointer 'data' won't be null as PbapSupportedFeatures
attribute is present in SDP record but it's value is zero.
This fix is required for passing below PTS testcases:
1. PBAP/PSE/PBD/BV-05-C
2. PBAP/PSE/PBD/BV-17-C
3. PBAP/PSE/PBB/BV-11-C
Even if the new missed calls value is zero, send it in GET response.
As per the PBAP spec, it is mandatory to include Newmissedcalls
tag in response incase of object name is 'mch.vcf' or 'cch.vcf'.
It will be better to include it in all GET response.
We no longer reconnect AVRCP session on AVDTP transport reconfiguration.
This breaks AVRCP volume after reconfiguration, since there's no volume
update event incoming.
Fix by keeping track of the latest volume in btd_device volume. It was
introduced to track volume changes that arrive when there are no
transports/players, but we should track all volume changes otherwise the
value can be out of date when we want to use it.
Fixes: 469a75ae18 ("sink: Fix transitioning to BTD_SERVICE_STATE_DISCONNECTED on idle")
If the stream has been confirmed to be closed it should be safe to
attempt to send SetConfiguration without having to wait for a period
since the remote end can assume no new stream would be created it may
end up disconnecting the session.
If the stream transition to AVDTP_STATE_IDLE it means the stream has
been disconnected, not the session, therefore
btd_service_disconnecting_complete shall not be called otherwise it may
trigger the policy plugin to disconnect AVRCP in cases like codec
reconfiguration.
If the stream transition to AVDTP_STATE_IDLE it means the stream has
been disconnected, not the session, therefore
btd_service_disconnecting_complete shall not be called otherwise it may
trigger the policy plugin to disconnect AVRCP in cases like codec
reconfiguration.
Fixes: https://github.com/bluez/bluez/issues/1003
Zephyr(1) has been using the same bus defines as Linux so tools likes of
btmon, etc, are able to decode the bus under HCI, so this attempts to
synchronize the definitions by adding the missing bus type IPC(11) and its
decoding string.
[1] https://github.com/zephyrproject-rtos/zephyr/pull/80808
Currently obexd uses session bus.
Distros where session bus is not supported and still obex profiles
are required in that case use system bus instead of session bus
which can be configured at run time.
An Command line option has been added to achieve it.
{ "system-bus", 's', 0, G_OPTION_ARG_NONE, &option_system_bus,
"Use System bus "}
we can use option obexd -s to use system bus.
This adds a new Broadcast Receiver test, for a Broadcast Sink
synchronizing to 2 Broadcasters, using defer setup.
ISO Broadcaster Receiver2 Defer - Success
This fixes memory leaks that appear in iso_accept_cb because a new io
channel is allocated but never unreferenced at the end of the test.
=================================================================
==20460==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 120 byte(s) in 1 object(s) allocated from:
#0 0x7dcddc8fbb37 in malloc ../../../../src/libsanitizer/asan/
asan_malloc_linux.cpp:69
#1 0x7dcddc719af9 in g_malloc (/lib/x86_64-linux-gnu/
libglib-2.0.so.0+0x62af9)
#2 0x7dcddc7722bd in g_io_channel_unix_new
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xbb2bd
#3 0x5d3fdfe28262 in iso_accept_cb tools/iso-tester.c:3004
Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0x7dcddc8fbb37 in malloc ../../../../src/libsanitizer/asan/
asan_malloc_linux.cpp:69
#1 0x7dcddc719af9 in g_malloc (/lib/x86_64-linux-gnu/
libglib-2.0.so.0+0x62af9)
#2 0x7dcddc70016f in g_io_channel_init
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4916f)
#3 0x7dcddc7722c8 in g_io_channel_unix_new
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xbb2c8)
#4 0x5d3fdfe28262 in iso_accept_cb tools/iso-tester.c:3004
SUMMARY: AddressSanitizer: 126 byte(s) leaked in 2 allocation(s).
66a8c522b64 ("adapter: Fix up address type when loading keys") didn't
fix all instances of wrong address type being loaded, so peripheral LTK
and IRK were still left with possible invalid types.
If a2dp_resume/a2dp_suspend are called while setup is being
reconfigured, they make the reconfiguration use wrong SEP. This occurs
if transport Acquire/Release are called while reconfiguration is waiting
for CLOSE_RSP.
Fix by failing a2dp_resume/suspend early without changing the setup, if
it is reconfiguring.
Such resume/suspend calls would in any case fail, because
avdtp_close(stream) has been done, so avdtp_suspend/resume would return
error.
User can cancel transport acquire by calling Release() while Acquire()
is in progress. This calls a2dp_cancel() which sends AVDTP_ABORT_CMD,
forcing AVDTP state transition to IDLE, and A2DP profile disconnects.
However, Release()/Acquire() should only result to transitions between
STREAMING/OPEN. The expected behavior is that either these calls return
error, or they block until the target state is reached.
Fix by: Release() during pending Acquire() first sends error reply to
the Acquire. Then it waits for START to complete, then sends SUSPEND,
and after that completes, then it replies.
This also fixes SetConfiguration() after canceled Acquire(), which
previously did not work due to AVDTP disconnect. Now it does
START/SUSPEND -> CLOSE -> reconfigure.
If the searched key is a prefix of the first key in the textfile,
the code will assume it's not the first line which is wrong.
The issue can be reproduced by a fuzzer. More context can be found in
https://issues.oss-fuzz.com/issues/42515619
To reproduce the issue, please kindly follow the instructions in
https://google.github.io/oss-fuzz/advanced-topics/reproducing/
Stack trace:
#0 0x55e1c450e7ce in find_key /src/bluez/src/textfile.c:133:9
#1 0x55e1c450e7ce in write_key /src/bluez/src/textfile.c:244:8
#2 0x55e1c450dc33 in LLVMFuzzerTestOneInput /src/fuzz_textfile.c:61:3
(...trace in fuzzer)
This fixes the following build error:
profiles/input/manager.c:102:4: error: implicit declaration of function ‘free’ [-Werror=implicit-function-declaration]
102 | free(uhid_enabled);
| ^~~~
This adds a call to g_dbus_set_debug which enabled debugging of D-Bus
messages when dynamic debug is enabled for main.c:
bluetoothd[3672799]: [:1.38799:method_call] > org.bluez.Device1.Connect [#761]
bluetoothd[3672799]: [:1.38799:error] < org.bluez.Error.Failed [#761]
In order to properly synchronize audio/video playback it is required
to report audio delay to the A2DP source. This commit allows connected
media application to update the Delay property of the A2DP transport
which will inform remote source about the playback delay.
In case when the transport is not acquired, everyone is allowed to set
the delay. However, when the transport is acquired only the owner can
modify the delay. This restriction is here to prevent interference
caused by 3rd party actors.
The functionality was tested by streaming audio between two hosts
running BlueZ Bluetooth stack.
This function allows to retrieve D-Bus message sender name in a property
setter callback. Message sender name might be required to limit write
access to authorized clients only.
For a BLE-only device, if the device is already paired and the upper
layer attempts to pair it again, the bdaddr_type will be set to
BDADDR_BREDR since the LE connection is already bonded. This causes the
device to use the BR/EDR bearer, which stalls the pairing procedure and
requires waiting for the pairing timeout.
The bluetoothctl log below shows the error result:
[bluetooth]# pair ED:8E:0E:B3:85:C1
Attempting to pair with ED:8E:0E:B3:85:C1
Pairing successful
[RAPOO BleMouse]# disconnect ED:8E:0E:B3:85:C1
Attempting to disconnect from ED:8E:0E:B3:85:C1
[RAPOO BleMouse]#
[bluetooth]# devices Paired
Device ED:8E:0E:B3:85:C1 RAPOO BleMouse
[bluetooth]# scan le
SetDiscoveryFilter success
Discovery started
[CHG] Controller 8C:FD:F0:21:84:17 Discovering: yes
[CHG] Device ED:8E:0E:B3:85:C1 RSSI: -38
[bluetooth]# scan off
Discovery stopped
[bluetooth]# pair ED:8E:0E:B3:85:C1
Attempting to pair with ED:8E:0E:B3:85:C1
[bluetooth]#
Failed to pair: org.freedesktop.DBus.Error.NoReply
If the stream goes IDLE while we have an outstanding request, connect_id
stays non-zero and is never cleared via a completion callback. As a
consequence, the profile on this device will never be connected
successfully again until BlueZ restarts.
If the stream goes IDLE while we have an outstanding request, connect_id
stays non-zero and is never cleared via a completion callback. As a
consequence, the profile on this device will never be connected
successfully again until BlueZ restarts.
In unicast, linked streams mean bidirectional CIS. Ucast stream can
have at most one linked stream.
Fix ucast streams to have only single link. This fixes eg. configuring
for AC 11(i).
When a transport is selected from bluetoothctl, a reply is expected.
Currently, if the method call is successful, no reply is sent, causing
the following error message in bluetoothctl:
transport.Failed to select: org.freedesktop.DBus.Error.NoReply
The same error can be reproduced for the unselect method.
This commit updates the select and unselect methods to send reply
messages.
This updates transport select to link transports together before calling
the "Select" method for each of them.
The bluetoothctl log below shows a Broadcast Sink detecting
2 streams from a source and selecting both of them. After the
first transport is acquired, the link is created and the first
transport goes active.
client/bluetoothctl
[bluetooth]# endpoint.register 00001851-0000-1000-8000-00805f9b34fb 0x06
[/local/endpoint/ep0] Auto Accept (yes/no): y
[/local/endpoint/ep0] Max Transports (auto/value): a
[/local/endpoint/ep0] Locations: 1
[/local/endpoint/ep0] Supported Context (value): 1
Capabilities:
03 01 ff 00 02 02 03 05 04 1a 00 f0 00 02 03 01
Metadata:
[bluetooth]# Endpoint /local/endpoint/ep0 registered
[bluetooth]# scan on
[bluetooth]# [NEW] Device 17:7A:80:64:A7:93 17-7A-80-64-A7-93
[17-7A-80-64-A7-93]# [NEW] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# [NEW] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# transport.select
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 State: broadcasting
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 State: broadcasting
[17-7A-80-64-A7-93]# transport.acquire
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
Links: /org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 acquiring complete
[17-7A-80-64-A7-93]# Acquire successful: fd 8 MTU 40:0
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 State: active
The btmon log shows that sync has been established with both BISes:
< HCI Command: LE Broadcast Isochronous Group Create Sync (0x08|0x006b)
BIG Handle: 0x00
BIG Sync Handle: 0x0000
Encryption: Unencrypted (0x00)
Broadcast Code[16]: 00000000000000000000000000000000
Maximum Number Subevents: 0x00
Timeout: 20000 ms (0x07d0)
Number of BIS: 2
BIS ID: 0x01
BIS ID: 0x02
> HCI Event: Command Status (0x0f) plen 4
LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19
LE Broadcast Isochronous Group Sync Estabilished (0x1d)
Status: Success (0x00)
BIG Handle: 0x00
Transport Latency: 0 us (0x000000)
NSE: 3
BN: 1
PTO: 1
IRC: 3
Maximum PDU: 40
ISO Interval: 10.00 msec (0x0008)
Connection Handle #0: 6
Connection Handle #1: 7
< HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13
Handle: 6
Data Path Direction: Output (Controller to Host) (0x01)
Data Path: HCI (0x00)
Coding Format: Transparent (0x03)
Company Codec ID: Ericsson Technology Licensing (0)
Vendor Codec ID: 0
Controller Delay: 0 us (0x000000)
Codec Configuration Length: 0
Codec Configuration[0]:
> HCI Event: Command Complete (0x0e) plen 6
LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
Status: Success (0x00)
Handle: 6
< HCI Command: LE Setup Isochronous Data Path (0x08|0x006e) plen 13
Handle: 7
Data Path Direction: Output (Controller to Host) (0x01)
Data Path: HCI (0x00)
Coding Format: Transparent (0x03)
Company Codec ID: Ericsson Technology Licensing (0)
Vendor Codec ID: 0
Controller Delay: 0 us (0x000000)
Codec Configuration Length: 0
Codec Configuration[0]:
> HCI Event: Command Complete (0x0e) plen 6
LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
Status: Success (0x00)
Handle: 7
The second transport can then be acquired and it will go straight
to active, since the fd has already been set:
[17-7A-80-64-A7-93]# transport.acquire
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
Links: /org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 acquiring complete
[17-7A-80-64-A7-93]# Acquire successful: fd 9 MTU 40:0
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 State: active
The transports can them be released one by one:
[17-7A-80-64-A7-93]# transport.release
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0
[17-7A-80-64-A7-93]# Transport fd disconnected
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis1/fd0 State: idle
[17-7A-80-64-A7-93]# Release successful
[17-7A-80-64-A7-93]# transport.release
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1
[17-7A-80-64-A7-93]# Transport fd disconnected
[17-7A-80-64-A7-93]# [CHG] Transport
/org/bluez/hci0/dev_17_7A_80_64_A7_93/bis2/fd1 State: idle
[17-7A-80-64-A7-93]# Release successful
This splits the transport set_state operation for unicast and broadcast,
by implementing it as a transport op. Unlike unicast, broadcast transports
need to be acquired/released separately, so changes in a transport state
should not affect its links.
This implements bap_update_links as transport op, since broadcast links
need to be handled differently for unicast, which only allows one link.
For broadcast, the property changed signal should be emitted everytime
a new link is added or removed.
This adds shared/bap support for enabling and starting multiple Broadcast
Sink streams. Stream enabling should fail if any other Broadcast Sink
streams are in the process of enabling or have been enabled for the same
source. Also, a stream that has been enabled and already has the fd set
should be started on the spot.
This adds support for a Broadcast Sink to synchronize to multiple BISes
from a Source.
BISes selected by the user need to be linked together and then enabled one
by one. The first enabled stream will enqueue all its links in a request
for PA and BIG sync. After BIG sync is established, the confirm callback
will be called for each BIS io created in the kernel. Each fd will be set
inside the corresponding link, even the links that have not yet been
enabled. The enabled links will be started as soon as the fds are ready.
This updates the stream state transition from CONFIG to ENABLING,
on enable for Broadcast Sink streams. This is done to differentiate
between streams discovered in the BASE after short-lived PA sync
and streams that have been selected and enabled by the user.
When a stream changes state, the update is notified to other drivers
that registered a state changed callback. These callbacks might further
change the stream state, leading to the stream being freed. To avoid
use after free errors post notifications, this commit adds support to
ref/unref streams, to make sure that the stream is kept alive until all
processing is completed. This also updates the switch condition post
notifications, to handle the stream based on its current state.
