Convert the code to use the net_buf API instead of the soon to be
removed bt_buf API.
Change-Id: I9437750aa6fffcde31e1879bf6e3a13143f45480
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Convert the code to use the net_buf API instead of the soon to be
removed bt_buf API.
Change-Id: I89e5ac5a178cf57c0a3f7fee38d1170c25e07c5b
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Convert the code to use the net_buf API instead of the soon to be
removed bt_buf API.
Change-Id: I3c7f6c5ec2b447adc8855acf8d66205434ce08eb
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Convert the code to use the net_buf API instead of the soon to be
removed bt_buf API.
Change-Id: I5f376caeb861ac8b815a0a2e235bd188b9e8185b
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Convert the code to use the net_buf API instead of the soon to be
removed bt_buf API.
Change-Id: I7f4577ba31f8e5646873f164ff308c71d23021e5
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Convert the code to use the net_buf API instead of the soon to be
removed bt_buf API.
Change-Id: I226de212d4f8d4f5b613708ffe42570443bc2182
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch performs the minimal necessary conversion to the net_buf
API. It uses a temporary "#define bt_buf net_buf" to make it possible
to convert the code in smaller increments. Most old bt_buf function
also serve as one-line wrappers to the matching net_buf APIs. Once
everything is converted these helpers will be removed.
Change-Id: Ie31433d33576022c9c193a35d2389267005545d6
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We need to have a generic buffer API in order to efficiently transfer
data between different subsystems. The first such case will be the
Networking and Bluetooth subsystems where 6LoWPAN data will be passed
back and forth.
The needed API needs to provide enough flexibility for different
buffer sizes as well as custom protocol-specific context data.
The implementation offered in this patch follows the general design of
the existing Networking and Bluetooth buffer implementations by using
a backing array of buffer which is fed into a "free buffers" FIFO for
management. The main difference is that the API allows specifying
variable sized buffers for each created pool, as well as a minimum
amount of "user data" that's allocated as part of each buffer.
There's also an optional destroy callback that's e.g. useful for HCI
flow control in Bluetooth (for notifying the controller of available
buffers).
Change-Id: I00b7007135a0ff35219f38f48658f31728fbb7ca
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This makes BT_GATT_CHARACTERISTIC declare a local bt_gatt_chrc so the
applications don't need to declare themselves.
Change-Id: Icf3fad7dffea5667c6f13aa022a5722900da51e8
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The spec says it should always be the very first descriptor after the
characteristic:
"BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part G] page 534:
3.3.2 Characteristic Value Declaration
The Characteristic Value declaration contains the value of the
characteristic. It is the first Attribute after the characteristic
declaration. All characteristic definitions shall have a
Characteristic Value declaration."
Change-Id: I6c38dea9cc4c1a05997edbd348e2759680472725
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bt_gatt_register will assign a handle if not initialized and removing
the handle makes it simpler to change the attributes since it is no
longer possible to have conflicting handles.
Change-Id: I787f7325cc990c360056b1aefd07bb7d7876b445
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This allow calling bt_gatt_register multiple times so different tasks
can add their own services separately.
Change-Id: I8143ddedfa1079087d608013d1a97b552a3007dc
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch adds support for Ethernet to the network stack, which
entails relying on the Ethernet device driver to set the MAC address,
invoking ARP routines at the appropriate points, configuring the
Contiki network stack to use the appropriate link-level header length,
etc.
Change-Id: I153a6f4c83c28ca7129ef5affa1e9a18b0f92913
Signed-off-by: Michael LeMay <michael.lemay@intel.com>
We can't use '=' in net/Makefile since then one statement would
override the value of the previous one when both CONFIG_NETWORKING and
CONFIG_BLUETOOTH were set to 'y'. Instead, use '+='.
Change-Id: Idba9916cc9fb2bd0e53975bdf0a86c0fd184533c
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We want to make the naming convention ref/unref rather than get/put.
So far the only reference counted objects are the buffers and the
connections. For the buffers the new generic buffer API will also use
ref/unref.
Change-Id: I9fe8b8a6a50a8baf06ba231e8f6717a5a47dd292
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
bt_uuid_to_str uuid param is const therefore bt_uuid_str should be const
as well.
Change-Id: I043d66d16c863ed92e60477dbbb9c37bcde92703
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The two last fields are 32 bits and 16 bits respectively not the other
way around.
Change-Id: I10d2ed9d69229f02b430f9812e95e4a8f3f060c7
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch fixes a potential issue in which the signed return value
from the network driver send routine is returned from a caller that
has an unsigned return type. The meaning of a negative return value
from the network driver send routine is that an error occurred. A
return value of 1 means that the packet was sent successfully. A
return value of 0 means that the packet could not be sent. Thus, this
patch converts negative return values from the network driver send
routine to a return value of 0 from the caller.
Change-Id: If5cbecb18e514fd976200ecc45782d2a9e1f300f
Signed-off-by: Michael LeMay <michael.lemay@intel.com>
This make use of bt_uuid_to_str to when printing UUID values, to make it
simpler when it is just going to print so the patch introduces a new
function that does the conversion in place using a static variable.
Change-Id: Idfedf05a5ad201653fff2e01387f046cd5647c83
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This allow sending direct notification to a specific peer without
using CCC which is allowed by the spec:
BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part F page 507
3.4.7.1 Handle Value Notification
A server can send a notification of an attribute’s value at any time.
Change-Id: Ieff29216cb9ba197c0da92d7b22b26e63101cfa8
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch cleans up the code a bit. BT_ATT_MAX_LE_MTU defines
MTU that can be used over LE ATT.
Change-Id: Ie433f33f3bcba3275f51e1bea826bb0fd061c45f
Signed-off-by: Mariusz Skamra <mariusz.skamra@tieto.com>
If attribute requires authentication to be read or written,
we check if current security level (should be BT_SECURITY_HIGH
or higher) allows to perform such operations on this attribute.
Change-Id: Ibba542ac96af00722370eba77d6c929cda520fd8
Signed-off-by: Mariusz Skamra <mariusz.skamra@tieto.com>
Always set MITM in AuthReq if local IO capabilities allow it.
This match Security Request behaviour with Pairing Request.
Change-Id: I1734df6661bada296b088cc762a871c443b9e5d1
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
This adds an option to enable L2CAP dynamic channel support, fixed
channels are not affected by it.
Change-Id: If36bece46b7b94142ea1ac976b878d1b5ae6a578
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This refactorer fixed channel data so that the channel itself carries
any extra context necessary.
Change-Id: Iea0f29fb7913a29dccdcbef72d92ec4cf4711bf3
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
From Core Spec Vol 3 Part H 2.3.5.1:
"If both devices have not set the MITM option in the Authentication
Requirements Flags, then the IO capabilities shall be ignored and the Just
Works association model shall be used."
Change-Id: I450f8ab5661382b787fe9742937d47df62fb6cfa
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
This split L2CAP API so that server API is available to applications
while the rest of the API is keep internal to the stack.
Change-Id: I031926ff906ce100684fba0947b2e9eb2c8fcaeb
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The ret variable in net_tx_fiber was declared as unsigned but assigned
larger signed values and treated as signed. This patch fixes that
issue.
Change-Id: I2e33f6115a3defe45f86b5f6c7dc13175ec26827
Signed-off-by: Michael LeMay <michael.lemay@intel.com>
Sanitycheck fails due to compile time warning.
Change-Id: I0b9e95d33e8298a15e09ea2532e335bdc0979d09
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
The function that resolves the source IP address we need to
use when sending a test network IP packet in Linux host is
refactored a bit. No functionality changes here.
Change-Id: I0f9bc79a9a7f01b382116b969739d7ad3f671751
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If Security Request with unsupported flags is received just ignore them
instead of repairing. This is already done for Pairing Request but was
missing in Security Request.
Since we are still on 4.0 just remove any new bits definitions and update
BT_SMP_AUTH_MASK accordingly.
This fix constant repairing (instead of just enabling encryption) with
peripherals that support LE Secure Connections.
Change-Id: Ic053590755e97eadbcadbea788670c050f895d32
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
To have same logs in att_mtu_req and att_mtu_rsp.
Change-Id: Ic820f989d0928089d5b0a6bce21e5e1c369eb026
Signed-off-by: Mariusz Skamra <mariusz.skamra@tieto.com>
According to the Core Spec 4.2 Vol 3 Part G
The server shall respond with the Server Rx MTU parameter set to the
maximum MTU that this server can receive.
Once the messages have been exchanged, the ATT_MTU shall be set
to the minimum of the Client Rx MTU and Server Rx MTU values.
bt: att_mtu_req (0x0010fd04): Client MTU 672
bt: att_mtu_req (0x0010fd04): Server MTU 65
bt: att_mtu_req (0x0010fd04): Negotiated MTU 65
bt: att_mtu_req (0x0010fd04): Client MTU 42
bt: att_mtu_req (0x0010fd04): Server MTU 65
bt: att_mtu_req (0x0010fd04): Negotiated MTU 42
Change-Id: I13f2f0fc99e99d8188ed15bf7972a9b892612e11
Signed-off-by: Mariusz Skamra <mariusz.skamra@tieto.com>
According to the Core Spec we shall respond to Exchange MTU Request
with MTU parameter set to the maximum MTU that we can receive.
As a Client, we shouldn't send an error if Server's Rx MTU exceeds
517 bytes. Whe should respond with our maximum MTU, because
after negotiation is done, ATT_MTU shall be set to the
minimum of the Client Rx MTU and Server Rx MTU values.
Error will be sent only in case of Rx MTU lower than LE default
ATT_MTU (23).
Change-Id: I9fa4f3fdb9b8129d52fc7b2557129c0894e5d201
Signed-off-by: Mariusz Skamra <mariusz.skamra@tieto.com>
BT_* log macros don't add new lines at the end of log message.
Change-Id: I4836f58e45453697a87c0a2b290014083b8e229a
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
According to Core 4.2 Vol 3 Part F 3.3, Commands have 6th bit
(startting from 0) set in ATT PDU. If the bit is set, no response shall be sent.
Change-Id: I63f7303e1cf2f9479dae129cdf5d31d7aadc739d
Signed-off-by: Mariusz Skamra <mariusz.skamra@tieto.com>
If pairing failed before encryption was enabled or if enabling
encryption failed (eg due to remote device missing LTK) required
security level should be reset.
Otherwise it is not possible to re-try with setting security level.
Error reporting to application is still missing though.
Change-Id: I085e3ee116bd04304a4c4563cc40f9d40262447e
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
According to Core Specification "An Error Response shall be sent by
the server in response to the Read Multiple Request if insufficient
authentication, insufficient authorization, insufficient encryption
key size is used by the client, or if a read operation is not permitted
on any of the Characteristic Values. The Error Code parameter is set as
specified in the Attribute Protocol."
If any handle used by client is invalid we should return and error.
Change-Id: I5489ce6284531822676a63edf13db23289866102
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
This patch fixes the issue with 128bit uuid descriptors discovery.
Data from Find Information Response were parsed improperly,
because length took into account the size of pointer to info data,
not data itself.
Change-Id: Ifad0110705bacc3c757a91ebbd97af5ba93897d9
Signed-off-by: Mariusz Skamra <mariusz.skamra@tieto.com>
Factor out role dependent code to helper. This allows to get rid of
'done' label without decresing code readibility. Allows to cleanly
build with CONFIG_BLUETOOTH_PERIPHERAL and CONFIG_BLUETOOTH_SMP
defined.
Change-Id: I33606955ae8b1c75385e2eee89620761d59f0108
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
It is possible that slave sends subsequent Security Request while
link is already encrypted. One example is that current LTK is
unauthenticated and slave wants to increase security with MITM
protection.
Change-Id: I5f079e6140a5912443f770ba2c7cabeffcecdf2b
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
If security level changed due to key refresh application was
not notified about it.
Change-Id: I550095608da6d9bfb885ff2fbf62d9edc0429d06
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
This fix crash due to calling auth callback from wrong pointer.
get_io_capa was using bt_smp_io_capa instead of structure provided
in argument. This resulted in checking NULL pointer for provided
callbacks. By coincident this always returned
BT_SMP_IO_KEYBOARD_DISPLAY (first 8 bytes in memory were non-zero)
and resulted in calling callback from NULL address if application
didn't provided passkey_display or passkey_entry callbacks.
btshell>
bt: bt_smp_connected (0x00115360): conn 0x00111788 handle 73
bt: bt_att_connected (0x00115360): conn 0x00111788 handle 73
bt: bt_gatt_connected (0x00115360): conn 0x00111788
Connected: 20:68:9D:60:A1:E4 (public)
bt: bt_smp_recv (0x00115360): Received SMP code 0x01 len 7
bt: smp_pairing_req (0x00115360):
bt: smp_init (0x00115360): prnd 8773a11cde889e1b7397064527a5469d
***** Unhandled exception/interrupt occurred! *****
Current thread ID = 0x00115360
Faulting instruction address = 0x00111788
Fatal fiber error! Aborting fiber.
Change-Id: Ic297603a3fbc8bd741d5110c01bef61f7dda1d6f
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
