Removes the output of redundant commands in bluetooth-player since the
previous patch ("shared/shell: Fix hidden default menu if no submenu")
made bluetooth-player output the default menu.
This adds the option to connect via either Node Identity or Network ID
advertisements. Adding the node unicast address selects Node Identity.
See Mesh Profile Specification 7.2.2.2 for further details.
When obexctl is run after starting to transfer a file, the transferred
size and the remaining time will be extreme values first as below:
[NEW] Transfer /org/bluez/obex/server/session8/transfer6
[CHG] Transfer /org/bluez/obex/server/session8/transfer6 Transferred: 1670741 (@1670KB/s 03:52)
[CHG] Transfer /org/bluez/obex/server/session8/transfer6 Transferred: 1703502 (@32KB/s 197:14)
[CHG] Transfer /org/bluez/obex/server/session8/transfer6 Transferred: 1736263 (@32KB/s 197:13)
1. Setup PS3 controller through cable pairing
2. Remove device from BlueZ's database
3. Plug original PS3 controller back
As we don't change the master bdaddr on the device itself, the joypad
will likely be trying to connect to BlueZ, and fail to connect after a
small period of time. But the device will appear connected just long
enough for the cable pairing to say "hey, I already have this setup".
Ideally, we would test for whether the device is temporary, or already
trusted, but testing for whether we've setup its internal services *and*
it's connected, rather than *or*, is sufficient.
When obexd is started with the option auto-accept or the agent is killed
after starting to transfer a file, obexd crashes due to cancellation of
the transfer from a client as below:
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x0
at 0x158A40: transfer_cancel (manager.c:272)
by 0x18A5D2: process_message.isra.4 (object.c:259)
by 0x18AE44: generic_message (object.c:1079)
by 0x5290FD2: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.14.13)
by 0x5282623: dbus_connection_dispatch (in /lib/x86_64-linux-gnu/libdbus-1.so.3.14.13)
by 0x184DBF: message_dispatch (mainloop.c:72)
by 0x5505E24: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
by 0x55061EF: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
by 0x5506501: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
by 0x137902: main (main.c:322)
There is an error in meshctl while displaying transition time. 1000 ms
is being presented as 16 sec, 40 ms. The reason is incorrect
conversion of milliseconds to seconds. The fix is pretty trivial.
AVRCP spec does allow duplicates folder names which would be exposed as
different D-Bus path as their UID is different, the code however would
attempt to set the folder by its name alone which resolve to the first
item on the list rather then the exact UID.
btd_service_set_user_data shall be allowed to be called when the state is
unavailable since device_probe is called with that state the callback
attempt to set its user_data.
When both controller and target roles are supported by a device they
would share the same btd_service user_data pointer which would lead to
use after free once either service is removed.
Make control_disconnect() a no-op if control was already
disconnected and freed.
bluetoothd[8436]: profiles/audio/avrcp.c:avrcp_disconnect() path /org/bluez/hci0/dev_38_71_DE_C0_FC_26
==8436== Invalid read of size 8
==8436== at 0x41FFB9: control_disconnect (control.c:130)
==8436== by 0x469E0A: service_remove (service.c:177)
==8436== by 0x475869: device_remove (device.c:4071)
==8436== by 0x45DEF9: adapter_remove (adapter.c:5485)
==8436== by 0x466B2A: adapter_cleanup (adapter.c:8679)
==8436== by 0x40BE16: main (main.c:782)
==8436== Address 0x84b8ac8 is 8 bytes inside a block of size 48 free'd
==8436== at 0x4C30D18: free (vg_replace_malloc.c:530)
==8436== by 0x50D44AD: g_free (in /usr/lib64/libglib-2.0.so.0.5400.2)
==8436== by 0x488AED: remove_interface (object.c:667)
==8436== by 0x488FE9: g_dbus_unregister_interface (object.c:1391)
==8436== by 0x469E20: service_remove (service.c:179)
==8436== by 0x475869: device_remove (device.c:4071)
==8436== by 0x45DEF9: adapter_remove (adapter.c:5485)
==8436== by 0x466B2A: adapter_cleanup (adapter.c:8679)
==8436== by 0x40BE16: main (main.c:782)
==8436== Block was alloc'd at
==8436== at 0x4C31A1E: calloc (vg_replace_malloc.c:711)
==8436== by 0x50D43F0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.5400.2)
==8436== by 0x41FC09: control_init (control.c:320)
==8436== by 0x42006D: control_init_remote (control.c:361)
==8436== by 0x469D59: service_probe (service.c:160)
==8436== by 0x46E464: probe_service (device.c:4207)
==8436== by 0x46E4C2: dev_probe (device.c:4226)
==8436== by 0x46989B: btd_profile_foreach (profile.c:708)
==8436== by 0x47239D: device_probe_profiles (device.c:4285)
==8436== by 0x50ED51C: g_slist_foreach (in /usr/lib64/libglib-2.0.so.0.5400.2)
==8436== by 0x50ED54A: g_slist_free_full (in /usr/lib64/libglib-2.0.so.0.5400.2)
==8436== by 0x45F1EE: load_devices (adapter.c:3864)
==8436== by 0x465E59: adapter_register (adapter.c:7741)
==8436== by 0x465E59: read_info_complete (adapter.c:8284)
==8436== by 0x48D277: request_complete (mgmt.c:261)
==8436== by 0x48DD44: can_read_data (mgmt.c:353)
==8436== by 0x4999A2: watch_callback (io-glib.c:170)
==8436== by 0x50CEBB6: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5400.2)
==8436== by 0x50CEF5F: ??? (in /usr/lib64/libglib-2.0.so.0.5400.2)
==8436== by 0x50CF271: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5400.2)
==8436== by 0x40BDE8: main (main.c:770)
passthrough commands comes from a different specification which can
have more specific rules regarding timeout, etc, so this moves button
presses to their own queue which should enable them to be send in
parallel to other command on the control channel.
If and interface is removed while properties are pending it would cause
process_properties_from_interface to clear data->pending_prop when it
should only clear the iface->pending_prop.
If the command completion without any character is run, then only returns
the commands of default menu since readline increases the variable state
during each matching and tools specific menu is not compared.
A fd is duplicated if dbus type is unix fd, and then it is not closed
even after the file is finished transporting. In the end obexd can not
transport due to the limitation of open-able fd as below.
Warning: invalid file descriptor 1031 in syscall fcntl(DUPFD_CLOEXEC)()
FILE DESCRIPTORS: 1021 open at exit.
Open pf-31 socket 1023:
at 0x5061F1F: fcntl_common (fcntl.c:46)
by 0x5061F1F: fcntl (fcntl.c:79)
by 0x52A1C3D: _dbus_dup (in /lib/x86_64-linux-gnu/libdbus-1.so.3.14.13)
by 0x528C7B8: dbus_message_iter_get_basic (in /lib/x86_64-linux-gnu/libdbus-1.so.3.14.13)
by 0x149E04: profile_new_connection (bluetooth.c:136)
by 0x18AAF2: process_message.isra.3 (object.c:259)
by 0x18B364: generic_message (object.c:1079)
by 0x5290FD2: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.14.13)
by 0x5282623: dbus_connection_dispatch (in /lib/x86_64-linux-gnu/libdbus-1.so.3.14.13)
by 0x1852FF: message_dispatch (mainloop.c:72)
by 0x5505E24: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
by 0x55061EF: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
by 0x5506501: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
disconnect callback was writing on the argv pointer causing word
wordfree to access invalid memory:
Invalid free() / delete / delete[] / realloc()
at 0x4C2FD18: free (vg_replace_malloc.c:530)
by 0x56E8588: wordfree (in /usr/lib64/libc-2.25.so)
by 0x41D0EB: rl_handler (shell.c:388)
by 0x53CDB6D: rl_callback_read_char (in /usr/lib64/libreadline.so.7.0)
by 0x41CA20: input_read (shell.c:661)
by 0x41D88A: watch_callback (io-glib.c:170)
by 0x4E85246: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x4E855E7: ??? (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x4E85901: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.5200.3)
by 0x41D77D: bt_shell_run (shell.c:609)
by 0x4055E4: main (main.c:2502)
Address 0x76afcb4 is 4 bytes inside a block of size 30 alloc'd
at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
by 0x517F803: ??? (in /usr/lib64/libdbus-1.so.3.19.0)
by 0x516D32A: dbus_message_copy (in /usr/lib64/libdbus-1.so.3.19.0)
by 0x4195F4: prop_entry_update.isra.1 (client.c:186)
by 0x4197C4: prop_entry_new (client.c:202)
by 0x4197C4: add_property (client.c:237)
by 0x4199A5: update_properties (client.c:277)
by 0x419E74: parse_properties (client.c:974)
by 0x419E74: parse_interfaces (client.c:1001)
by 0x41B412: parse_managed_objects (client.c:1093)
by 0x41B412: get_managed_objects_reply (client.c:1114)
by 0x51607A1: ??? (in /usr/lib64/libdbus-1.so.3.19.0)
by 0x516411E: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.19.0)
by 0x41261F: message_dispatch (mainloop.c:72)
by 0x4E81C26: ??? (in /usr/lib64/libglib-2.0.so.0.5200.3)
