This is a regression introduced by
7ece89b0b6 which cause the disconnection
to happen immediatelly when the last reference is droppped but since the
stream setup may have been started by the remove end there is a chance
a stream is currently ongoing in which case the previous behavior of
not disconnecting immediatelly is required in order to give time for the
end to complete any pending request.
server->seps contains avdtp_local_sep not a2dp_sep causing the
following crash:
Invalid read of size 4
at 0x426EF8: avdtp_sep_get_state (avdtp.c:3655)
by 0x41D474: a2dp_avdtp_get (a2dp.c:1413)
by 0x42BE80: resume_a2dp (transport.c:340)
by 0x42C0D3: acquire (transport.c:466)
by 0x4CE702: process_message.isra.3 (object.c:259)
by 0x4CEF34: generic_message (object.c:1079)
by 0x53BB57F: ??? (in /usr/lib64/libdbus-1.so.3.19.0)
by 0x53AC3A9: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.19.0)
by 0x4C935F: message_dispatch (mainloop.c:72)
by 0x50C9C26: ??? (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD246: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD5E7: ??? (in /usr/lib64/libglib-2.0.so.0.5200.3)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
avdtp_unref would actually wait 1 second before disconnecting which may
be enough for the remote device to start a new stream when it should
not be able to that anymore.
This allows to skip SDP search for DualShock 3 devices, since some
DS3 clones do not provide any SDP record. This allows them to operate
nonetheless.
The HID SDP record is lifted straight off an original DualShock 3
controller. The PNPID SDP record is not set as not required to provide
a working device.
Tested with a "SHANWAN" clone controller.
Cancelling all the pending requests on the device is not needed as
bt_gatt_client_free() already does this for us.
There's also no need to explicitly unregister our notification, as this
will be done once the device has been disconnected, or not setup for
notifications yet.
==14797== Invalid read of size 1
==14797== at 0x1825E7: ba2str (bluetooth.c:79)
==14797== by 0x173DF4: change_state (service.c:101)
==14797== by 0x148ECA: batt_disconnect (battery.c:348)
==14797== by 0x174564: btd_service_disconnect (service.c:293)
==14797== by 0x4EA551C: g_slist_foreach (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x17AC71: att_disconnected_cb (device.c:4661)
==14797== by 0x1972D7: queue_foreach (queue.c:220)
==14797== by 0x19B831: disconnect_cb (att.c:590)
==14797== by 0x1A4482: watch_callback (io-glib.c:170)
==14797== by 0x4E86BB6: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x4E86F5F: ??? (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x4E87271: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x121604: main (main.c:770)
==14797== Address 0x74ad69b is 11 bytes inside a block of size 624 free'd
==14797== at 0x4C30D18: free (vg_replace_malloc.c:530)
==14797== by 0x4E8C4AD: g_free (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x1935CD: remove_interface (object.c:667)
==14797== by 0x193AC9: g_dbus_unregister_interface (object.c:1391)
==14797== by 0x148EC0: batt_disconnect (battery.c:346)
==14797== by 0x174564: btd_service_disconnect (service.c:293)
==14797== by 0x4EA551C: g_slist_foreach (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x17AC71: att_disconnected_cb (device.c:4661)
==14797== by 0x1972D7: queue_foreach (queue.c:220)
==14797== by 0x19B831: disconnect_cb (att.c:590)
==14797== by 0x1A4482: watch_callback (io-glib.c:170)
==14797== by 0x4E86BB6: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x4E86F5F: ??? (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x4E87271: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x121604: main (main.c:770)
==14797== Block was alloc'd at
==14797== at 0x4C31A1E: calloc (vg_replace_malloc.c:711)
==14797== by 0x17FF6C: device_new (device.c:3648)
==14797== by 0x180FDE: device_create_from_storage (device.c:3712)
==14797== by 0x169495: load_devices (adapter.c:3826)
==14797== by 0x16FF6B: adapter_register (adapter.c:7742)
==14797== by 0x16FF6B: read_info_complete (adapter.c:8285)
==14797== by 0x197D57: request_complete (mgmt.c:261)
==14797== by 0x198824: can_read_data (mgmt.c:353)
==14797== by 0x1A4482: watch_callback (io-glib.c:170)
==14797== by 0x4E86BB6: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x4E86F5F: ??? (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x4E87271: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5400.1)
==14797== by 0x121604: main (main.c:770)
This is required for custom advertising data.
The HAL entry points related to multiadvertising are now implemented
and map to the mgmnt "add advertising" operation.
The Battery Level characteristic was tested with a
Microsoft Arc Touch Mouse SE.
The Battery1 interface is now exported for Bluetooth LE devices which
support the Battery Level characteristic, providing a single
"Percentage" value to other integration points in the OS, such as UPower
for consumption on most free desktops.
See https://bugs.freedesktop.org/show_bug.cgi?id=92370
Since this glibc commit:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=37f802f86400684c8d13403958b2c598721d6360
glibc doesn't include declare ssize_t when fcntl.h is included (fcntl.h
included <bits/uio.h> which includes <sys/types.h>).
This fixes the following compile-time error:
In file included from obexd/plugins/mas.c:41:0:
./obexd/src/obex.h:37:1: error: unknown type name ‘ssize_t’; did you mean ‘size_t’?
ssize_t obex_get_size(struct obex_session *os);
^~~~~~~
This adds the following command which can be used to control the
advertisement intervals:
[bluetooth]# set-advertise-duration 4
[bluetooth]# set-advertise-timeout 4
[bluetooth]# advertise on
[CHG] Controller B8:8A:60:D8:17:D7 SupportedInstances: 0x04
[CHG] Controller B8:8A:60:D8:17:D7 ActiveInstances: 0x01
Advertising object registered
[CHG] Controller B8:8A:60:D8:17:D7 SupportedInstances: 0x05
[CHG] Controller B8:8A:60:D8:17:D7 ActiveInstances: 0x00
This adds implementation of Duration and Timeout property and properly
set them in Add Advertising:
@ MGMT Command: Add Advertising (0x003e) plen 11
Instance: 1
Flags: 0x00000003
Switch into Connectable mode
Advertise as Discoverable
Duration: 4
Timeout: 0
Advertising data length: 0
Scan response length: 0
When data is too much, the data may include values not making sense, so
this patch clears the advertising manufacturer/service data corresponding
to the running command.
Even if running set-advertise-manufacturer with data having an invalid
value, client does not clear the advertising service data and clears the
advertising manufacturer data.
Since get_ccc_state can be called from both read and write callbacks it
was causing the disconnect handler to be register twice causing the
following crash:
bluetoothd[31312]: src/gatt-database.c:att_disconnected()
bluetoothd[31312]: src/gatt-database.c:ccc_write_cb() External CCC write received with value: 0x0000
bluetoothd[31312]: src/gatt-database.c:att_disconnected()
Invalid read of size 8
at 0x475639: att_disconnected (gatt-database.c:301)
by 0x4D6C75: disconn_handler (att.c:538)
by 0x4D22EF: queue_foreach (queue.c:220)
by 0x4D8959: disconnect_cb (att.c:590)
by 0x4E559A: watch_callback (io-glib.c:170)
by 0x50CD246: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD5E7: ??? (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD901: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x40CD10: main (main.c:770)
Address 0x8e30250 is 0 bytes inside a block of size 32 free'd
at 0x4C2FD18: free (vg_replace_malloc.c:530)
by 0x4756D5: device_state_free (gatt-database.c:271)
by 0x4756D5: att_disconnected (gatt-database.c:313)
by 0x4D6C75: disconn_handler (att.c:538)
by 0x4D22EF: queue_foreach (queue.c:220)
by 0x4D8959: disconnect_cb (att.c:590)
by 0x4E559A: watch_callback (io-glib.c:170)
by 0x50CD246: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD5E7: ??? (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x50CD901: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x40CD10: main (main.c:770)
This includes the link type into the options passed to ReadValue and
WriteValue, with this the implementation can pass tests such as
TP/GAR/CL/BI-34-I which requires specific errors to be reported
depending on the bearer.
The spec suggests to rely on the link supervision timeout to detect
when the remote is not responding but this ignores the fact that due
to a bug or bad implementation stacks may ignore the request causing
the whole request queue to stall.
If no callback is set that means the request don't care about the
response, so instead of putting such request into the pending queue
this proceeds to send them immediately.
This fixes the following problems:
plugins/sixaxis.c:443:7: error: ‘version’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!setup_device(fd, sysfs_path, name, source, vid, pid, version, type, adapter))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
plugins/sixaxis.c:409:34: note: ‘version’ was declared here
uint16_t bus, vid, pid, source, version;
^~~~~~~
plugins/sixaxis.c:443:7: error: ‘source’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!setup_device(fd, sysfs_path, name, source, vid, pid, version, type, adapter))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
plugins/sixaxis.c:409:26: note: ‘source’ was declared here
uint16_t bus, vid, pid, source, version;
^~~~~~
cc1: all warnings being treated as errors
And many instances of code going over 80 columns.
This patch adds support for "pairing" a Dualshock4 controller over USB
into the sixaxis plugin, similarly to what the Sixaxis/PS3 controller
supported.
Actual bonding happens on first connection, but the device will be
marked as trusted when the agent replies.
This patch is based on DS4 supprt for sixpair tool by t0xicCode:
975c38cb6c
Move the struct containing the Sixaxis-compatible devices to a
header shared with the input profiles code, so as to reduce device
declaration.
Adding support for new devices should be as easy as adding the device's
declaration in profiles/input/sixaxis.h
Previously, users doing cable configuration of Sixaxis PS3 controllers
would only get asked whether a device was allowed to connect to the
computer when switching it to Bluetooth mode: unplugging it, and
pressing the PS button.
Instead, we should ask the user straight away, through the agent,
whether the pad should be allowed to connect.
This makes it easier to setup those devices, while keeping security.
Add btd_request_authorization_cable_configured() function to allow
cable configured devices to ask the user straight away about whether the
device should be allowed to connect to the computer.
This allows us to ask the user at the time of the USB connection and
initial setup, rather than when the first Bluetooth connection is made.
The fact that the device might not be connected to the adapter when
this event is triggered is mentioned in the Agent API docs.
While testing advertisement, I encountered Seg fault in client, when bluetoothd
tries to fetch the Adv data set by client. It can happen either while fetching
Manufacturer specific data or Service data. Backtrace is provided below for reference
After fix is applied, advertisement works fine for me. I am sending the following patch
your review. Thank you.
Passing val instead of &val in dbus_message_iter_append_fixed_array
DBUS API causes segmentation fault while fecthing Manufacturer
data or service data set by client.
BT Before Fix:
[bluetooth]# set-advertise-name Test
[bluetooth]# set-advertise-uuids 0x1824
[bluetooth]# set-advertise-manufacturer 0x75 0x02 0x03 0x04
[bluetooth]# advertise on
Program received signal SIGSEGV, Segmentation fault.
in append_array_variant(iter=iter@entry=0x7fffffffd780,
val=val@entry=0x62485a <ad+90>, n_elements=n_elements@entry=3, type=121) at client/advertising.c:178
in dict_append_basic_array(type=121, n_elements=3,
val=0x62485a <ad+90>, key=0x624858 <ad+88>, key_type=113, dict=0x7fffffffd730) at client/advertising.c:205
get_manufacturer_data(property=<optimized out>, iter=0x7fffffffd840,
user_data=<optimized out>) at client/advertising.c:253
After Fix:
[bluetooth]# set-advertise-name Test
[bluetooth]# set-advertise-uuids 0x1824
[bluetooth]# set-advertise-manufacturer 0x75 0x02 0x03 0x04
[bluetooth]# advertise on
[CHG] Controller 00:19:0E:11:55:44 SupportedInstances: 0x04
[CHG] Controller 00:19:0E:11:55:44 ActiveInstances: 0x01
Advertising object registered
[bluetooth]#
Add the common function cmd_usage(), which displays the specified command
name and the argument text in all_cmd corresponded to it, replace each
command specific usage with this function.
Add the argument texts based on the usage of each command to the output of
the command help. So the command help can give overview easier than using
the option --help of each command.
The command remote-oob may process an invalid value and hit the following
segfault since getopt_long() returns the character 'h' for hash option
when passing the option --help to remote-oob.
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x0000000000415e25 in hex2bin (hexstr=0x0, buf=buf@entry=0x7ffd85c799f7 "", buflen=16) at tools/btmgmt.c:140
#2 0x0000000000416caf in cmd_remote_oob (mgmt=0x1cc2010, index=<optimized out>, argc=2, argv=0x1cdff10) at tools/btmgmt.c:3213
#3 0x000000000041465b in rl_handler (input=0x1cd6240 "remote-oob --help") at tools/btmgmt.c:4685
#4 0x00007fd627fd96f5 in rl_callback_read_char () from /lib/x86_64-linux-gnu/libreadline.so.6
#5 0x000000000040fc71 in prompt_read (io=<optimized out>, user_data=<optimized out>) at tools/btmgmt.c:4750
#6 0x0000000000430089 in io_callback (fd=<optimized out>, events=1, user_data=0x1cc2bc0) at src/shared/io-mainloop.c:123
#7 0x0000000000430d4b in mainloop_run () at src/shared/mainloop.c:157
#8 0x0000000000402caf in main (argc=0, argv=0x7ffd85c79d50) at tools/btmgmt.c:4847
