There are several situations where we're interested in knowing whether
we're currently in the process of powering off an adapter. This patch
adds a convenience function for the purpose and makes it public since
we'll soon need to access it from hci_event.c as well.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Pull networking updates from David Miller:
"Highlights:
1) Steady transitioning of the BPF instructure to a generic spot so
all kernel subsystems can make use of it, from Alexei Starovoitov.
2) SFC driver supports busy polling, from Alexandre Rames.
3) Take advantage of hash table in UDP multicast delivery, from David
Held.
4) Lighten locking, in particular by getting rid of the LRU lists, in
inet frag handling. From Florian Westphal.
5) Add support for various RFC6458 control messages in SCTP, from
Geir Ola Vaagland.
6) Allow to filter bridge forwarding database dumps by device, from
Jamal Hadi Salim.
7) virtio-net also now supports busy polling, from Jason Wang.
8) Some low level optimization tweaks in pktgen from Jesper Dangaard
Brouer.
9) Add support for ipv6 address generation modes, so that userland
can have some input into the process. From Jiri Pirko.
10) Consolidate common TCP connection request code in ipv4 and ipv6,
from Octavian Purdila.
11) New ARP packet logger in netfilter, from Pablo Neira Ayuso.
12) Generic resizable RCU hash table, with intial users in netlink and
nftables. From Thomas Graf.
13) Maintain a name assignment type so that userspace can see where a
network device name came from (enumerated by kernel, assigned
explicitly by userspace, etc.) From Tom Gundersen.
14) Automatic flow label generation on transmit in ipv6, from Tom
Herbert.
15) New packet timestamping facilities from Willem de Bruijn, meant to
assist in measuring latencies going into/out-of the packet
scheduler, latency from TCP data transmission to ACK, etc"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1536 commits)
cxgb4 : Disable recursive mailbox commands when enabling vi
net: reduce USB network driver config options.
tg3: Modify tg3_tso_bug() to handle multiple TX rings
amd-xgbe: Perform phy connect/disconnect at dev open/stop
amd-xgbe: Use dma_set_mask_and_coherent to set DMA mask
net: sun4i-emac: fix memory leak on bad packet
sctp: fix possible seqlock seadlock in sctp_packet_transmit()
Revert "net: phy: Set the driver when registering an MDIO bus device"
cxgb4vf: Turn off SGE RX/TX Callback Timers and interrupts in PCI shutdown routine
team: Simplify return path of team_newlink
bridge: Update outdated comment on promiscuous mode
net-timestamp: ACK timestamp for bytestreams
net-timestamp: TCP timestamping
net-timestamp: SCHED timestamp on entering packet scheduler
net-timestamp: add key to disambiguate concurrent datagrams
net-timestamp: move timestamp flags out of sk_flags
net-timestamp: extend SCM_TIMESTAMPING ancillary data struct
cxgb4i : Move stray CPL definitions to cxgb4 driver
tcp: reduce spurious retransmits due to transient SACK reneging
qlcnic: Initialize dcbnl_ops before register_netdev
...
Conflicts:
net/6lowpan/iphc.c
Minor conflicts in iphc.c were changes overlapping with some
style cleanups.
John W. Linville says:
====================
Please pull this last(?) batch of wireless change intended for the
3.17 stream...
For the NFC bits, Samuel says:
"This is a rather quiet one, we have:
- A new driver from ST Microelectronics for their NCI ST21NFCB,
including device tree support.
- p2p support for the ST21NFCA driver
- A few fixes an enhancements for the NFC digital laye"
For the Atheros bits, Kalle says:
"Michal and Janusz did some important RX aggregation fixes, basically we
were missing RX reordering altogether. The 10.1 firmware doesn't support
Ad-Hoc mode and Michal fixed ath10k so that it doesn't advertise Ad-Hoc
support with that firmware. Also he implemented a workaround for a KVM
issue."
For the Bluetooth bits, Gustavo and Johan say:
"To quote Gustavo from his previous request:
'Some last minute fixes for -next. We have a fix for a use after free in
RFCOMM, another fix to an issue with ADV_DIRECT_IND and one for ADV_IND with
auto-connection handling. Last, we added support for reading the codec and
MWS setting for controllers that support these features.'
Additionally there are fixes to LE scanning, an update to conform to the 4.1
core specification as well as fixes for tracking the page scan state. All
of these fixes are important for 3.17."
And,
"We've got:
- 6lowpan fixes/cleanups
- A couple crash fixes, one for the Marvell HCI driver and another in LE SMP.
- Fix for an incorrect connected state check
- Fix for the bondable requirement during pairing (an issue which had
crept in because of using "pairable" when in fact the actual meaning
was "bondable" (these have different meanings in Bluetooth)"
Along with those are some late-breaking hardware support patches in
brcmfmac and b43 as well as a stray ath9k patch.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When we're not bondable we should never send any other SSP
authentication requirement besides one of the non-bonding ones.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This setting maps to the HCI_BONDABLE flag which tracks whether we're
bondable or not. Therefore, rename the mgmt setting and respective
command accordingly.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The HCI_PAIRABLE flag isn't actually controlling whether we're pairable
but whether we're bondable. Therefore, rename it accordingly.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The new leds bit handling produces this spares warning.
CHECK net/bluetooth/hidp/core.c
net/bluetooth/hidp/core.c:156:60: warning: dubious: x | !y
Just fix it by doing an explicit x << 0 shift operation.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Both BT_CONNECTED and BT_CONFIG state mean that we have a baseband link
available. We should therefore check for either of these when pairing
and deciding whether to call hci_conn_security() directly.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
John W. Linville says:
====================
pull request: wireless-next 2014-07-25
Please pull this batch of updates intended for the 3.17 stream!
For the mac80211 bits, Johannes says:
"We have a lot of TDLS patches, among them a fix that should make hwsim
tests happy again. The rest, this time, is mostly small fixes."
For the Bluetooth bits, Gustavo says:
"Some more patches for 3.17. The most important change here is the move of
the 6lowpan code to net/6lowpan. It has been agreed with Davem that this
change will go through the bluetooth tree. The rest are mostly clean up and
fixes."
and,
"Here follows some more patches for 3.17. These are mostly fixes to what
we've sent to you before for next merge window."
For the iwlwifi bits, Emmanuel says:
"I have the usual amount of BT Coex stuff. Arik continues to work
on TDLS and Ariej contributes a few things for HS2.0. I added a few
more things to the firmware debugging infrastructure. Eran fixes a
small bug - pretty normal content."
And for the Atheros bits, Kalle says:
"For ath6kl me and Jessica added support for ar6004 hw3.0, our latest
version of ar6004.
For ath10k Janusz added a printout so that it's easier to check what
ath10k kconfig options are enabled. He also added a debugfs file to
configure maximum amsdu and ampdu values. Also we had few fixes as
usual."
On top of that is the usual large batch of various driver updates --
brcmfmac, mwifiex, the TI drivers, and wil6210 all get some action.
Rafał has also been very busy with b43 and related updates.
Also, I pulled the wireless tree into this in order to resolve a
merge conflict...
P.S. The change to fs/compat_ioctl.c reflects a name change in a
Bluetooth header file...
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
If we have entries in the whitelist we shouldn't disable page scanning
when disabling connectable mode. This patch adds the necessary check to
the Set Connectable command handler.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch fixes a typo in the hci_cc_write_scan_enable() function where
we want to clear the HCI_PSCAN flag if the SCAN_PAGE bit of the HCI
command parameter was not set.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
With the Bluetooth 4.1 specification the Simultaneous LE and BR/EDR
controller option has been deprecated. It shall be set to zero and
ignored otherwise.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Expose the default values for minimum and maximum LE advertising
interval via debugfs for testing purposes.
Signed-off-by: Georg Lukas <georg@op-co.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Store the default values for minimum and maximum advertising interval
with all the other controller defaults. These vaules are sent to the
adapter whenever advertising is (re)enabled.
Signed-off-by: Georg Lukas <georg@op-co.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Devices using resolvable private addresses are required to provide
an identity resolving key. These devices can not be found using
the current controller white list support. This means if the kernel
knows about any devices with an identity resolving key, the white
list filtering must be disabled.
However so far the kernel kept identity resolving keys around even
for devices that are not using resolvable private addresses. The
notification to userspace clearly hints to not store the key and
so it is best to just remove the key from the kernel as well at
that point.
With this it easy now to detect when using the white list is
possible or when kernel side resolving of addresses is required.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Bluetooth controller can use a white list filter when scanning
to avoid waking up the host for devices that are of no interest.
Devices marked as reporting, direct connection (incoming) or general
connection are now added to the controller white list. The update of
the white list happens just before enabling passive scanning.
In case the white list is full and can not hold all devices, the
white list is not used and the filter policy set to accept all
advertisements.
Using the white list for scanning allows for power saving with
controllers that do not handle the duplicate filtering correctly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When adding remote devices to the kernel using the Add Device management
command, these devices are explicitly allowed to connect. This kind of
incoming connections are possible even when the controller itself is
not connectable.
For BR/EDR this distinction is pretty simple since there is only one
type of incoming connections. With LE this is not that simple anymore
since there are ADV_IND and ADV_DIRECT_IND advertising events.
The ADV_DIRECT_IND advertising events are send for incoming (slave
initiated) connections only. And this is the only thing the kernel
should allow when adding devices using action 0x01. This meaning
of incoming connections is coming from BR/EDR and needs to be
mapped to LE the same way.
Supporting the auto-connection of devices using ADV_IND advertising
events is an important feature as well. However it does not map to
incoming connections. So introduce a new action 0x02 that allows
the kernel to connect to devices using ADV_DIRECT_IND and in addition
ADV_IND advertising reports.
This difference is represented by the new HCI_AUTO_CONN_DIRECT value
for only connecting to ADV_DIRECT_IND. For connection to ADV_IND and
ADV_DIRECT_IND the old value HCI_AUTO_CONN_ALWAYS is used.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Unconditionally connecting to devices sending ADV_DIRECT_IND when
the controller is in CONNECTABLE mode is a feature that is not
fully working. The background scanning trigger for this has been
removed, but the statement allowing it to happen in case some
other part triggers is still present. So remove that code part
as well to avoid unwanted connections.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If the Bluetooth controller supports Get MWS Transport Layer
Configuration command, then issue it during initialization.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If the Bluetooth controller supports Read Local Supported Codecs
command, then issue it during initialization so that the list of
codecs is known.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The commits 08c30aca9e "Bluetooth: Remove
RFCOMM session refcnt" and 8ff52f7d04
"Bluetooth: Return RFCOMM session ptrs to avoid freed session"
allow rfcomm_recv_ua and rfcomm_session_close to delete the session
(and free the corresponding socket) and propagate NULL session pointer
to the upper callers.
Additional fix is required to terminate the loop in rfcomm_process_rx
function to avoid use of freed 'sk' memory.
The issue is only reproducible with kernel option CONFIG_PAGE_POISONING
enabled making freed memory being changed and filled up with fixed char
value used to unmask use-after-free issues.
Signed-off-by: Vignesh Raman <Vignesh_Raman@mentor.com>
Signed-off-by: Vitaly Kuzmichev <Vitaly_Kuzmichev@mentor.com>
Acked-by: Dean Jenkins <Dean_Jenkins@mentor.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
It's safer practice to use sizeof(*ptr) instead of sizeof(ptr_type) when
allocating memory in case the type changes. This also fixes the
following style of warnings from static analyzers:
CHECK: Prefer kzalloc(sizeof(*ie)...) over kzalloc(sizeof(struct inquiry_entry)...)
+ ie = kzalloc(sizeof(struct inquiry_entry), GFP_KERNEL);
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The variable ret does not need to be assigned when declaring it. So
remove this initial assignment.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When HCI_CONNECTABLE is set the code has been enabling passive scanning
in order to be consistent with BR/EDR and accept connections from any
device doing directed advertising to us. However, some hardware
(particularly CSR) can get very noisy even when doing duplicates
filtering, making this feature waste resources.
Considering that the feature is for fairly corner-case use (devices
who'd use directed advertising would likely be in the whitelist anyway)
it's better to disable it for now. It may still be brought back later,
possibly with a better implementation (e.g. through improved scan
parameters).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit 6c53823ae0 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: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 3.16
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The current "wait_on_bit" interface requires an 'action'
function to be provided which does the actual waiting.
There are over 20 such functions, many of them identical.
Most cases can be satisfied by one of just two functions, one
which uses io_schedule() and one which just uses schedule().
So:
Rename wait_on_bit and wait_on_bit_lock to
wait_on_bit_action and wait_on_bit_lock_action
to make it explicit that they need an action function.
Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
which are *not* given an action function but implicitly use
a standard one.
The decision to error-out if a signal is pending is now made
based on the 'mode' argument rather than being encoded in the action
function.
All instances of the old wait_on_bit and wait_on_bit_lock which
can use the new version have been changed accordingly and their
action functions have been discarded.
wait_on_bit{_lock} does not return any specific error code in the
event of a signal so the caller must check for non-zero and
interpolate their own error code as appropriate.
The wait_on_bit() call in __fscache_wait_on_invalidate() was
ambiguous as it specified TASK_UNINTERRUPTIBLE but used
fscache_wait_bit_interruptible as an action function.
David Howells confirms this should be uniformly
"uninterruptible"
The main remaining user of wait_on_bit{,_lock}_action is NFS
which needs to use a freezer-aware schedule() call.
A comment in fs/gfs2/glock.c notes that having multiple 'action'
functions is useful as they display differently in the 'wchan'
field of 'ps'. (and /proc/$PID/wchan).
As the new bit_wait{,_io} functions are tagged "__sched", they
will not show up at all, but something higher in the stack. So
the distinction will still be visible, only with different
function names (gds2_glock_wait versus gfs2_glock_dq_wait in the
gfs2/glock.c case).
Since first version of this patch (against 3.15) two new action
functions appeared, on in NFS and one in CIFS. CIFS also now
uses an action function that makes the same freezer aware
schedule call as NFS.
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: David Howells <dhowells@redhat.com> (fscache, keys)
Acked-by: Steven Whitehouse <swhiteho@redhat.com> (gfs2)
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steve French <sfrench@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140707051603.28027.72349.stgit@notabene.brown
Signed-off-by: Ingo Molnar <mingo@kernel.org>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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 <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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: Marcel Holtmann <marcel@holtmann.org>
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: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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/rfc6550
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
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: Johan Hedberg <johan.hedberg@intel.com>
Tested-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 3.16
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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 <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
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: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There exists no external user of struct hci_pinfo and hci_pi and thus
move it into the one place that is actually using it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The hci_sec_filter socket filter details do not change. They are fixed
and with that they can also be delcared as const.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There is only single location using struct hci_sec_filter and with
that there is no point in putting this declaration into a global
header file. So move it right next to its user and make the code
a lot more simpler.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the controller is brought up using legacy ioctl, the setting of
the HCI_PAIRABLE flag should happen then. Previously it was set during
enumeration and when retrieving device information.
This change also will not set the HCI_PAIRABLE flag when the controller
is used with the HCI User Channel operation.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
During the initial setup phase, the controller is powered on and will
be powered off again if it is not used within the auto-off timeout.
Userspace using ioctl does not know about the difference between the
initial setup phase and a controller being present. It is a bad idea
to keep the controller powered by just looking at the device list or
device information. Instead just tell userspace that the controller
is still down.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Set Connectable/Discoverable mgmt handlers use a hci_request with a
proper callback to handle the HCI command sending. It makes therefore
little sense to have this extra function to be called from hci_event.c
for command failures.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Since the HCISETSCAN ioctl is the only non-mgmt user we care about for
setting the right discoverable state we can simply do the necessary
updates in the ioctl handler function instead. This then allows the
removal of the mgmt_discoverable function and should simplify that state
handling considerably.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
With subsequent patches we'll also need to update the discoverable
state. As the code grows bigger it's better to move this out from the
switch statement into its own function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The mgmt_connectable function has been used to ensure that the right
actions to HCI_CONNECTABLE are taken when the HCI_Write_Scan_Enable
command is triggered by something else than mgmt. The only other user
that we really care about is the HCISETSCAN ioctl code, so we can
actually more simply perform the needed changes there instead.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The code for updating the HCI_CONNECTABLE flag was incorrectly using
test_and_set_bit instead of test_and_clear_bit when HCI_CONNECTABLE is
to be cleared.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the remote device tries to initiate bonding with us and we don't have
HCI_PAIRABLE set we should just flat out reject the request. This brings
SMP in line with how the flag is used for BR/EDR SSP.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When we change the connectable state and have advertising enabled we
should update the advertising parameters no matter what. The code was
incorrectly only updating them if advertising was not already active.
This patch fixes the issue.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When the SMP context is created all flags default to zero. To determine
that we are the initiators it's therefore best to simply change the flag
value when we know we're sending the first SMP PDU. Clearing the flag
when receiving a Pairing Request is not correct since the request may be
a response to a previous Security Request from us (for which we would
already have correctly set the flag). Same goes for receiving a Security
Request which may be coming after us already starting pairing by sending
a Pairing Request.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Whether we bond or not should not have any impact on the user
interaction model. This patch removes an incorrect fall-back from
JUST_CFM to JUST_WORKS in case we're not bonding.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For incoming requests we want to let the user know that pairing is
happening since otherwise there could be access to MEDIUM security
services without any user interaction at all. Therefore, set the
selected method to JUST_CFM instead of JUST_WORKS and let it be
converted back to JUST_WORKS later if we are the initators.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When ERTM support is disabled, then do not even send ERTM configuration
option even if the remote side supports it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the white list is in use the code would not update the
HCI_CONNECTABLE flag if it gets changed through the ioctl code (e.g.
hciconfig hci0 pscan). Since the flag is important for properly
accepting incoming connections add code to fix it up if necessary and
emit a New Settings mgmt event.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds support for looking up entries in the white list when
HCI_CONNECTABLE is not set. The logic is fairly simple: if we're
connectable check the black list, if we're not connectable check the
white list.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Page scan should be enabled either if the connectable setting is set or
if there are any entries in the BR/EDR white list. This patch implements
such behavior by updating the two places that were making decisions on
whether to enable page scan or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The conditions for accepting an incoming connections are already
non-trivial and will become more so once a white list is added. This
patch breaks up the checks for when to reject the request by creating a
helper function for it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Since page scan might be enabled by Add Device we should not implicitly
set connectable whenever something else than Set Connectable changes it.
This patch makes sure that we don't set HCI_CONNECTABLE for these cases
if there are any entries in the white list.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When we're removing the last item in the white list or adding the first
one to it and HCI_CONNECTABLE is not set we need to update the current
page scan. This patch adds a simple helper function for the purpose and
calls it from the respective mgmt command handlers.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch extends the Add/Remove device commands by letting user space
pass BR/EDR addresses to them. The resulting entries get stored in a new
hdev->whitelist list. The idea is that we can now selectively accept
connections from devices in the list even though HCI_CONNECTABLE is not
set (the actual implementation of this is coming in a subsequent patch).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We already have several lists with struct bdaddr_list entries, and there
will be more in the future. Since the operations for adding, removing,
looking up and clearing entries in these lists are exactly the same it
doesn't make sense to define new functions for every single list. This
patch unifies the functions by passing the list_head to them instead of
a hci_dev pointer.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Authenticated Payload Timeout Expired event is valid for
controllers with BR/EDR Secure Connections support, but also for
LE only controllers supporting LE Ping feature. When either of them
is available enable this event. Previous it was not enabled when
the controller was only supporting LE operation.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
All LE controllers always implicitly stop advertising when establishing
connections. Therefore, be sure to clear the flag in the event handler
for new LE connections.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the connectable state change doesn't require any special HCI commands
the set_connectable_update_settings() function is used instead of the
set_connectable_complete() function. We must therefore make sure to call
hci_update_background_scan() there as well. This code path is used also
when we're powered off, but that's fine since hci_update_background_scan()
has the necessary checks for it.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The connectable and discoverable mgmt settings are supported both for LE
and BR/EDR controllers so they do not belong behind a lmp_bredr_capable()
condition. This patch fixes the issue in get_supported_settings().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If any of the HCI commands from the hci_stop_discovery function were
successfully sent we need to set the discovery state to STOPPING. The
Stop Discovery code was already handling this, but the code in
clean_up_hci_state was not. This patch updates the hci_stop_discovery to
return a bool to indicate whether it queued any commands and the
clean_up_hci_state() function respectively to look at the return value
and call hci_discovery_set_state() if necessary.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There are many different places that can disable LE scanning but we only
want to re-enable advertising in hci_cc_le_set_scan_enable() for a very
specific use case, which is when the active scanning part of Start
Discovery is complete. Because of this, fix the discovery state check to
test for the exact state.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Many controllers allow simultaneous active scanning and advertising
(e.g. Intel and Broadcom) but some do not (e.g. CSR). It's therefore
safest to implement mutual exclusion of these states in the kernel.
This patch ensures that the two states are never entered simultaneously.
Extra precaution needs to be taken for outgoing connection attempts in
slave role (i.e. through directed advertising) in which case the
operation that came first has precedence and the one that comes after
gets a rejection.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Most controllers do not support advertising while initiating an LE
connection. We also have to first disable current advertising if the
initiation is going to happen through direct advertising. Therefore,
simply stop advertising as the first thing when starting to issue
commands to establish an LE connection.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When deciding to call disable_advertising() we're interested in the real
state instead of the mgmt setting. Use therefore HCI_LE_ADV instead of
the HCI_ADVERTISING flag.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
By adding support for disabling advertising when necessary and doing the
checks for existing LE connections inside the enable_advertising
function we can simplify the calling code quite a lot.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Now that we have a flag for tracking the real advertising state we
should use that to determine whether it's safe to update the random
address or not. The couple of places that were clearing the flag due to
a pending request need to be updated too.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Since the real advertising state is now tracked with its own flag we can
simply set/unset the HCI_ADVERTISING flag in the
set_advertising_complete function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Having a single HCI_ADVERTISING flag is problematic since it tries to
track both the real advertising state and the corresponding mgmt
setting. To make the logic simpler and more reliable add a new flag that
only tracks the actual advertising state that has been written to the
controller.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For adapters that do not support LE and ones where LE hasn't been
enabled we shouldn't be trying to initiate background scanning. This
patch adds an extra check to the hci_update_background_scan() to ensure
that we bail out if HCI_LE_ENABLED is not set.
Since we do allow user space to feed the kernel with LE connection
parameters even when LE is not enabled we now need to also call
hci_update_background_scan() as soon as LE gets enabled so that scanning
gets started if necessary.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If we have both LE scanning and advertising simultaneously enabled we
need a way to tell hci_connect_le() in which role to initiate a
connection. This patch adds a new parameter to the function to give it
the necessary information. For auto-connect and mgmt_pair_device we
always use master role, whereas for L2CAP users (in practice sockets) we
use slave role whenever HCI_ADVERTISING is set and master role
otherwise.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
