| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GUINT_TO_POINTER does not cast properly in older version of GLib (< 2.31)
causing the following errors:
cc1: warnings being treated as errors
gobex/gobex-apparam.c: In function ‘g_obex_apparam_set_bytes’:
gobex/gobex-apparam.c:176:38: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint8’:
gobex/gobex-apparam.c:243:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint16’:
gobex/gobex-apparam.c:261:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint32’:
gobex/gobex-apparam.c:282:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_uint64’:
gobex/gobex-apparam.c:303:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_string’:
gobex/gobex-apparam.c:324:43: error: cast to pointer from integer of
different size
gobex/gobex-apparam.c: In function ‘g_obex_apparam_get_bytes’:
gobex/gobex-apparam.c:342:43: error: cast to pointer from integer of
different size
make[1]: *** [gobex/gobex-apparam.o] Error 1
make: *** [all] Error 2
|
|
|
|
| |
This adds "apparam" to the debug options of GOBEX_DEBUG
|
|
|
|
|
|
| |
This introduce 2 new convenient functions: g_obex_header_get_apparam
which parses and decode an header into GObexApparam and
gobex_header_new_apparam that encode GObexApparam into GObexHeader.
|
|
|
|
|
|
|
| |
GObexApparam abstract the handling of application parameter tags, it
can be used to read/parse application parameter header data using
g_obex_apparam_get_* functions or to generate the data using
g_obex_apparam_set_*.
|
|
|
|
|
| |
g_debug doesn't print anything if domain is not present in
G_MESSAGES_DEBUG.
|
| |
|
|
|
|
| |
Values stored are never read.
|
|
|
|
|
|
| |
If callback is provided in g_obex_cancel_transfer() current complete
callback will be replaced by the new one and user will be informed
when abort completes.
|
| |
|
|
|
|
|
| |
This code path could lead to situations where the callback is later
used, making the daemon crash.
|
|
|
|
|
|
|
| |
ENOSYS correspond to function not implemented which is exactly what the
OBEX error code means.
Also since EINVAL means invalid argument that now map to OBEX bad request
|
|
|
|
|
|
| |
This patch create a map between posix errors code and OBEX response
opcode and use it to generate a proper response in case a transfer
failed instead of always responding with internal error.
|
|
|
|
|
| |
G_OBEX_OP_ABORT is defined as 0x7f but error checking of opcode is
done for greater than 0x1f. So abort request is simply ignored.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GOEP 2.0 test specification forbids the server to include SRM headers in
CONNECT response:
"3.16 TP/SRM/BI-03-C Process an OBEX CONNECT request (incorrectly)
containing a SRM header:
• Expected Outcome
Pass Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT responds with a SUCCESS without a SRM header.
– OBEX/L2CAP channel is established.
Fail Verdict:
– On receiving the invalid SRM header in the OBEX_CONNECT request, the
IUT does not respond with a SUCCESS and/or includes a SRM header in the
response.
– OBEX/L2CAP channel is not established or OBEX/RFCOMM channel is
established."
|
|
|
|
| |
While sending the final bit can be changed during encoding.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies the applications so SRM setup phase became transparent
while using SOCK_SEQPACKET which is useful for GOEP 2.0 since in that
case we can only use SRM if the transport is L2CAP.
This also follows GOEP 2.0 Page 14 - 4.6 Using Single Response Mode:
"The Server cannot issue an enable request, but can only issue a
response to an enable request from the Client. SRM will remain in
effect for the duration of the operation that enabled it (PUT or GET)
...
SRM headers shall not be sent in CONNECT request or response packets."
and Page 22 - 5.4 Establishment of OBEX Connection:
"SRM headers shall not be sent in the Connect request or response
packets (note, this is to preserve backwards compatibility). SRM shall
be enabled through Put and Get operations only."
So only in case of PUT or GET requests SRM is automatically configured,
applications can still enable it manually for other operations by adding
the headers like before but it is not recommended.
Note that it would be a good practice to indicate SRM support by using
value 0x02, but since that should happens during CONNECT command it is
not done automatically for requests when acting as a client, server
responding to indicate requests will automatically add SRM headers though.
|
|
|
|
|
| |
Single Response Mode Parameters is a 1-byte quantity containing the
value for the parameters used for SRM.
|
|
|
|
|
| |
Single Response Mode (SRM) is a 1-byte quantity containing a value to
enable or disable SRM, as well as to indicate support for SRM.
|
|
|
|
|
| |
g_obex_get_rsp_pkt takes a response packet which sometimes is more
convenient for adding headers.
|
|
|
|
|
| |
g_obex_put_req is quite similar to g_obex_put_req_pkt so now it just
call it to avoid duplicating this code.
|
|
|
|
|
| |
Also rename G_OBEX_HDR_SRM_PARAMETERS to just G_OBEX_HDR_SRMP as the spec
normally refer to it.
|
| |
|
|
|
|
|
|
|
|
|
| |
The previous approach searched the transfer pointer itself, assuming
that the transfers has not been modified if the pointer is in the list.
However the callback could have removed the transfer and registered
another one, which can eventually point to the same memory location.
This is solved by looking for the transfer id instead of the pointer.
|
| |
|
|
|
|
| |
If statement checks for get_id handle but was removing req_id.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OBEX spec says:
Only the first packet in the request needs to contain the Connection
Id header...
If a Connection Id header is received with an invalid connection
identifier, it is recommended that the operation be rejected with the
response code (0xD3) “Service Unavailable”.
Since not all requests packets need to contain Connection Id header we
should only try to validate it in case a header is received.
Reported by Hendrik Sattler <post@hendrik-sattler.de>
|
|
|
|
|
| |
According to both OBEX and GOEP specs Connection ID should only be
included in the first packet of a request.
|
|
|
|
|
| |
obex->rx_last_op is only updated if there is no pending request which
means it only store last received request.
|
|
|
|
|
|
|
| |
OBEX spec state that it is optional to send a Connection Id header in an
OBEX ABORT operation.
Reported by Hendrik Sattler <post@hendrik-sattler.de>
|
|
|
|
|
|
| |
Since gobex maintain the connection id of the session it is more
convenient to check whether the incoming request connection matches
before calling the application handlers.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This adds support for debug using GOBEX_DEBUG environment variable.
|
| |
|
| |
|
|
|
|
| |
Length values of less than 3 are invalid.
|
|
|
|
| |
This was exactly the same as g_obex_packet_get_header.
|
|
|
|
|
|
|
| |
Frequently upon receiving the first packet servers will perform some
sort of user interaction to authorize the incoming request. It's
therefore wise to use a larger timeout for this first packet on the
client side.
|
| |
|
|
|
|
|
|
|
| |
A user callback could potentially do things like g_obex_cancel_request
or g_obex_unref while we are inside the IO watch callback. It is
therefore important to ensure that we are in a consistent state when the
user callback returns.
|
| |
|
| |
|
| |
|