This adds the following tests based on BAP Audio Configurations:
ISO AC 1 & 4 - Success
ISO AC 2 & 10 - Success
ISO AC 3 & 5 - Success
ISO AC 6(i) - Success
ISO AC 6(ii) - Success
ISO AC 7(i) - Success
ISO AC 7(ii) - Success
ISO AC 8(i) - Success
ISO AC 8(ii) - Success
ISO AC 9(i) - Success
ISO AC 9(ii) - Success
ISO AC 11(i) - Success
ISO AC 11(ii) - Success
This fixes the following tests now that all supported PHYs are enabled
by default:
Start Discovery LE - (Ext Scan Param) Failed
Get PHY Success Failed
Set PHY 1m 2m coded Succcess Timed out
This adds support for advertise.rsi command which can be used to request
the generation of RSI and include it as part of advertising data:
[bluetooth]# advertise.rsi --help
Show/Enable/Disable RSI to be advertised
Usage:
rsi [on/off]
[bluetooth]# advertise.rsi
RSI: on
[bluetooth]# advertise on
...
Advertising object registered
Tx Power: off
Name: off
Appearance: off
Discoverable: on
RSI: on
[bluetooth]#
This adds support for "rsi" when a SIRK has been set on main.conf, the
clients can then enable it via Includes property which will make the
daemon to automatically generate an RSI (hash+random) and include it as
part of the advertising data:
< HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 15
Handle: 0x01
Operation: Complete extended advertising data (0x03)
Fragment preference: Minimize fragmentation (0x01)
Data length: 0x0b
Resolvable Set Identifier: E2-4E-AA-1B-2B-61
Hash: 0x1b2b61
Random: 0xe24eaa
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
This adds "rsi" as possible value to SupportedIncludes so when it is
available it means client and set it on its Includes property so a
proper RSI is generated and included as part of the Advertising Data.
This fixes the out-of-bounds array access in mesh-io-mgmt.c caught
by address sanitizer. Similar fixes were applied earlier to
generic and unit IOs. With this patch, the common code is factored
into a centralized location.
discovery_filter_to_mgmt_cp() does not add discovery_filter.discoverable
to the created mgmt_cp_start_service_discovery struct.
Instead update_discovery_filter() separately checks
client->discovery_filter->discoverable for all clients.
This means that for discovery-filters which only have the discoverable
flag set, to put the adapter in discoverable mode while discovering,
the created mgmt_cp_start_service_discovery struct is empty.
This empty mgmt_cp_start_service_discovery struct then gets sent
to the kernel as part of a MGMT_OP_START_SERVICE_DISCOVERY msg
by start_discovery_timeout().
This use of an empty filter with MGMT_OP_START_SERVICE_DISCOVERY
causes some bluetooth devices to not get seen with some (most?)
Broadcom bluetooth adapters. This problem has been observed with
the following Broadcom models: BCM4343A0, BCM43430A1, BCM43341B0 .
On these models the following 2 devices were not being discovered
when starting a scan with a filter with just discoverable set
in the filter (as gnome-bluetooth does):
Device 09:02:01:03:0F:87 (public)
Name: Bluetooth 3.0 Keyboard
Alias: Bluetooth 3.0 Keyboard
Class: 0x00000540
Icon: input-keyboard
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: yes
UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v05ACp022Cd011B
Device 00:60:D1:00:00:34 (public)
Name: Bluetooth Mouse
Alias: Bluetooth Mouse
Class: 0x00002580
Icon: input-mouse
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: usb:v0103p0204d001E
Since setting the discoverable flag on a filter only is a way to
automatically put the adapter in discoverable mode itself while
it is discovering; and since this does not any device filtering
at all; modify merge_discovery_filters() to treat discovery with
such filters as regular unfiltered discovery.
This results in start_discovery_timeout() starting regular
discovery through a MGMT_OP_START_DISCOVERY message and this
fixes these 2 example devices not getting discovered by the
mentioned Broadcom BT adapter models.
Link: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/merge_requests/163
Reviewed-by: Bastien Nocera <hadess@hadess.net>
The following crash can be observed if the remote peer send and
unsupported event:
ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000148f11
at pc 0x559644552088 bp 0x7ffe28b3c7b0 sp 0x7ffe28b3c7a0
WRITE of size 1 at 0x60b000148f11 thread T0
#0 0x559644552087 in avrcp_handle_event profiles/audio/avrcp.c:3907
#1 0x559644536c22 in control_response profiles/audio/avctp.c:939
#2 0x5596445379ab in session_cb profiles/audio/avctp.c:1108
#3 0x7fbcb3e51c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43)
#4 0x7fbcb3ea66c7 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xaa6c7)
#5 0x7fbcb3e512b2 in g_main_loop_run (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x552b2)
#6 0x559644754ab6 in mainloop_run src/shared/mainloop-glib.c:66
#7 0x559644755606 in mainloop_run_with_signal src/shared/mainloop-notify.c:188
#8 0x5596445bb963 in main src/main.c:1289
#9 0x7fbcb3bafd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#10 0x7fbcb3bafe3f in __libc_start_main_impl ../csu/libc-start.c:392
#11 0x5596444e8224 in _start (/usr/local/libexec/bluetooth/bluetoothd+0xf0224)
Add mgmt-tester tests for hci devcoredump. These testa trigger the
devcoredump with a test data and verifies the generated devcoredump
file for the test data and correct devcoredump header fields.
If the device is marked as auto-connect the kernel may initiate the
connection spontaneously causing new connections to not have set the
state->initiator flag properly.
This caches any IRK being parsed so they can be used to resolve
addresses later which fixes the problem of only being able to resolve
addresses if the monitor happens to be active while SMP exchange the
keys.
Device using RPA have its storage using its identity address so this
uses keys_resolve_identity to attempt to resolve the destination
address instead of always using the connection address.
This prints the value attribute information when print attribute
descriptors:
< ACL Data TX: Handle 3585 flags 0x00 dlen 9
ATT: Write Request (0x12) len 4
Handle: 0x002c Type: Client Characteristic Configuration (0x2902)
Value Handle: 0x002b Type: Battery Level (0x2a19)
Data: 0100
Notification (0x01)
This adds support for -i/--init-script which can be used to provide a
file with commands to be initialized, the commands are then run in
sequence after completing:
client/bluetoothctl -i client/power-on-off.bt
Agent registered
Changing power on succeeded
[CHG] Controller A8:7E:EA:56:87:D5 Pairable: yes
[CHG] Controller 98:8D:46:EE:6D:16 Pairable: yes
[CHG] Controller 98:8D:46:EE:6D:16 PowerState: on-disabling
AdvertisementMonitor path registered
Data field were print twice (1 time incorrectly):
> ACL Data RX: Handle 64 flags 0x02 dlen 19
ATT: Signed Write Command (0xd2) len 14
Handle: 0x006f Type: Vendor specific (f7debc9a-7856-3412-7856-341278563412)
Data: 0800000087f303c224516133
Data:
Signature: 0800000087f303c224516133
It will accept file when obex agent replied any message
event though the message is org.bluez.obex.Error.Rejected.
The patch helps to reject a Bluetooth object push request if
user replied "org.bluez.obex.Error.Rejected" message according
to the doc/obex-agent-api.txt.
Any error while setting absolute volume on the peer, or notifying the
peer of changes was previously going completely unnoticed. Propagate it
to the logs and back to the DBus "Volume" property setter so that they
aren't misled into thinking that the AVRCP command succeeded.
Note that an error is mostly harmless when the setter of the property is
an audio sink and the peer the audio source: in this case we're only
_notifying_ the peer of the change when it has already been applied on
the sink.
Also improve the other two error messages to more closely describe what
was "invalid" about the argument.
When attaching a local provisioner node, always request own
composition data to accommodate functional consolidation of
regular and remote provisioning mechanisms.
The knowledge of the own node composition is necessary for
provisioning initiation and self configuration.
This fixes the situation when subsequent requests to get a node
composition result in appending element's model list with duplicate models.
This adds a check for a presence of a model on an element when attempting
to add a new model ID to a model list on this element.
Add CIG, CIS, and PHY properties to BAP transport. The other QoS
properties are there, and these may also be useful to clients, e.g. to
manage CIG/CIS allocation as client.
Hide transport QoS properties when they are not configured.
Notifications were using bt_att_send directly instead of
bt_gatt_client_write_value thus it wouldn't create a request which
causes the instance to not be able to track it which in turn may cause
the client to trigger its idle callback too early.
Fixes: https://github.com/bluez/bluez/issues/490
If remote device does not respond to a Prov Link Open request, then the
callbacks do not get established, and attempting to send Failure
messages on the non-existent link rersult in seg fault.
The mesh daemon can process incoming mesh packets on more than one
controller, but if a Provisioning data packet that originated from the
local daemon is received by a different controller, it must be filtered
and disregarded, or it will break the provisioning protocol.
Because the daemon explicitly supports multiple nodes, we need
local Config Clients to be able to see local unprovisioned devices.
This loops the unprovisioned beacon, so that local Provisioning servers
can see it.
Fixes Issue: https://github.com/bluez/bluez/issues/341
This fixes the following crash:
Invalid read of size 8
at 0x1E1E0B: bt_gatt_client_idle_unregister (gatt-client.c:3812)
by 0x1EB6BD: bt_bap_detach (bap.c:3821)
by 0x1EB6BD: bt_bap_detach (bap.c:3808)
by 0x1D5631: queue_foreach (queue.c:207)
by 0x1DCAA3: disconnect_cb (att.c:713)
by 0x1F4404: watch_callback (io-glib.c:157)
by 0x48BBC7E: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.7400.6)
by 0x4912117: ??? (in /usr/lib64/libglib-2.0.so.0.7400.6)
by 0x48BB24E: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.7400.6)
by 0x1F4A54: mainloop_run (mainloop-glib.c:66)
by 0x1F4E21: mainloop_run_with_signal (mainloop-notify.c:188)
by 0x1304B4: main (main.c:1428)
Address 0x28 is not stack'd, malloc'd or (recently) free'd
Some platforms use different filtering and for this purpose,
some of the ACL/SCO/ISO/SDP data is truncated.
In such a case, included length is smaller than the original size.
Without this fix, btmon stops working after first truncated packet.
Audio Locations and Contexts are properties of the PACS service, not of
individual PAC, as these are device-wide bitmaps and a single
characteristic may exist on PACS server (PACS v1.0 Sec 3).
Move the attributes out from bt_bap_pac to bt_bap_pacs, and actually
keep track of the values.
The following set can be observed when a sirk is exists but it is
encrypted leading to info->set to not be set:
Invalid read of size 8
at 0x1ACDF0: append_set (device.c:1662)
by 0x1FFEFFF7DF: ???
by 0x1D4461: queue_foreach (queue.c:207)
by 0x1AC8DE: dev_property_get_set (device.c:1700)
by 0x1CF3E2: append_property (object.c:498)
by 0x1CFA91: append_properties (object.c:527)
by 0x1CFAFD: append_interface (object.c:542)
by 0x48D7CEF: g_slist_foreach (gslist.c:887)
by 0x1CF5A7: append_interfaces (object.c:1104)
by 0x1CF5A7: append_object (object.c:1119)
by 0x48D7CEF: g_slist_foreach (gslist.c:887)
by 0x1CF5D0: append_object (object.c:1122)
by 0x48D7CEF: g_slist_foreach (gslist.c:887)
Address 0x8 is not stack'd, malloc'd or (recently) free'd
This fixes the following trace:
Invalid read of size 1
at 0x1F4282: bt_csip_get_sirk (csip.c:812)
by 0x176B21: csip_ready (csip.c:259)
by 0x1F3C74: csip_notify_ready (csip.c:578)
by 0x1F3C74: csip_idle (csip.c:659)
by 0x1DCDCC: idle_notify (gatt-client.c:171)
by 0x1D579A: queue_remove_if (queue.c:279)
by 0x1D584F: queue_remove_all (queue.c:321)
by 0x1E036F: notify_client_idle (gatt-client.c:180)
by 0x1E036F: request_unref (gatt-client.c:199)
by 0x1DC60D: destroy_att_send_op (att.c:211)
by 0x1DC60D: handle_rsp (att.c:874)
by 0x1DC60D: can_read_data (att.c:1064)
by 0x1F43F4: watch_callback (io-glib.c:157)
by 0x48BBC7E: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.7400.6)
by 0x4912117: ??? (in /usr/lib64/libglib-2.0.so.0.7400.6)
by 0x48BB24E: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.7400.6)
Address 0x0 is not stack'd, malloc'd or (recently) free'd