- 13 Feb, 2014 40 commits
-
-
Andre Guedes authored
This patch adds to hdev the connection parameters list (hdev->le_ conn_params). The elements from this list (struct hci_conn_params) contains the connection parameters (for now, minimum and maximum connection interval) that should be used during the connection establishment. Moreover, this patch adds helper functions to manipulate hdev->le_ conn_params list. Some of these functions are also declared in hci_core.h since they will be used outside hci_core.c in upcoming patches. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
The LTK key types available right now are unauthenticated and authenticated ones. Provide two simple constants for it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
When the ACL link is using P-256 authenticated combination key, mark the link mode as HCI_LM_FIPS. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
This check is only used for RFCOMM connections and most likely no RFCOMM based profile will require security level 4 secure connection security policy. In case it ever does make sure that seucrity level 4 is treated as sufficient security level. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
With support for Secure Connections it is possible to switch the controller into a mode that is called Secure Connections Only. In this mode only security level 4 connections are allowed (with the exception of security level 0 approved services). This patch just introduces the management command and setting of the right internal flags to enable this mode. It does not yet enforce it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The struct smp_ltk does not need to be packed and so remove __packed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The field is not a boolean, it is actually a field for a key type. So name it properly. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The LTK authenticated parameter is the key type of the LTK and similar to link keys there is no need to check the currently supported values. For possible future improvements, the kernel will only use key types it knows about and just ignore all the other ones. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
When encryption for LE links has been enabled, it will always be use AES-CCM encryption. In case of BR/EDR Secure Connections, the link will also use AES-CCM encryption. In both cases track the AES-CCM status in the connection flags. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
The function already has an unlock label which means the one extra level on indentation is not useful and just makes the code more complex. So remove it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
Since the use of debug keys can now be identified from the current settings information, this debugfs entry is no longer necessary. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
Originally allowing the use of debug keys was done via the Load Link Keys management command. However this is BR/EDR specific and to be flexible and allow extending this to LE as well, make this an independent command. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
When the controller has been enabled to allow usage of debug keys, then clearly identify that in the current settings information. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Andre Guedes authored
This patch moves connection attempt failure code to its own function so it can be reused in the next patch. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Andre Guedes authored
This patch groups the list_head fields from struct hci_dev together and removes empty lines between them. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Andre Guedes authored
This patch creates two new fields in struct hci_conn to save the minimum and maximum connection interval values used to establish the connection this object represents. This change is required in order to know what parameters the connection is currently using. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
If LTK distribution happens in both directions we will have two LTKs for the same remote device: one which is used when we're connecting as master and another when we're connecting as slave. When looking up LTKs from the locally stored list we shouldn't blindly return the first match but also consider which type of key is in question. If we do not do this we may end up selecting an incorrect encryption key for a connection. This patch fixes the issue by always specifying to the LTK lookup functions whether we're looking for a master or a slave key. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
All callers of hci_add_ltk pass a valid value to it. There are no places where e.g. user space, the controller or the remote peer would be able to cause invalid values to be passed. Therefore, just remove the potentially confusing check from the beginning of the function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Instead of magic bitwise operations simply compare with the two possible type values that we are interested in. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The code was previously iterating the wrong list (and what's worse casting entries to a type which they were not) and also missing a proper line terminator when printing each entry. The code now also prints the LTK type in hex for easier comparison with the kernel-defined values. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Starting with the 4.1 Core Specification these flags are no longer used and should always be cleared. From volume 3, part C, section 13.1.1: "The 'Simultaneous LE and BR/EDR to Same Device Capable (Controller)' and ‘Simultaneous LE and BR/EDR to Same Device Capable (Host)’ bits in the Flags AD type shall be set to ‘0’." Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
So far we've only been requesting the LTK to be distributed to the master (initiator) of pairing, which is usually enough since it's the master that will establish future connections and initiate encryption. However, in the case that both devices support switching to the opposing role (which seems to be increasingly common) pairing will have to performed again since the "new" master will not have all information. As there is no real harm in it, this patch updates the code to always try distributing the LTK also to the slave device, thereby enabling role switches for future connections. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Vinicius Gomes <vcgomes@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
This patch increments the management interface revision due to the various fixes, improvements and other changes that have been made. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Johan Hedberg authored
Now that ATT sockets have been converted to use the new L2CAP_CHAN_FIXED type there is no need to have an extra check for chan->psm in the l2cap_chan_close function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The l2cap_chan->psm value is always set to a valid value for a connection oriented channel. The l2cap_chan->sport is used for tracking local PSM allocations but will not always have a proper value, such as with connected sockets derived from a listening socket. This patch fixes the sock_getname callback to always use chan->psm when returning address information. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
When we're not connected the peer address information is undefined. This patch fixes the remote address getting to return a proper error in case the sate is anything else than BT_CONNECTED. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
When we're not connected the peer address information is undefined. This patch fixes the remote address getting to return a proper error in case the state is anything else than BT_CONNECTED. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The sport variable is used to track the allocation of the local PSM database to ensure no two sockets take the same local PSM. It is acquired upon bind() but needs to be freed up if the socket ends up becoming a client one. This patch adds the clearing of the value when l2cap_chan_connect is called. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The L2CAP specification requires us to disconnect an L2CAP channel if the remote side gives us credits beyond 65535. This patch makes sure we disconnect the channel in such a situation. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The L2CAP specification requires us to disconnect a channel if the remote device sends us data when it doesn't have any credits to do so. This patch makes sure that we send the appropriate L2CAP Disconnect request in this situation. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
There's a le_default_mps variable that can be modified through debugfs but it was never actually used for determining our MPS value. This patch fixes the MPS initialization to use the variable instead of a fixed value. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
Fixed channels have the same source and destination CID. Ensure that the values get properly initialized when receiving incoming connections and deriving values from the parent socket. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The BT_SECURITY option should also be allowed for fixed channels, so punch the appropriate hole for it when checking for the channel type. The main user of fixed CID user space sockets is right now ATT (which is broken without this patch). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
ATT channels are not connection oriented so having them use L2CAP_CHAN_CONN_ORIENTED is quite confusing. Instead, use the new L2CAP_CHAN_FIXED type and ensure that the MTU and CID values get properly set. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
There's no reason why A2MP should need or deserve its on channel type. Instead we should be able to group all fixed CID users under a single channel type and reuse as much code as possible for them. Where CID specific exceptions are needed the chan-scid value can be used. This patch renames the current A2MP channel type to a generic one and thereby paves the way to allow converting ATT and SMP (and any future fixed channel protocols) to use the new channel type. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
The only user of l2cap_seq_list_remove() was l2cap_seq_list_pop() which only removes the head, meaning only the "else if (seq_list->head == seq)" branch was ever being used. This patch moves the code from this branch straight into l2cap_seq_list_pop() and removes the (now useless) l2cap_seq_list_remove(). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This patch adds a queue for incoming L2CAP data that's received before l2cap_connect_cfm is called and processes the data once l2cap_connect_cfm is called. This way we ensure that we have e.g. all remote features before processing L2CAP signaling data (which is very important for making the correct security decisions). The processing of the pending rx data needs to be done through queue_work since unlike l2cap_recv_acldata, l2cap_connect_cfm is called with the hci_dev lock held which could cause potential deadlocks. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Johan Hedberg authored
This patch moves the l2cap_conn_add, is_valid_psm and l2cap_chan_connect functions further down in l2cap_core.c. The patch doesn't contain anything else except the relocation of these functions. By moving the functions further down the patch enables a subsequent patch that adds a pending RX queue to be implemented without a forward declaration of a function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Oliver Neukum authored
The device is not functional without firmware. The device without firmware: T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=311f Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb The device with firmware: T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=3007 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Oliver Neukum authored
The device will bind to btusb without firmware, but with the original buggy firmware device discovery does not work. No devices are detected. Device descriptor without firmware: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=311e Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms with firmware: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=311e Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-