- 15 7月, 2012 1 次提交
-
-
由 Mat Martineau 提交于
This change addresses an L2CAP ERTM throughput problem when a remote device does not fully utilize the available transmit window. The L2CAP ERTM transmit window size determines the maximum number of unacked frames that may be outstanding at any time. It is configured separately for each direction of an ERTM connection. Each side sends a configuration request with a tx_win field indicating how many unacked frames it is capable of receiving before sending an ack. The configuration response's tx_win field shows how many frames the transmitter will actually send before waiting for an ack. It's important to trace both the actual transmit window (to check for validity of incoming frames) and the number of frames that the transmitter will send before waiting (to send acks at the appropriate time). Now there are separate tx_win and ack_win values. ack_win is updated based on configuration responses, and is used to determine when acks are sent. Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 11 7月, 2012 3 次提交
-
-
由 Andrei Emeltchenko 提交于
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Correct places where CID and PSM were printed as int. For CID: 0x%4.4x is used and for PSM: 0x%2.2x. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Avoid unneeded type conversion by correcting type specifiers in debug statements for L2CAP. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 12 6月, 2012 1 次提交
-
-
由 Szymon Janc 提交于
If remote device sends bogus RFC option with invalid length, undefined options values are used. Fix this by using defaults when remote misbehaves. This also fixes the following warning reported by gcc 4.7.0: net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp': net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized] net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 08 6月, 2012 1 次提交
-
-
由 Johan Hedberg 提交于
The l2cap_conn_del function tries to cancel_sync the security timer, but when it's called from the timeout function itself a deadlock occurs. Subsequently the "hcon->l2cap_data = NULL" that's supposed to protect multiple calls to l2cap_conn_del never gets cleared and when the connection finally drops we double free's etc which will crash the kernel. This patch fixes the issue by using the HCI_CONN_LE_SMP_PEND for protecting against this. The same flag is also used for the same purpose in other places in the SMP code. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 05 6月, 2012 34 次提交
-
-
由 Andre Guedes 提交于
This patch changes the default MTU value for L2CAP ATT fixed channel to L2CAP_DEFAULT_MTU (672 octets). Differently from others L2CAP channels, in L2CAP ATT fixed channel there is no MTU negotiation. The MTU value for that channel is up to the L2CAP implementation. The only restriction in L2CAP spec is the MTU value must not be less than 23 octets. At ATT protocol level (on top of L2CAP), we have the ATT_MTU which defines the maximum size of any ATT message sent between client and server. GATT profile defines ATT_MTU default value to 23 octets. If a GATT based profile wants to use ATT_MTU greater than 23 octets (e.g. HID over GATT profile), it should negotiate a new value by executing the GATT Exchange MTU sub-procedure. Thus, in order to support any value of ATT_MTU negotiated at ATT protocol level, our L2CAP implementation should have L2CAP ATT fixed channel MTU equal or greater than ATT_MAX_MTU (512 octets). Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Gustavo Padovan 提交于
Trivial fix, let the code cleaner. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Gustavo Padovan 提交于
Simplify the handling of different ERTM header size. We were the same check in some places of the code, and more is expected to come, so just replace them with a function. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Andrei Emeltchenko 提交于
l2cap_att_channel always returns 0 which is not used. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
l2cap_conless_channel always return 0 which is not used. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
l2cap_data_channel always return 0 which is not used anywhere, make it void function. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Make A2MP channel special channel which do not reference hci_conn. This prevents from keeping ACL connection open when all L2CAP channels got closed. hci_conn_hold and hci_conn_put are not reference counts on the hci_conn structure in the typical way. They are reference counts for the ACL. When you do the last hci_conn_put, the ACL is disconnected after a timeout. Reported-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Functions will be always defined and in case not implemented as dummy __no_func. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Handle incoming A2MP connection by creating AMP manager and processing A2MP messages. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
A2MP fixed channel do not have sk Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Create and initialize fixed A2MP channel Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Gustavo Padovan 提交于
Move this check to before the channel time creation simplifies the code and avoid memory allocation if the channel already exist. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
Remove socket specific code from l2cap_core.c Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
These vars are kept in sync so we can use chan->state here. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Andrei Emeltchenko 提交于
This move socket specific code to l2cap_sock.c. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Andrei Emeltchenko 提交于
This remove a bit more of socket code from l2cap core, this calls set the SOCK_ZAPPED and do some clean up depending on the socket state. Reported-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
Use chan instead of void * makes more sense here. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
This replace code in l2cap_le_conn_ready() by a similar code in l2cap_chan_ready(). Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
This is already performed inside l2cap_chan_ready(), so we don't need it here again. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
Both FCS and Extended header might be or might not be present in a ERTM channel. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Andrei Emeltchenko 提交于
__constant_cpu_to_le16() is the right go here. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Define assigned Protocol and Service Multiplexor (PSM) identifiers and use them instead of magic numbers. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Mat Martineau 提交于
Sometimes an ACL link must be raised to a higher security level after an L2CAP connection is requested, but before a connection response is sent. In this case, a connection response sent by L2CAP was not immediately followed by a configuration request. Other code paths do send this configuration request right away. It was possible for the connection to stall while L2CAP waited for the remote device (like PTS) to trigger the configuration process. Here is an abbreviated hcidump of the failure case with PTS: 1337806446.051982 > ACL data: handle 43 flags 0x02 dlen 10 L2CAP(s): Info req: type 2 1337806446.052050 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x000000b8 1337806446.595320 > ACL data: handle 43 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 4097 scid 0x0041 1337806446.595673 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 1 status 0 1337806446.595679 < ACL data: handle 43 flags 0x00 dlen 10 L2CAP(s): Info req: type 2 1337806446.669835 > ACL data: handle 43 flags 0x02 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x00000028 1337806446.669899 < HCI Command: Authentication Requested (0x01|0x0011) plen 2 1337806446.669906 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 1 status 1 <security setup here> 1337806446.769888 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 0 status 0 At this point, the connection stalls and no further messages are sent on the L2CAP signaling channel. No data is received either. If we immediately send a configuration request after a successful connect response, the connection completes: 1337724090.041162 > ACL data: handle 43 flags 0x02 dlen 10 L2CAP(s): Info req: type 2 1337724090.041236 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x000000b8 1337724090.597128 > ACL data: handle 43 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 4097 scid 0x0041 1337724090.597236 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 1 status 0 1337724090.597244 < ACL data: handle 43 flags 0x00 dlen 10 L2CAP(s): Info req: type 2 1337724090.660842 > ACL data: handle 43 flags 0x02 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x00000028 1337724090.660926 < HCI Command: Authentication Requested (0x01|0x0011) plen 2 1337724090.660934 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 1 status 1 <security setup here> 1337724090.755162 < ACL data: handle 43 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 0 status 0 1337724090.755171 < ACL data: handle 43 flags 0x00 dlen 23 L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 11 1337724091.361847 > ACL data: handle 43 flags 0x02 dlen 29 L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 15 1337724091.863808 > ACL data: handle 43 flags 0x02 dlen 23 L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 11 1337724091.863882 < ACL data: handle 43 flags 0x00 dlen 29 L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 15 1337724092.683745 > ACL data: handle 43 flags 0x02 dlen 12 L2CAP(d): cid 0x0040 len 8 [psm 4097] 0000: 00 00 11 22 33 44 34 2f ..."3D4/ Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Andrei Emeltchenko 提交于
Define Continuation flag which the only flag used from Flags field in L2CAP Configuration Request and Response. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
Most of the include were unnecessary or already included by some other header. Replace module.h by export.h where possible. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Andrei Emeltchenko 提交于
Previous callers of l2cap_build_conf_rsp in l2cap_config_req use flags instead of continuation flag hardcoded value. It does not change logic and preserve future possible flags. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
These functions were returning always 0, we just make then void. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Gustavo Padovan 提交于
The same check is done just before call l2cap_streaming_send() Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Andrei Emeltchenko 提交于
Silence warnings below: net/bluetooth/l2cap_core.c:1662:24: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:1662:27: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:1683:24: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:1683:27: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:2260:46: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:2574:33: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:2581:33: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:4556:24: warning: Using plain integer as NULL pointer net/bluetooth/l2cap_core.c:4556:27: warning: Using plain integer as NULL pointer Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Gustavo Padovan 提交于
chan->tx_q is only initialized if we use ERTM or Streaming mode. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Mat Martineau 提交于
This enables the new receive and transmit state machines. Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Mat Martineau 提交于
The transmit window values must be configured for streaming mode, even though streaming mode does not have a window. This enables use of extended headers when the transmit window socket option is set to 64 or larger. Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Mat Martineau 提交于
Let the compiler decide if inlining is appropriate. Signed-off-by: NMat Martineau <mathewm@codeaurora.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-