| 0491cdf3 |
Fix memory leak when adding GATT Characteristic
Commit 4465c577778d812702d752dfd2812e25a2f69b31 has fixed a segfault
which may occur during new GATT Characteristic insertion. However, the
cleanup exercise isn't done before returning.
Bluetoothd address sanitizer backtrace:
=================================================================
==88967==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 768 byte(s) in 6 object(s) allocated from:
#0 0x768d1f8b3ec7 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x59f0cac1ea07 in util_malloc src/shared/util.c:46
Indirect leak of 576 byte(s) in 18 object(s) allocated from:
#0 0x768d1f8b3ec7 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x59f0cac1ea07 in util_malloc src/shared/util.c:46
Indirect leak of 114 byte(s) in 6 object(s) allocated from:
#0 0x768d1f8b4097 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x59f0cac75d6c in new_attribute src/shared/gatt-db.c:222
SUMMARY: AddressSanitizer: 1458 byte(s) leaked in 30 allocation(s).
Additionally added an explicit check that current Characteristic handle
is not greater or equal to its value handle. If value handle is equal to
Characteristic handle, then second "new_attribute" allocation will
overwrite the pointer in service->attributes, which will also cause a
leak. |
Stanislavs Nilovs |
5 months ago |
1 file, +6, -2 |
| 8a304f7f |
shared/bap: reset local ep state on stream detach
When removing streams in bt_bap_detach(), they are detached directly
without going through normal state transitions. As BAP Unicast Server,
this leaves local endpoints to the state they were in, so they persist
if client connects again. This is not wanted.
For server streams, clear the local ASE state on detach. At that point,
the ASE is either already idle or the session is detached.
Don't modify state of remote endpoints (BAP Client streams), as only
remote server should do that. |
Pauli Virtanen |
5 months ago |
1 file, +6, -0 |
| 013b3431 |
Fix buffer overflow in sdp_xml_parse_uuid128
This was found by OSS-Fuzz.
This can be reproduced by running this input:
`<uuid value="111111111111111111111111111111111111">`
against the harness in
https://github.com/google/oss-fuzz/blob/master/projects/bluez/fuzz_xml.c
which just calls `sdp_xml_parse_record`.
`sdp_xml_parse_uuid` checks that the length of the string is 36 (32
digits + 4 '-' characters) prior to calling `sdp_xml_parse_uuid128`.
There's no check preventing this data from being 36 digits (with no
"-"), which leads to a buffer overflow in sdp_xml_parse_uuid128.
https://issues.oss-fuzz.com/issues/42534847
https://oss-fuzz.com/testcase-detail/5070205940531200 |
Oliver Chang |
5 months ago |
1 file, +6, -0 |
| bf5ec167 |
bap: remove bap_update_cigs callback properly whan data is freed
setup_free() may re-enable the CIG update callback. If this occurs in
bap_data_free(), the callback crashes with UAF.
Fix by moving clearing the callback after all setups are freed. |
Pauli Virtanen |
5 months ago |
1 file, +4, -3 |
| 5ccbff08 |
shared/bap: check ASE state in find_ep_ucast
ASE may be in non-configurable state also if it has no associated
stream, eg. as a result of failed stream teardown or other misbehavior.
Check also ASE state when selecting a "free" one.
Fixes wrongly picking ASE that is not IDLE/CONFIG/QOS and cannot be
configured. |
Pauli Virtanen |
5 months ago |
1 file, +9, -0 |
| aba67693 |
bap: clear server streams when ucast disconnects
Streams are freed by bap_detach() without state change callback. Clear
data->server_streams explicitly before bap_detach().
Fixes UAF due to stale stream pointers in server_streams. |
Pauli Virtanen |
5 months ago |
1 file, +3, -0 |
| 84c336f2 |
media: clear transport if reconfiguring in pac_config()
We are not updating transport->configuration if transport already exists
in pac_config(), so reconfiguration of a stream leaves sound server with
old configuration.
Do this in the same way we do for A2DP: first ClearConfiguration() to
remove old transport, then SetConfiguration() to make new one with the
new settings. |
Pauli Virtanen |
5 months ago |
1 file, +17, -14 |
| caa49533 |
media: fix pac_select(), pac_config() return values
These return 0 on success, < 0 on error, not TRUE/FALSE. |
Pauli Virtanen |
5 months ago |
1 file, +11, -5 |
| bb012215 |
shared/bap: use correct parser for Config Codec message
ASCS Config Codec gets Codec_Specific_Configuration, not
Codec_Specific_Capabilities so use the correct parser.
Fixes spurious 'invalid size' printed in debug logs. |
Pauli Virtanen |
5 months ago |
1 file, +1, -1 |
| a9831491 |
bap: send correct framing value to kernel
Get framing value to use from the QoS of the appropriate stream, instead
of hardcoding unframed. |
Pauli Virtanen |
5 months ago |
1 file, +2, -0 |
| 5ab82029 |
bap: fix multiple release of stream when closing setup
If setup->closing, then the stream was already released and should not
be released again. Also, if stream is RELEASING on setup_close(),
freeing the setup should be delayed until the stream exits that state.
Fixes issue where setup is closed, stream goes RELEASING->CONFIG, the
setup is freed and a duplicate release op is queued. Before that
completes, the stream is reused for a new setup. In this case, the new
setup is incorrectly destroyed when the release op completes although it
was intended to destroy the old setup. |
Pauli Virtanen |
5 months ago |
1 file, +8, -3 |
| 0cac149a |
mesh: Fix 'buf’ may be used uninitialized warning
../dist-unpack/bluez-5.83/tools/mesh/agent.c: In function ‘response_decimal’:
../dist-unpack/bluez-5.83/tools/mesh/agent.c:94:9: warning: ‘buf’ may be used uninitialized [-Wmaybe-uninitialized]
94 | bt_put_be32(atoi(input), buf);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../dist-unpack/bluez-5.83/tools/mesh/agent.c:20:
../dist-unpack/bluez-5.83/lib/bluetooth/bluetooth.h:342:20: note: by argument 2 of type ‘const void *’ to ‘bt_put_be32’ declared here
342 | static inline void bt_put_be32(uint32_t val, const void *ptr)
| ^~~~~~~~~~~
../dist-unpack/bluez-5.83/tools/mesh/agent.c:88:17: note: ‘buf’ declared here
88 | uint8_t buf[DECIMAL_OOB_LEN];
| ^~~ |
Bastien Nocera |
5 months ago |
1 file, +1, -1 |
| eb40539c |
client: Fix missing strdup/memset declarations
bluez/client/display.c: In function ‘rl_prompt_input’:
bluez/client/display.c:112:24: error: implicit declaration of function ‘strdup’ [-Wimplicit-function-declaration]
112 | saved_prompt = strdup(rl_prompt);
| ^~~~~~
bluez/client/display.c:112:24: warning: incompatible implicit declaration of built-in function ‘strdup’ [-Wbuiltin-declaration-mismatch]
bluez/client/display.c:119:9: error: implicit declaration of function ‘memset’ [-Wimplicit-function-declaration]
119 | memset(prompt, 0, sizeof(prompt));
| ^~~~~~
bluez/client/display.c:24:1: note: include ‘<string.h>’ or provide a declaration of ‘memset’
23 | #include "display.h"
+++ |+#include <string.h>
24 |
bluez/client/display.c:119:9: warning: incompatible implicit declaration of built-in function ‘memset’ [-Wbuiltin-declaration-mismatch]
119 | memset(prompt, 0, sizeof(prompt));
| ^~~~~~
bluez/client/display.c:119:9: note: include ‘<string.h>’ or provide a declaration of ‘memset’ |
Bastien Nocera |
5 months ago |
1 file, +1, -0 |
| ae29fcb2 |
build: Move library source to lib/bluetooth
This fixes the installed directory hierarchy not matching the source
directory hierarchy. |
Bastien Nocera |
5 months ago |
257 files, +20752, -20762 |
| 10977abd |
iso-tester: Add ISO Reconnect Send and Receive #16
This adds ISO Reconnect Send and Receive #16 which test reconnecting,
send/receive datas, 16 times to stress test the handling of reconnecting
logic and confirm tha POLLOUT is generated everytime:
ISO Reconnect Send and Receive #16 - Success - run
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #16...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #15...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #14...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #13...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #12...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #11...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #10...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #9...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #8...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #7...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #6...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #5...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #4...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #3...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #2...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
Reconnecting #1...
Connecting to 00:AA:01:01:00:00...
Connect 0 in progress
Accept client connection with handle 0x0101: 0x00
New client connection with handle 0x0101
Successfully connected
POLLOUT event received
Writing 40 bytes of data
Receive 40 bytes of data
Client received 40 bytes of data
Disconnecting...
ISO handle 0x0101 disconnected
Successfully disconnected
ISO Reconnect Send and Receive #16 - Success - test passed |
Luiz Augusto von Dentz |
5 months ago |
1 file, +104, -67 |
| af816afa |
shared/asha: Do not start ASHA in case of CoC connection failure |
Arkadiusz Bokowy |
5 months ago |
1 file, +8, -3 |
| 2c0c323d |
profiles/battery: handle reversed ordering of CCC and value
Order of batt_io_value_cb() and batt_io_ccc_written_cb() may be reverse.
This causes device to appear with 0% or missing battery percentage,
because batt->percentage is set on the ignored update so the initial
update is lost.
Fix by saving new initial value, if battery is not registered. Also
downgrade warning to debug message.
Also check data length before parsing it.
Log (Sony Linkbuds S):
src/shared/att.c:can_read_data() (chan 0x7c31eea05c50) ATT PDU received: 0x1b
profiles/battery/battery.c:parse_battery_level() Battery Level updated: 87%
profiles/battery/battery.c:parse_battery_level() Trying to update an unregistered battery
src/battery.c:btd_battery_register() path = /org/bluez/hci1/dev_CF_D2_4D_EE_A2_1A
src/battery.c:btd_battery_register() registered Battery object: /org/bluez/hci1/dev_CF_D2_4D_EE_A2_1A
profiles/battery/battery.c:batt_io_ccc_written_cb() Battery Level: notification enabled |
Pauli Virtanen |
5 months ago |
1 file, +12, -7 |
| f086b3d2 |
btdev: Fix sending BT_HCI_EVT_LE_BIG_SYNC_LOST with wrong BIG handle
BT_HCI_EVT_LE_BIG_SYNC_LOST must be sent with the BIG handle used by the
remote peer which may be different than the one use with
BT_HCI_CMD_LE_TERM_BIG. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +18, -6 |
| 077de3f8 |
bap: Fix possible crash with Broadcast Sink
If the remote terminates the BIG Sync the following crash is observed:
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x8
at 0x40781C6: setup_free (bap.c:1024)
by 0x4078EB8: bap_state_bcast_sink (bap.c:3118)
by 0x41319DF: bap_bcast_set_state (bap.c:2392)
by 0x412CFFC: stream_set_state (bap.c:1537)
by 0x4131CBA: stream_io_disconnected (bap.c:6597)
by 0x414A079: watch_callback (io-glib.c:173)
by 0x4149EE9: io_err_watch_dispatch (io-glib.c:380)
by 0x4C9587F: ??? (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x4C9E7C7: ??? (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x4C9EA6E: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x414ABED: mainloop_run (mainloop-glib.c:65)
by 0x414B1C4: mainloop_run_with_signal (mainloop-notify.c:196) |
Luiz Augusto von Dentz |
5 months ago |
1 file, +2, -1 |
| 13e0776c |
iso-tester: Add Reconnect test for Broadcaster
This adds the following test:
ISO Broadcaster Reconnect |
Luiz Augusto von Dentz |
5 months ago |
1 file, +20, -0 |
| 165e57e7 |
bap: Fix crash when Broadcast endpoint exit
The following crash can be observed when a Broadcast endpoint exit
when a bap_setup exists:
Invalid read of size 8
at 0x4075B30: set_configuration_ready (bap.c:1120)
by 0x40766C3: setup_ready (bap.c:748)
by 0x407809C: setup_free (bap.c:998)
by 0x4078301: bap_state_bcast_src (bap.c:3012)
by 0x41319DF: bap_bcast_set_state (bap.c:2392)
by 0x412CFFC: stream_set_state (bap.c:1537)
by 0x4131AA3: bap_bcast_set_state (bap.c:2404)
by 0x412CFFC: stream_set_state (bap.c:1537)
by 0x412D0E6: bap_bcast_release (bap.c:2543)
by 0x41314EF: bt_bap_stream_release (bap.c:6518)
by 0x4131607: remove_lpac_streams (bap.c:4348)
by 0x4108444: queue_foreach (queue.c:207)
Address 0x56f7758 is 8 bytes inside a block of size 16 free'd
at 0x4B85E43: free (vg_replace_malloc.c:989)
by 0x407472D: setup_config (bap.c:1778)
by 0x407A869: set_configuration (bap.c:1175)
by 0x4102A8F: process_message (object.c:293) |
Luiz Augusto von Dentz |
5 months ago |
1 file, +4, -0 |
| 280c9523 |
btdev: Fix checking for PA on BT_HCI_CMD_LE_TERM_BIG
BT_HCI_CMD_LE_TERM_BIG does not require PA to be enabled. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +0, -8 |
| 0084cfe5 |
iso-tester: add tests for hardware RX timestamps
Add tests for HW RX timestamping. Also add test that sends large
packets to test ISO fragmentation.
Add tests:
ISO Receive - HW Timestamping
ISO Receive Fragmented - Success
ISO Receive Fragmented - HW Timestamping |
Pauli Virtanen |
5 months ago |
2 files, +82, -12 |
| fd80f235 |
bthost: fragment when sending ISO packets
Support fragmentation to controller MTU when sending ISO packets.
By default, fragment when exceeding btdev iso_mtu. |
Pauli Virtanen |
5 months ago |
3 files, +70, -30 |
| 00ffc553 |
btio: Fix handling of getpeername
getpeername can either return an error set in the errno or the
returned size can be invalid but in that case errno is not set so
printing it would generate bogus message. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +6, -2 |
| d427a2a5 |
btdev: Fix handling of BT_HCI_CMD_LE_TERM_BIG
BT_HCI_CMD_LE_TERM_BIG shall cleanup the BIS connections and if there
are remote connected then they shall be notified with
BT_HCI_EVT_LE_BIG_SYNC_LOST so they can proceed to cleanup as well. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +66, -1 |
| 6939c470 |
btdev: Add le_big on BT_HCI_CMD_LE_CREATE_BIG
When handling BT_HCI_CMD_LE_CREATE_BIG create a struct le_big to
represent it otherwise the likes of BT_HCI_CMD_LE_TERM_BIG will not be
able to detect a BIG was created. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +57, -20 |
| da772d62 |
client/mgmt: Print UUID and flags when showing experimental features
Command expinfo in mgmt menu queries experimental features from kernel
with MGMT_OP_READ_EXP_FEATURES_INFO. However, currently only the number
of experimental features are shown,
> expinfo
Global
Number of experimental features: 1
Primary controller (hci0)
Number of experimental features: 4
and lacking of details makes the command less useful. To ease debug,
this patch introduces extra output for the expinfo command, showing UUID
and flags of experimental features as well. A typical output will look
like,
> expinfo
Global
Number of experimental features: 1
6fbaf188-05e0-496a-9885-d6ddfdb4e03e (flags 0x0000)
Primary controller (hci0)
Number of experimental features: 4
671b10b5-42c0-4696-9227-eb28d1b049d6 (flags 0x0000)
330859bc-7506-492d-9370-9a6f0614037f (flags 0x0000)
6fbaf188-05e0-496a-9885-d6ddfdb4e03e (flags 0x0000)
2ce463d7-7a03-4d8d-bf05-5f24e8f36e76 (flags 0x0000) |
Yao Zi |
5 months ago |
1 file, +12, -1 |
| cd13141c |
monitor/intel: Add decoding of cnvi core
Add decoding of cnvi core from Intel read version event.
bluetooctl> hci.cmd 0xfc05 0xff
HCI traces:
< HCI Command: Intel Read Version (0x3f|0x0005) plen 1
Requested Type:
All Supported Types(0xff)
> HCI Event: Command Complete (0x0e) plen 122
Intel Read Version (0x3f|0x0005) ncmd 1
Status: Success (0x00)
CNVi TOP(16): 0x01080901
CNVr TOP(17): 0x00002a10
CNVi BT(18): 0x001c3700 - Gale Peak2(0x1c)
CNVr BT(19): 0x00313000
CNVr OTP(21): 0x0344
.....
..... |
Kiran K |
5 months ago |
1 file, +45, -1 |
| 3c0693c5 |
client: Add transport.metadata command
This adds transport.metadata command which can be used to update the
MediaTransport.Metadata property:
> transport.metadata <transport> "0x03 0x02 0x02 0x00"
[CHG] Transport <transport> Metadata:
03 02 02 00
> transport.show <transport>
...
Metadata.#0: len 0x03 type 0x02
Metadata.Context: 0x0002
Metadata.Context Conversational (0x0002) |
Luiz Augusto von Dentz |
5 months ago |
1 file, +48, -0 |
| 75628226 |
transport: Fix not updating MediaTransport.Metadata
MediaTransport.Metadata needs to be checked for updates when state
changes to Enabling or Streaming otherwise it remains blank. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +27, -0 |
| 4549772b |
transport: Add write support to Metadata property
This adds initial support from writing to Metadata property. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +44, -1 |
| 06d73a43 |
client: Fix gatt.{read, write} not working on scripts
If gatt.{read, write} are called within a script they don't indicate
completion so they block commands to be run after them. |
Luiz Augusto von Dentz |
5 months ago |
1 file, +4, -0 |
| 52de8da1 |
doc: Add initial ISO(7) documentation
This adds initial documentation for ISO sockets. |
Luiz Augusto von Dentz |
5 months ago |
2 files, +441, -3 |
| 4c431e5d |
client: Rework handling of Disconnected signal
Print with color the signal to indicate there is a change, also rework
the order of the parameters and use bearer specific suffix if the signal
comes from org.bluez.Bearer.*. |
Luiz Augusto von Dentz |
6 months ago |
1 file, +17, -7 |
| f4f8fe3e |
client: Add support for org.bluez.Bearer.{BREDR, LE}1
This adds support for printing properties related to
org.bluez.Bearer.{BREDR, LE}1:
> info XX:XX:XX:XX:XX:XX
...
BREDR.Paired: yes
BREDR.Bonded: yes
BREDR.Connected: no
LE.Paired: yes
LE.Bonded: yes
LE.Connected: no
...
[CHG] BREDR XX:XX:XX:XX:XX:XX Connected: yes |
Luiz Augusto von Dentz |
6 months ago |
1 file, +122, -2 |
| fdfaeddc |
bearer: Add initial implementation of org.bluez.Bearer.{BREDR, LE}
This adds initial implementation of org.bluez.Bearer{BREDR, LE}(5)
interfaces. |
Luiz Augusto von Dentz |
6 months ago |
4 files, +339, -12 |
| 8c8b5ed2 |
doc: Add org.bluez.Bearer.LE and org.bluez.Bearer.BREDR
This adds bearer specific interfaces so they can properly be operated
separately.
Fixes: https://github.com/bluez/bluez/issues/1350 |
Luiz Augusto von Dentz |
6 months ago |
3 files, +289, -0 |
| f406028b |
device: Add btd_device_bdaddr_type_connected
This adds btd_device_bdaddr_type_connected which can return the
connected state based on the address type. |
Luiz Augusto von Dentz |
6 months ago |
2 files, +9, -0 |
| 6c3cc38d |
doc: explain SCO BT_SK_PKT_STATUS socket option |
Pauli Virtanen |
6 months ago |
1 file, +32, -0 |
| 8c9977b0 |
adapter: Fix RemoveDevice timeout when device already disconnected
When attempting to use RemoveDevice to delete a BIS source device that
was synchronized by the BIS sink scan delegator, the kernel marks the
device as disconnected due to PA(period adv) sync termination. However, BlueZ is not
notified of this disconnection and still proceeds to send MGMT Disconnect
command. The kernel responds with MGMT_STATUS_DISCONNECTED, which BlueZ
does not currently handle as a successful case. As a result, the RemoveDevice
call never completes and no D-Bus reply is returned.
Fixes: https://github.com/bluez/bluez/issues/1421 |
Ye He |
6 months ago |
1 file, +2, -1 |
| 2b0a6fa0 |
mesh: fix corrupted relay packets
Currently, all relayed packets are broken!
At the point when net_key_encrypt() is called from net_rx() for
encrypting a relay packet, the packet size must include the NetMIC
field. But the length of this field has already been removed during
decryption of the incoming packet (by decrypt_net_pkt()), although
mesh_crypto_packet_decrypt() has correctly reset the NetMIC field to
zeroes.
Move stripping of the NetMIC field length from decrypt_net_pkt() to
mesh_crypto_packet_parse(), so that the field length is only stripped
from the payload message (but keeping the field length for the network
PDU). Additionally add extra length checks during parsing. |
Christian Eggers |
6 months ago |
2 files, +22, -4 |
| 159101c7 |
mesh: crypto: simplify mesh_crypto_packet_parse()
- NULL pointer checks are not required (no caller passes NULL pointers)
- reuse result of mesh_crypto_network_header_parse() rather than
determining value of 'CTL' again. |
Christian Eggers |
6 months ago |
1 file, +9, -21 |
| 9a32ff5a |
mesh: crypto: mesh_crypto_aes_ccm_encrypt(): remove unused parameter
The 'out_mic' pointer isn't written by this function and all callers
pass a NULL pointer for this. It's obviously not required (and would not
work), so lets remove it. |
Christian Eggers |
6 months ago |
5 files, +8, -11 |
| cb4b20c7 |
mesh: net: update comment
term 'master credentials' has been replaced by 'flooding credentials' in
commit 09f87c80f1d5 ("mesh: Inclusive language changes") |
Christian Eggers |
6 months ago |
1 file, +1, -1 |
| 0e586df2 |
mesh: net: remove unused stuff
'struct mesh_key_set' and 'struct net_decode' arent't used anymore since
commit 994932b740c7 ("mesh: Refactor friend.c and net.c for central key
DB").
'mesh_status_func_t' isn't used anymore since commit c4bf0626fb62
("mesh: Replace storage_save_config with mesh_config_save_config"). |
Christian Eggers |
6 months ago |
2 files, +0, -20 |
| b692d72b |
mesh: net: constify tx path
Although the first byte of network packets has the same value for all 4
'send' functions, it feels much more natural to assign this byte at the
location(s) where the packet is assembled, rather than where it is sent.
This improves the readability because send_msg_pkt() isn't called with a
partially uninitialized buffer anymore. |
Christian Eggers |
6 months ago |
1 file, +5, -2 |
| cd651d8e |
mesh: replace MESH internal defines by shared ones
Replace BT_AD_MESH_* by MESH_AD_TYPE_*.
Both sets of definition have been added almost at the time, so maybe
it was a 'race condition'. |
Christian Eggers |
6 months ago |
11 files, +43, -40 |
| 646cbe92 |
mesh: introduce MESH_AD_MAX_LEN and MESH_NET_MAX_PDU_LEN
Use symbolic names rather than magic numbers. Remove unneeded extra
pointer in send_seg(). |
Christian Eggers |
6 months ago |
6 files, +29, -13 |
| 009cfb51 |
mesh: net-keys: more uses of BEACON_LEN_SNB and BEACON_LEN_MPB |
Christian Eggers |
6 months ago |
1 file, +2, -2 |