When a obex transfer is interrupted by a peer in the middle, the response
G_OBEX_RSP_FORBIDDEN comes and the transfer is freed in transfer_complete.
However gobex is still ref'ed and gobex->io continues to be writable,
so write_data() and then g_obex_abort() are called. When the abort response
comes, struct obc_transfer is already freed, which leads to the crash.
Backtrace :
__GI___pthread_mutex_lock (mutex=0x65732f74) at pthread_mutex_lock.c:67
0xecc6eeda in dbus_connection_get_object_path_data () from libdbus-1.so.3
0x000457d4 in g_dbus_emit_property_changed_full () at gdbus/object.c:1794
0x00045868 in g_dbus_emit_property_changed () at gdbus/object.c:1832
0x000367f0 in transfer_set_status () at obexd/client/transfer.c:211
0x0003681e in transfer_set_status () at obexd/client/transfer.c:206
xfer_complete () at obexd/client/transfer.c:672
0x00022df6 in transfer_complete () at gobex/gobex-transfer.c:103
0x00022f44 in transfer_abort_response () at gobex/gobex-transfer.c:124
0x00020a0e in handle_response () at gobex/gobex.c:1128
0x00020dde in incoming_data () at gobex/gobex.c:1373
This commit introduces g_obex_drop_tx_queue(), which will be called if
a transfer error detected. After the tx queue is dropped, obex shuts
down gracefully.
It has been reported that under some unknown circuntances the reference
number of AVDTP sessions can go bellow 0 (loop around) causing a crash:
bluetoothd[5633]: profiles/audio/avdtp.c:avdtp_ref() 0x56a882b8a500: ref=-2101995743
bluetoothd[5633]: profiles/audio/a2dp.c:discover_cb() err (nil)
WARNING crash_reporter[10707]: [user] Received crash notification for bluetoothd[5633]
If CCC fails to be programmed the callback would be run without taking
a reference which may lead to freeing the client instance while there
are still notification to be processed.
To fix this handling of both success and failure to program the CCC will
now take a reference to the client, also in case of failure instead of
attempting to program the CCC once again the code now notify all the
queued requests which is consistent with how the success case is
handled.
If a new packet for outbound delivery is queued during the last
transmission of the only other packet being sent, the prior
packet got forgotten and leaked. This fix correctly deletes the prior
packet, but also makes sure it is given the proper oportunity for
transmission.
This adds a concept of "blacklisted" addresses. that a provisioner is
not allowed to assign to newly added mesh nodes.
An address may be "blacklisted" is a node has been removed from the network
(e.g., after node reset procedure). This ensures that the addresses are not
reused for provisioning new nodes to prevent a potential communication
problem due to saved RPL entries associated with these addresses in the
rest of the mesh network. The address is "cleared", when IV index updates
at least twice.
This adds keeping track of IV index changes.
The updates are detected by observing PropertiesChanged signal
on local node's object path and reading "IvIndex" property
This adds emitting of PropertiesChanged signal whenever the
mesh IV index is updated to indicate that the vlaues of "IvIndex"
property has been modified.
The timestamp_high value is assigned from the monotonic time but there
is a chance that the value becomes zero because it reads the value
between bit8 and bit13.
This patch makes sure the timestamp_high value get a non-zero value.
The SysEx end of message parser didn't consider the fact that
timestampsLow are in the stream and it might have the EOX (F7)
byte as well.
Fix that by always assuming the first system message byte is
the timestampLow.
Future work would involve support other type of system message
bytes, such as real-time.
This patch introduces a new command ‘add’ within "monitor" submenu to
allow users to add advertisement monitor filters and get back monitor
handlers. An event handler is also added to handle kernel issued
MGMT_EV_ADV_MONITOR_ADDED events. The command will work with the new
MGMT opcode MGMT_OP_ADD_ADV_MONITOR. This patch only adds support for
adding pattern based filters.
Tested on Atlas Chromebook with a sample stdout below:
[mgmt]# add -p 0:1:c504 1🅰️9a55beef
Advertisement monitor with handle:0x0005 added
[mgmt]# add -p 0:1:xxxx
Failed to parse monitor patterns.
Usage: add <-p|-h> [options...]
Monitor Types:
-p <ad_type:offset:pattern>... Pattern Monitor
e.g.:
add -p 0:1:c504 1🅰️9a55beef
This patch introduces a new btmgmt command ‘remove’ wihtin "monitor"
submenu to allow users to remove previously added filters along with a
event handler to handle kernel issued MGMT_EV_ADV_MONITOR_REMOVED
event. The command will work with the new
MGMT opcode MGMT_OP_REMOVE_ADV_MONITOR.
Tested on Atlas Chromebook with a sample stdout below:
[mgmt]# remove 1
Advertisement monitor with handle: 0x0001 removed
[mgmt]# remove 1234
Could not remove advertisement monitor with status 0x11 (Invalid Index)
This patch introduces a new submenu "monitor" along with command
‘features’ to help user query for supported advertisement features. The
command will work with the new MGMT opcode
MGMT_OP_READ_ADV_MONITOR_FEATURES.
Tested on Atlas Chromebook with a sample stdout below:
[mgmt]# features
Supported features:
None
Enabled features:
None
Max number of handles: 32
Max number of patterns: 16
Handles list with 2 items:
0x0001
0x0002
To import nodes, applications need just IvIndex and IvUpdate. KeyRefresh
phase in under provisioner's control, so we don't need to expose it.
Moreover, BeaconFlags property dealt just with the primary net key, and
each subnet key is refreshed separately.
We require the successful return of JoinComplete() method before
handling subsequent Attach() or Leave() method calls. To simplify the
construction of Applications, we will accept one of these calls up to 1
second prior to receiving the final return status of JoinComplete,
which tells us that the Application is ready to use the node.
If the node is still not ready after the deferral, Attach and/or Leave
will fail.
This adds the following command opcodes, event codes and the corresponding
structures.
- MGMT_OP_READ_ADV_MONITOR_FEATURES
- MGMT_OP_ADD_ADV_PATTERNS_MONITOR
- MGMT_OP_REMOVE_ADV_MONITOR
- MGMT_EV_ADV_MONITOR_ADDED
- MGMT_EV_ADV_MONITOR_REMOVED
When a discovery client has set a pattern as filter the code allocates
the string so it needs to be freed with the filter otherwise it leads to
the following leak:
10 bytes in 2 blocks are definitely lost in loss record 19 of 265
at 0x483980B: malloc (vg_replace_malloc.c:309)
by 0x4D9FF7E: strdup (in /usr/lib64/libc-2.30.so)
by 0x1FC8E7: parse_pattern (adapter.c:2454)
by 0x1FF37B: parse_discovery_filter_entry (adapter.c:2480)
by 0x1FF37B: parse_discovery_filter_dict (adapter.c:2538)
by 0x2020AF: set_discovery_filter (adapter.c:2589)
by 0x24AD63: process_message.isra.0 (object.c:259)
by 0x24B40F: generic_message (object.c:1079)
by 0x4A670B7: ??? (in /usr/lib64/libdbus-1.so.3.19.11)
by 0x4A57763: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.19.11)
by 0x2459CF: message_dispatch (mainloop.c:72)
by 0x4963E8A: ??? (in /usr/lib64/libglib-2.0.so.0.6200.6)
by 0x496756F: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6200.6)
If the intr channel was disconnected by the other party, then they
are also responsible to close the ctrl channel. Such disconnection
message would have the G_IO_ERR flag set, as opposed to it being
unset if the disconnection is initiated by us.
There doesn't seem to be an explicit rule in the specification
about this behavior, but this is enforced in the PTS qualification
tool.
According to bluetooth HID Profile spec Ver 1.0, section 7.2.2, A
host or device shall always complete the disconnection of the
interrupt channel before disconnecting the control channel.
However, the current implementation disconnects them both
simultaneously.
This patch postpone the disconnection of control channel to the
callback of interrupt watch, which shall be called upon receiving
interrupt channel disconnection response.
If the client disconnect/crash while MGMT_OP_STOP_DISCOVERY was pending
it would possibly cause a crash as the client pointer is passed to
mgmt_send and accessed in the callback after being freed.
To fix this the adapter itself is now passed to the callback so the
client is not accessed directly, instead the code now checks if
discovery_list has not been cleared in the meantime and only then
proceed to access the client pointer which is how
MGMT_OP_START_DISCOVERY is handled.
This describes the following commands and event.
- Read Advertisement Monitor Features command
- Add Advertisement Patterns Monitor command
- Remove Advertisement Monitor command
- Advertisement Monitor Added event
- Advertisement Monitor Removed event
Note that the content of a monitor can differ based on its type. For now we
introduce only pattern-based monitor, so you may find that unlike the
command of removing monitor(s), the Add command is tied to a specific type.
This introduces the following behavior change for those methods
on Network interface that specify node token as an input parameter
Leave() method:
If Leave method is called for a node that is being processed as a result
of a Create, Import, Join or Attach method calls in progress, node removal
is not allowed and org.bluez.mesh.Error.Busy error is returned.
Attach() method:
If Attach method is called for a node that is being processed as a result
of a Create, Import or Join method calls in progress, node attachment
is not allowed and org.bluez.mesh.Error.Busy error is returned.
This separates "Busy" and "InProgress" error codes:
MESH_ERROR_IN_PROGRESS maps to org.bluez.mesh.Error.InProgress
MESH_ERROR_BUSY maps to org.bluez.mesh.Error.Busy
Minor API change:
UpdateAppKey() returns "InProgress" error instead of "Busy"
