- 18 Jul, 2014 1 commit
-
-
Johan Hedberg authored
The EOPNOTSUPP and ENOTSUPP errors are very similar in meaning, but ENOTSUPP is a fairly new addition to POSIX. Not all libc versions know about the value the kernel uses for ENOTSUPP so it's better to use EOPNOTSUPP to ensure understandable error messages. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 17 Jul, 2014 7 commits
-
-
Johan Hedberg authored
When we're not pairable we should still allow us to act as initiators for pairing, i.e. the HCI_PAIRABLE flag should only be affecting incoming pairing attempts. This patch fixes the relevant checks for the hci_io_capa_request_evt() and hci_pin_code_request_evt() functions. Signed-off-by:
-
Johan Hedberg authored
Even though our side requests authentication, the original action that caused it may be remotely triggered, such as an incoming L2CAP or RFCOMM connect request. To track this information introduce a new hci_conn flag called HCI_CONN_AUTH_INITIATOR. Signed-off-by:
-
Johan Hedberg authored
We're interested in whether an authentication request is because of a remote or local action. So far hci_conn_security() has been used both for incoming and outgoing actions (e.g. RFCOMM or L2CAP connect requests) so without some modifications it cannot know which peer is responsible for requesting authentication. This patch adds a new "bool initiator" parameter to hci_conn_security() to indicate which side is responsible for the request and updates the current users to pass this information correspondingly. Signed-off-by:
-
Johan Hedberg authored
When a new hci_conn object is created the remote SSP authentication requirement is set to the invalid value 0xff to indicate that it is unknown. Once pairing completes however the code was leaving it as-is. In case a new pairing happens over the same connection it is important that we reset the value back to unknown so that the pairing code doesn't make false assumptions about the requirements. Signed-off-by:
-
Vladimir Davydov authored
If the current process is exiting, lingering on socket close will make it unkillable, so we should avoid it. Reproducer: #include <sys/types.h> #include <sys/socket.h> #define BTPROTO_L2CAP 0 #define BTPROTO_SCO 2 #define BTPROTO_RFCOMM 3 int main() { int fd; struct linger ling; fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); //or: fd = socket(PF_BLUETOOTH, SOCK_DGRAM, BTPROTO_L2CAP); //or: fd = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO); ling.l_onoff = 1; ling.l_linger = 1000000000; setsockopt(fd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling)); return 0; } Signed-off-by:Vladimir Davydov <vdavydov@parallels.com> Signed-off-by:
-
Johan Hedberg authored
If user space has a NoInputNoOutput IO capability it makes no sense to bother it with confirmation requests. This patch updates both SSP and SMP to check for the local IO capability before sending a user confirmation request to user space. Signed-off-by:
-
Johan Hedberg authored
Commit 6c53823a reshuffled the way the authentication requirement gets set in the hci_io_capa_request_evt() function, but at the same time it failed to update an if-statement where cp.authentication is used before it has been initialized. The correct value the code should be looking for in this if-statement is conn->auth_type. Signed-off-by:
-
- 16 Jul, 2014 7 commits
-
-
Johan Hedberg authored
We should check the blacklist no matter what, meaning also when we're not connectable. This patch fixes the respective logic in the function making the decision whether to accept a connection or not. Signed-off-by:
-
Johan Hedberg authored
When we have at least one LE slave connection most (probably all) controllers will refuse to initiate any new connections. To avoid unnecessary failures simply check for this situation up-front and skip the connection attempt. Signed-off-by:
-
Johan Hedberg authored
Most (probably all) controllers can only deal with a single slave LE connection at a time. This patch adds a counter for such connections so that the number can be quickly looked up without iterating the connections list. Signed-off-by:
-
Johan Hedberg authored
We need to be able to track slave vs master LE connections in hci_conn_hash, and to be able to do that we need to know the role of the connection by the time hci_conn_add_has() is called. This means in practice the hci_conn_add() call that creates the hci_conn_object. This patch adds a new role parameter to hci_conn_add() function to give the object its initial role value, and updates the callers to pass the appropriate role to it. Since the function now takes care of initializing both conn->role and conn->out values we can remove some other unnecessary assignments. Signed-off-by:
-
Johan Hedberg authored
To make the code more understandable it makes sense to use the new HCI defines for connection role instead of a "bool master" parameter. This makes it immediately clear when looking at the function calls what the last parameter is describing. Signed-off-by:
-
Johan Hedberg authored
Having a dedicated u8 role variable in the hci_conn struct greatly simplifies tracking of the role, since this is the native way that it's represented on the HCI level. Signed-off-by:
-
Johan Hedberg authored
All HCI commands and events, including LE ones, use 0x00 for master role and 0x01 for slave role. It makes therefore sense to add generic defines for these instead of the current LE_CONN_ROLE_MASTER. Having clean defines will also make it possible to provide simpler internal APIs. Signed-off-by:
-
- 15 Jul, 2014 3 commits
-
-
Johan Hedberg authored
The check for the blacklist in hci_le_conn_complete_evt() should be when we know that we have an actual successful connection (ev->status being non-zero). This patch fixes this ordering. Signed-off-by:
-
Johan Hedberg authored
The params variable was just used for storing the return value from the hci_pend_le_action_lookup() function and then checking whether it's NULL or not. We can simplify the code by checking the return value directly. Signed-off-by:
-
Chin-Ran Lo authored
We should suspend hci device and purge remaining data in tx queue before enabling host sleep in firmware. If any data is sent to firmware after host sleep is activated, firmware may end up sending a TX_DONE interrupt to driver. If this interrupt gets delivered to host while the SDIO host controller is suspending, it may crash the system. Conversely, in resume handler, we should resume hci device after host sleep is de-activated. Signed-off-by:
Chin-Ran Lo <crlo@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
- 14 Jul, 2014 3 commits
-
-
Himangi Saraogi authored
This patch removes the null test on ctrl. ctrl is initialized at the beginning of the function to &session->ctrl. Since session is dereferenced prior to the null test, session must be a valid pointer, and &session->ctrl cannot be null. The following Coccinelle script is used for detecting the change: @r@ expression e,f; identifier g,y; statement S1,S2; @@ *e = &f->g <+... f->y ...+> *if (e != NULL || ...) S1 else S2 Signed-off-by:
Himangi Saraogi <himangi774@gmail.com> Acked-by:
Julia Lawall <julia.lawall@lip6.fr> Signed-off-by:
-
Johan Hedberg authored
In the case that the key distribution bits cause us not to generate a local LTK we should not try to re-encrypt if we're currently encrypted with an STK. This patch fixes the check for this in the smp_sufficient_security function. Signed-off-by:
-
Marcel Holtmann authored
The sco_chan_get helper function is only used in two places and really only protects conn->sk with a lock. So instead of hiding that fact, just put the actual code in place where it is used. Signed-off-by:
-
- 13 Jul, 2014 7 commits
-
-
Marcel Holtmann authored
The spinlock protecting the L2CAP ident number can be converted into a mutex since the whole processing is run in a workqueue. So instead of using a spinlock, just use a mutex here. Signed-off-by:
-
Marcel Holtmann authored
The forward declaration of sco_chan_del is not needed and thus just remove it. Move sco_chan_del into the proper location. Signed-off-by:
-
Marcel Holtmann authored
The forward declaration of __sco_chan_add is not needed and thus just remove it. Move __sco_chan_add into the proper location. Signed-off-by:
-
Marcel Holtmann authored
The allocation of inquiry cache entries is triggered as a result of processing HCI events. Since the processing is done in the context of a workqueue, there is no needed to allocate with GFP_ATOMIC in that case. Switch it to GFP_KERNEL. Signed-off-by:
-
Marcel Holtmann authored
The support for LE encryption is optional and with that also the LE Long Term Key Request event. If encryption is not supported, then do not bother enabling this event. Signed-off-by:
-
Marcel Holtmann authored
The support for LE encryption is optional. When encryption is not supported then also do not enable the encryption related events. This moves the event mask setting to the third initialization stage to ensure that the LE features are available. Signed-off-by:
-
Marcel Holtmann authored
The Read LE Advertising Channel TX Power command is not mandatory for a Bluetooth HCI controller only supporting receiption. Move the command to the third stage of the controller initialization and only execute it when support for it has been indicated. Signed-off-by:
-
- 12 Jul, 2014 1 commit
-
-
Marcel Holtmann authored
The protocol for the UART might be configured, but that does not mean the HCI device is registered. Return an error in that case and only return the index number when HCI_UART_REGISTERED is set. Signed-off-by:
-
- 11 Jul, 2014 11 commits
-
-
Alexander Aring authored
This patch add a maintainer entry for "net/6lowpan". Also add the current IEEE 802.15.4 mailing list and bluetooth mailinglist to this branch, because this code is shared between them. Signed-off-by:
Alexander Aring <alex.aring@gmail.com> Acked-by:
Jukka Rissanen <jukka.rissanen@linux.intel.com> Signed-off-by:
-
Alexander Aring authored
This patch moves generic code which is used by bluetooth and ieee802154 6lowpan to a new net/6lowpan directory. This directory contains generic 6LoWPAN code which is shared between bluetooth and ieee802154 MAC-Layer. This is the IPHC - "IPv6 Header Compression" format at the moment. Which is described by RFC 6282 [0]. The BLTE 6LoWPAN draft describes that the IPHC is the same format like IEEE 802.15.4, see [1]. Futuremore we can put more code into this directory which is shared between BLTE and IEEE 802.15.4 6LoWPAN like RFC 6775 or the routing protocol RPL RFC 6550. To avoid naming conflicts I renamed 6lowpan-y to ieee802154_6lowpan-y in net/ieee802154/Makefile. [0] http://tools.ietf.org/html/rfc6282 [1] http://tools.ietf.org/html/draft-ietf-6lowpan-btle-12#section-3.2 [2] http://tools.ietf.org/html/rfc6775 [3] http://tools.ietf.org/html/rfc6550Signed-off-by:
-
Johan Hedberg authored
When we need to make the decision whether to perform just-works or real user confirmation we need to know the exact local authentication requirement that was passed to the controller. So far conn->auth_type (the local requirement) wasn't in one case updated appropriately in fear of the user confirmation being rejected later. The real problem however was not really that conn->auth_type couldn't represent the true value but that we were checking the local MITM requirement in an incorrect way. It's perfectly fine to let auth_type follow what we tell the controller since we're still tracking the target security level with conn->pending_sec_level. This patch updates the check for local MITM requirement in the hci_user_confirm_request_evt function to use the locally requested security level and ensures that auth_type always represents what we tell the controller. All other code in hci_user_confirm_request_evt still uses the auth_type instead of pending_sec_level for determining whether to do just-works or not, since that's the only value that's in sync with what the remote device knows. Signed-off-by:
Szymon Janc <szymon.janc@tieto.com> Signed-off-by:
-
Marcel Holtmann authored
The quirk for enabling external configuration with UART needs to be provided via the HCI UART flags. Add a new flag for it and declare it as valid. Signed-off-by:
-
Marcel Holtmann authored
Providing unknown or invalid flags to the HCI UART driver should result in an error. So check which flags are valid and otherwise return an error. Signed-off-by:
-
Marcel Holtmann authored
There is no external user of the SCO timeout constants and thus move them into net/bluetooth/sco.c where they are actuallu used. In addition just remove SCO_CONN_IDLE_TIMEOUT since it is unused. Signed-off-by:
-
Marcel Holtmann authored
The SCO_DEFAULT_FLUSH_TO constant has been defined, but it is not used anywhere and so just remove it. Signed-off-by:
-
Marcel Holtmann authored
There exists no external user of struct sco_conn and thus move it into the one place that is actually using it. Signed-off-by:
-
Marcel Holtmann authored
There exists no external user of struct sco_pinfo and sco_pi and thus move it into the one place that is actually using it. Signed-off-by:
-
Marcel Holtmann authored
The list of L2CAP fixed channels increased with newer versions of the specification. This just updates the constants for it. Signed-off-by:
-
Marcel Holtmann authored
The internals of the HCI request framework should not be leaking to its users. Move them all into net/bluetooth/hci_core.c and provide a simple hci_req_pending helper function for the one user outside the framework. Signed-off-by:
-
