This adds a process callback and a data destroy callback to the session's
pending_request structure.
This is needed as preparation of queuing all OBEX session commands.
Parse the service attributes mas_instance_id and supported_message_types
from the transport's service attributes as soon as a connection is
established.
This automatically establishes the MNS connection when the MAS client
session is started and terminates the MNS connection when the MAS client
session is closed.
The MAP client controls the notification channel using the
SetNotificationRegistration function. The MSE will connect/disconnect
the MNS connection accordingly.
This implements the server role of the MAP Message Notification Service
(MNS) which is part of the MAP Client Equipment (MCE) device.
After successful registration, the MNS will receive event reports,
notifying about state changes on the server side.
Possible events are: NewMessages, DeliverySuccess, SendingSuccess,
DeliveryFailure, SendingFailure, MemoryFull, MemoryAvailable,
MessageDeleted, MessageShift
g_atomic_* end up using G_STATIC_ASSERT, causing gcc 4.8 to yell due to
-Wunused-local-typedefs.
/usr/include/glib-2.0/glib/gmacros.h:162:53: error: typedef ‘_GStaticAssertCompileTimeAssertion_2’ locally defined but not used [-Werror=unused-local-typedefs]
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
Most of the uses of atomic operations were wrong. They were fixed as
well. If we are using atomic operations, reading the variable again
later for logging is not an option, we should use the return of the
atomic function used to fetch the variable.
obc_session_setpath is able to handle multiple folder changes at once.
This removes the limit, that was introduced because of PBAP's limitation
to 3 levels (75d32c6b3a).
Other profiles like MAP might have deeper folder hierarchies.
The parameter Status indicates the status of reception of the message.
It can be used to differentiate between messages with a reception status
of "completed", "fractioned" and "notification".
This parameter got lost when obexd was refactored to use of D-Bus properties.
The documentation and the parsing code for it was still there.
Since 9606375649 xfer_complete() sets the
transfer status rather than the size. Adapt obc_transfer_free to check
for the completed status to avoid deletion of completed transfers.
Calls to ListMessages with filter 'Read' set to true should
request the MSE to send read messages only.
The old code requests the MSE to send unread messages only.
This behavior is not matching the other filters.
Calls to ListMessages with filter 'Read' or 'Priority' caused a segfault
in parse_filter_read / parse_filter_priority. The functions read
D-Bus boolean values (uint32) into uint8.
0 0x00007ffff730332d in ?? () from /usr/lib/libdbus-1.so.3
1 0x00007ffff7304219 in dbus_message_iter_next () from /usr/lib/libdbus-1.so.3
2 0x000000000043ef0f in parse_message_filters (
apparam=<error reading variable: Cannot access memory at address 0x7ffffeffff08>,
iter=<error reading variable: Cannot access memory at address 0x7ffffeffff00>)
at obexd/client/map.c:1246
The MAP specification defines ParameterMask as a bitmask of 32 bit / 4 bytes.
For the lower 16 bit the specification defines parameters, the higher 16 bit
remain reserved for future use. Therefore FILTER_ALL is set to 0x0000FFFF.
(Reserved bits have to be set to 0)
In addition this fixes the issue that ListFilterFields didn't show all fields.
Calls to ListMessages with filter 'Types' make obexd hang in an infinite loop.
This is caused by a missing dbus_message_iter_next in parse_filter_type.
0 0x00007ffff7304ca7 in dbus_message_iter_get_basic ()
from /usr/lib/libdbus-1.so.3
1 0x0000000000434fba in parse_filter_type (iter=0x7fffffffd7d0, apparam=
0x6987f0) at obexd/client/map.c:1086
2 parse_message_filters (iter=0x7fffffffd730, apparam=0x6987f0)
at obexd/client/map.c:1222
3 map_list_messages (connection=<optimized out>, message=0x669ae0, user_data=
0x698a60) at obexd/client/map.c:1273
4 0x00000000004109a1 in process_message (connection=0x662b20,
message=<optimized out>, iface_user_data=<optimized out>,
method=<optimized out>, method=<optimized out>) at gdbus/object.c:285
5 0x00007ffff7308e15 in ?? () from /usr/lib/libdbus-1.so.3
6 0x00007ffff72fb070 in dbus_connection_dispatch ()
from /usr/lib/libdbus-1.so.3
7 0x000000000040e3d8 in message_dispatch (data=0x662b20)
at gdbus/mainloop.c:76
8 0x00007ffff703d3cb in ?? () from /usr/lib/libglib-2.0.so.0
9 0x00007ffff703c845 in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
10 0x00007ffff703cb78 in ?? () from /usr/lib/libglib-2.0.so.0
11 0x00007ffff703cf72 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
12 0x000000000040df82 in main (argc=1, argv=0x7fffffffdd88)
at obexd/src/main.c:323
This fixes crashes in MAP client when the server does not send optional properties.
0 0x00007ffff6a792c5 in raise () from /usr/lib/libc.so.6
1 0x00007ffff6a7a748 in abort () from /usr/lib/libc.so.6
2 0x00007ffff731c145 in ?? () from /usr/lib/libdbus-1.so.3
3 0x00007ffff7312a25 in ?? () from /usr/lib/libdbus-1.so.3
4 0x00007ffff73050d6 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
5 0x0000000000433cc5 in get_replyto (property=<optimized out>, iter=<optimized out>,
data=<optimized out>) at obexd/client/map.c:484
6 0x00000000004103b6 in append_property (p=p@entry=0x6594c0 <map_msg_properties+192>,
dict=dict@entry=0x7fffffffd8e0, iface=0x6a3720) at gdbus/object.c:547
7 0x0000000000410472 in append_properties (data=data@entry=0x6a3720, iter=iter@entry=
0x7fffffffd960) at gdbus/object.c:576
8 0x00000000004104d1 in append_interface (data=0x6a3720, user_data=0x7fffffffda40)
at gdbus/object.c:591
9 0x00007ffff7058a4d in g_slist_foreach () from /usr/lib/libglib-2.0.so.0
10 0x0000000000411d05 in emit_interfaces_added (data=0x6a2ff0) at gdbus/object.c:623
11 process_changes (user_data=0x6a2ff0) at gdbus/object.c:1006
12 0x00007ffff703c845 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
13 0x00007ffff703cb78 in ?? () from /usr/lib/libglib-2.0.so.0
14 0x00007ffff703cf72 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
15 0x000000000040df82 in main (argc=1, argv=0x7fffffffdd88) at obexd/src/main.c:323
If the empty path is given, an empty name should be sent via OBEX.
Currently the name field is not set at all and later checks which
depend on data->index will access invalid memory regions as g_strsplit
returns NULL when an empty string is given.
0 0x000000000041a181 in g_obex_setpath (obex=obex@entry=0x662eb0, path=
0x20 <Address 0x20 out of bounds>, func=func@entry=0x42d300 <setpath_cb>,
user_data=user_data@entry=0x668f10, err=err@entry=0x7fffffffda08)
at gobex/gobex.c:1397
1 0x000000000042d395 in setpath_cb (obex=0x662eb0, err=0x0, rsp=<optimized out>,
user_data=0x668f10) at obexd/client/session.c:902
2 0x0000000000418e54 in handle_response (obex=obex@entry=0x662eb0, err=err@entry=0x0,
rsp=rsp@entry=0x668f40) at gobex/gobex.c:948
3 0x0000000000419d7a in incoming_data (io=<optimized out>, cond=<optimized out>,
user_data=0x662eb0) at gobex/gobex.c:1191
4 0x00007ffff703c845 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
5 0x00007ffff703cb78 in ?? () from /usr/lib/libglib-2.0.so.0
6 0x00007ffff703cf72 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
7 0x000000000040def2 in main (argc=1, argv=0x7fffffffdd88) at obexd/src/main.c:323
Crash occurs when removing a session with RemoveSession while another
session has been created but not yet registered.
Backtrace:
0 __strcmp_ssse3 () at ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:233
1 0xb758e7c3 in g_str_equal () from /lib/i386-linux-gnu/libglib-2.0.so.0
2 0x08073e56 in find_session (path=0x85c8504 "/org/bluez/obex/session0") at obexd/client/manager.c:146
3 remove_session (connection=0x85bc5e0, message=0x85bca98, user_data=0x0) at obexd/client/manager.c:216
4 0x08055f6f in process_message (connection=0x85bc5e0, message=<optimized out>, iface_user_data=0x0,
method=<optimized out>, method=<optimized out>) at gdbus/object.c:285
5 0xb7672666 in ?? () from /lib/i386-linux-gnu/libdbus-1.so.3
6 0xb76624d7 in dbus_connection_dispatch () from /lib/i386-linux-gnu/libdbus-1.so.3
7 0x080532f8 in message_dispatch (data=0x85bc5e0) at gdbus/mainloop.c:76
8 0xb759f6bf in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
9 0xb759e9e3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
10 0xb759ed80 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
11 0xb759f1db in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
12 0x08052d74 in main (argc=1, argv=0xbfb344e4) at obexd/src/main.c:323
Transfer need to be registered before it is authorized because
AuthorizePush takes the transfer path and the agent may try to access
the transfer properties to figure out its details.
Rename the interface and move it to obexd-api.txt since it now belongs
to the same daemon, in addition remove obex-client-api.txt and align with
Transfer1 API in use by the server.
In addition fix the reply generated by obc_transfer_create_dbus_reply to
not use a structure container instead use object, dict 'oa{sv}' as
indicated in the documentation.
This reverts commit 8a03376544.
The patch needs to be split up and the gdbus/ changes were bogus
compared to the original commit message.
Conflicts:
Makefile.am
Makefile.obexd
profiles/cyclingspeed/cyclingspeed.c
profiles/heartrate/heartrate.c
src/error.c
Instead of trying to include config.h in each file over the tree and
possibly forgetting to include it, give a "-include config.h" argument
to the compiler so it's guaranteed that a) it will be included for all
source files and b) it will be the first header included.
gdbus/ directory is left out, since it would break other projects using
it.
In case of message listing we need to send application
parameters in response and also it is required for sending
response to message listing size request.
For multiple subsequent request for message listing
we need to reset this variable to FALSE, so that each
time the get next header function is executed properly.
Once a message was already listed and inserted on the cache it could
not be listed again as the code was using the wrong key to lookup for
found messages then once we try to create the message again it fails
as the object already exists.
Invalid read of size 8
at 0x40EC04: g_obex_apparam_free (gobex-apparam.c:362)
by 0x41A66A: obc_transfer_free (transfer.c:272)
by 0x413221: pending_request_free (session.c:163)
by 0x413659: session_terminate_transfer (session.c:745)
by 0x41A53E: xfer_complete (transfer.c:518)
by 0x41B5D7: get_xfer_progress_first (transfer.c:562)
by 0x409750: handle_response (gobex.c:948)
by 0x40A609: incoming_data (gobex.c:1191)
by 0x371D047824: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x371D047B57: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x371D047F51: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x40542F: main (main.c:175)
Address 0x4f64510 is 0 bytes inside a block of size 8 free'd
at 0x4A079AE: free (vg_replace_malloc.c:427)
by 0x371D04D50E: g_free (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x416060: phonebook_size_callback (pbap.c:266)
by 0x413651: session_terminate_transfer (session.c:743)
by 0x41A53E: xfer_complete (transfer.c:518)
by 0x41B5D7: get_xfer_progress_first (transfer.c:562)
by 0x409750: handle_response (gobex.c:948)
by 0x40A609: incoming_data (gobex.c:1191)
by 0x371D047824: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x371D047B57: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x371D047F51: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x40542F: main (main.c:175)
Commit 15b15167fb2dd82e2189cc1955def1818a7bc6a6 broke the build:
plugins/messages.c:324:42: error: unknown type name ‘messages_update_inbox_cb’
plugins/messages.c:331:5: error: unknown type name ‘messages_set_read_cb’
plugins/messages.c:337:6: error: unknown type name ‘messages_set_delete_cb’
When the transfer file is opened in O_RDWR mode, just after the contents are
written to the file, the file offset has to be set to the beginning of the
file. If not subsequent read fails. This patch fixes this.
Attachment and charset are mandatory, so Message.Get now takes an
additional boolean parameter which the user application should set
if it wants the attachments to be downloaded, charset is always set
to UTF8.
This align the client timeout for GET operations with g_obex_get_req_pkt
which does use 60 seconds to cover for extra interaction during the first
packet.
gboolean is expected to hold 0/1. But it is holding int return from
strcasecmp which crashes DBusMessage at:
_dbus_return_val_if_fail (*bool_p == 0 || *bool_p == 1, FALSE);
Trace:
0 0x00007ffff7328d95 in __GI_raise (sig=6) at raise.c:64
1 0x00007ffff732a2ab in __GI_abort () at abort.c:93
2 0x00007ffff78d0655 in _dbus_abort () at dbus-sysdeps.c:94
3 0x00007ffff78c75f1 in _dbus_warn_check_failed at dbus-internals.c:289
4 0x00007ffff78ba28b in dbus_message_iter_append_basic at dbus-message.c:2538
5 0x00000000004201c3 in append_variant at client/dbus.c:44
6 0x000000000042024e in obex_dbus_dict_append at client/dbus.c:65
7 0x000000000041dcc9 in parse_read at client/map.c:423
8 0x000000000041dfa7 in msg_element at client/map.c:518
9 0x00007ffff7b323b9 in emit_start_element at gmarkup.c:986
10 0x00007ffff7b33b44 in g_markup_parse_context_parse at gmarkup.c:1323
11 0x000000000041e1ad in message_listing_cb at client/map.c:586
12 0x000000000041744c in session_terminate_transfer client/session.c:743
13 0x00000000004174d7 in session_notify_complete at client/session.c:758
14 0x000000000041755a in transfer_complete at client/session.c:778
15 0x000000000041f57b in xfer_complete at client/transfer.c:521
16 0x000000000040efdf in transfer_complete at gobex/gobex-transfer.c:102
17 0x000000000040f418 in transfer_response at gobex/gobex-transfer.c:221
18 0x000000000040b320 in handle_response at gobex/gobex.c:948
19 0x000000000040bbc1 in incoming_data at gobex/gobex.c:1191
20 0x00007ffff7b2f94a in g_main_dispatch (context=0x62f130) at gmain.c:2515
21 g_main_context_dispatch (context=0x62f130) at gmain.c:3052
22 0x00007ffff7b2fd10 in g_main_context_iterate at gmain.c:3123
23 g_main_context_iterate at gmain.c:3060
24 0x00007ffff7b3010a in g_main_loop_run (loop=0x62e1b0) at gmain.c:3317
25 0x000000000041527d in main at client/main.c:175
Change logic to check for O_WRONLY, as oflag is
created by an OR operation of O_WRONLY, O_CREAT and
O_TRUNC.
Message update is a PUT function, this check returns
bad response if GET is received.
2,210 (64 direct, 2,146 indirect) bytes in 2 blocks are definitely lost in loss record 150 of 155
at 0x4A0884D: malloc (vg_replace_malloc.c:263)
by 0x3B2900F8A1: sdp_create (sdp.c:3656)
by 0x3B2900FAE0: sdp_connect (sdp.c:4604)
by 0x415902: adapter_reply (bluetooth.c:421)
by 0x3B22C0C429: ??? (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x3B22C0F5E9: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x4059A7: message_dispatch (mainloop.c:76)
by 0x32CD64822A: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x32CD647694: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x32CD6479C7: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x32CD647DC1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x40567F: main (main.c:175)
At the moment IRMC fails to connect for phonebook_ebook and
phonebook_tracker usage because the name parameter for phonebook_pull
is not an absolute path.
This parses the response and return as a list of dictionary where each
entry is a folder and its properties, similar to what
FileTransfer.ListFolder does.
Always set error on failure in obc_transfer_put. This is expected by
callers and will avoid possible NULL pointer dereference.
Also fix improper use of errno variable (calling error may modify it)
and some dead assignments to perr.
Use g_malloc0 instead of g_try_malloc0 to allocate list. All users
expects to get valid pointer from it anyway. Also size of allocated
memory is small.
384 (184 direct, 200 indirect) bytes in 1 blocks are definitely lost in loss record 141 of 157
at 0x4A0884D: malloc (vg_replace_malloc.c:263)
by 0x392E217815: ??? (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x392E218632: dbus_message_new_method_call (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x413AD3: send_method_call (bluetooth.c:87)
by 0x414933: manager_reply (bluetooth.c:496)
by 0x392E20C429: ??? (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x392E20F5E9: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.5.6)
by 0x405767: message_dispatch (mainloop.c:76)
by 0x369E04827A: ??? (in /usr/lib64/libglib-2.0.so.0.3200.3)
by 0x369E0476E4: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.3)
by 0x369E047A17: ??? (in /usr/lib64/libglib-2.0.so.0.3200.3)
by 0x369E047E11: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.3)
Cancelling queued (not started yet) transfers should not fail. Instead,
they must be removed from the queue, so we just need to call the
transfer callback.
Passing an empty string as a filename for obc_transfer_get will be
similar to passing a NULL filename. This means a temporary file will be
created to store the content of the transfer.
NULL and "" are not exactly equivalent though: in case of NULL the file
will be automatically removed immediately after being open, which means
that the transfer initiator should also open the file to prevent it from
being removed (to be used from the modules). In this case, the filename
will not be exposed in D-Bus.
On the other hand, if "" is given, the file will be removed only in case
of error. So after success the transfer initiator should decide whether
the file should be removed or not.
This change is convenient in order to expose the same API in D-Bus.
There is no reason to have inconsistent behavior between GetFile and
PutFile, in FileTransfer D-Bus API.
Before this change, PutFile reported success immediately after queueing
the transfer, even though the D-Bus signature includes the async flag.
Relying on a internal policy (based on transfer type) to decide if a
transfer should be exposed or not in D-Bus has some limitations. The
simplest possible alternative to this is to expose all transfers in
D-Bus, assuming the overhead is not significant.
The authorization mechanism is entirely removed from the session, and
thus transfers are automatically started (once popped from the queue)
without confirmation and without any name/filename change.
The number of transferred bytes is exposed in D-Bus using a specific
property for this purpose.
Internally, the value of this property does not necessarily match the
internal progress counter. In order to avoid D-Bus overhead, the
property will be updated once per second.
