The HCI_CONN_AUTH_PEND flag should be set whenever requesting
authentication so that multiple pending requests can't occur.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Some test systems require an arbitrary delay to the auto-accept test
cases for Secure Simple Pairing in order for the tests to pass.
Previously when this was handled in user space it was worked around by
code modifications and recompilation, but now that it's on the kernel
side it's more convenient if there's a debugfs interface for it.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds automated negative and positive (auto-accept) responses
for Secure Simple Pairing user confirmation requests. The responses are
only sent if the HCI_MGMT flag is set in order not to confuse older user
space versions (without management interface support).
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Extend the mgmt_pin_code_request interface to require secure
pin code (16 digit) for authentication.
This is a kernel part of the secure pin code requirement notification
to user space agent.
Code styling fix by Johan Hedberg.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
If host requires MITM protection notify that to controller in
io capabilities reply even if the remote device requires no bonding.
If it is not respected, host can get an unauthenticated link key while
it expects authenticated one.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
High security level for pre v2.1 devices requires combination link key
authenticated by at least 16 digit PIN code.
It's also necessary to update key_type and pin_length when the key
exists and is sufficently secured for the connection as there will be
no link key notify event in that case.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Keep the link key type together with connection and use it to
map security level to link key requirements. Authenticate and/or
encrypt connection if the link is insufficiently secure.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
If authentication fails the security level should stay as it was set
before the process has started. Setting BT_SECURITY_LOW can hide real
security level on a link eg. having BT_SECURITY_MEDIUM on the link,
re-authenticate with failure to get BT_SECURITY_HIGH, as a result we
get BT_SECURITY_LOW on the link while the real security is still medium.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Introduce the link key types defs and use them instead of magic numbers.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds a new event to the Management interface to track when
local adapters are discovering remote devices. For now this only tracks
BR/EDR discovery procedures.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds start_discovery and stop_discovery commands to the
management interface. Right now their implementation is fairly
simplistic and the parameters are fixed to what user space has
defaulted to so far.
This is the very initial phase for discovery implementation into
the kernel. Next steps include name resolution, LE scanning and
bdaddr type handling.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Anderson Briglia <anderson.briglia@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
There is no need to the socket deal directly with the channel, most of the
time it cares about the channel only.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
In this commit, omtu, imtu, flush_to, mode and sport. It also remove the
pi var from l2cap_sock_sendmsg().
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
l2cap_chan_connect() is a much better name and reflects what this
functions is doing (or will do once socket dependence is removed from the
core).
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
If the allocation happens at l2cap_sock_create() will be able to use the
struct l2cap_chan to store channel info that comes from the user via
setsockopt.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Since
commit a120e912eb
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Fri Feb 19 15:47:33 2010 -0800
iwlwifi: sanity check before counting number of tfds can be free
we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.
On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link, making bisection of other problems impossible.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since
commit a120e912eb
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Fri Feb 19 15:47:33 2010 -0800
iwlwifi: sanity check before counting number of tfds can be free
we use skb->data after calling ieee80211_tx_status_irqsafe(), which
could free skb instantly.
On current kernels I do not observe practical problems related with
bug, but on 2.6.35.y it cause random system hangs when stressing
wireless link.
Cc: stable@kernel.org # 2.6.32+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The locking with SMPS requests means that the
debugs file should lock the mgd mutex, not the
iflist mutex. Calls to __ieee80211_request_smps()
need to hold that mutex, so add an assertion.
This has always been wrong, but for some reason
never been noticed, probably because the locking
error only happens while unassociated.
Cc: stable@kernel.org [2.6.34+]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The patch 'ath9k_hw: fix stopping rx DMA during resets' added code to detect
a condition where rx DMA was stopped, but the MAC failed to enter the idle
state. This condition requires a hardware reset, however the return value
of ath_stoprecv was 'true' in that case, which allowed it to skip the reset
when issuing a fast channel change.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Paul Stewart <pstew@google.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When retrasmitting one frame, only SAR bits in control field should
be kept.
Signed-off-by: Ruiyi Zhang <Ruiyi.zhang@atheros.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
shutdown should wait for SCO link to be properly disconnected before
detroying the socket, otherwise an application using the socket may
assume link is properly disconnected before it really happens which
can be a problem when e.g synchronizing profile switch.
Signed-off-by: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
In the teardown path the reset command is sent to the controller,
this event causes the command timer to be reactivated.
So the timer is removed in two situations, when the adapter isn't
marked as UP and when we know that some command has been sent.
Reported-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
hci_io_capa_reply_evt() holds reference for hciconnection. It's useless since
hci_io_capa_request_evt()/hci_simple_pair_complete_evt() already protects the
connection. In addition it leaves connection open after failed SSP pairing.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
For some reason, sending QoS configuration causes transmission to stop
after a single frame on HT channels when not associated. Removing the
extra QoS configuration has no effect on station mode, and fixes
injection mode.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Fix a regression from the L2CAP "rewrite" patches.
Purge the tx_q already happens on l2cap_chan_del() so we don't need it at
l2cap_disconnect_req().
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
l2cap_get_sock_by_scid was changed to not lock the socket anymore, but I
forgot to change all the users of this function.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Fix an locking issue with the new l2cap_att_channel(). l2cap_att_channel()
was trying to lock a locked socket.
Reported-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
priv->tx_power_next is not initialized to max supported power,
but instead default value is used, what cause errors like
[ 58.597834] iwl3945 0000:03:00.0: Requested user TXPOWER 15 above upper limit 14.
[ 58.597839] iwl3945 0000:03:00.0: Error setting Tx power (-22).
if maximum tx power read from the eeprom is smaller than default.
In consequence card is unable to initialize properly. Fix the problem
and cleanup tx power initialization.
Reported-and-tested-by: Robin Dong <hao.bigrat@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The SD8787 firmware image is shared with mwifiex driver.
Whoever gets loaded first will be responsible for firmware
downloading.
Signed-off-by: Kevin Gan <ganhy@marvell.com>
Signed-off-by: Tristan Xu <xurf@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Check the return value of hu->proto->recv() in hci_uart_tty_receive()
the recv() may return error, check it, not add this to statistics.
Signed-off-by: Jiejing Zhang <jiejing.zhang@freescale.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Use kernel stored remote Out Of Band data only if management interface
is enabled. Otherwise HCI_OP_REMOTE_OOB_DATA_NEG_REPLY was sent to
controller even if remote Out Of Band data was present in bluetoothd.
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Despite it works, handling through l2cap_data_channel() is wrongs.
That function should handle only connection oriented data.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Pass the correct module name and device interface so that
ethtool can display the proper values.
The firmware version will be fixed later on when the FW
can actually report a version. :)
Reported-by: Richard Farina <sidhayn@gmail.com>
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Tested-by: Richard Farina <sidhayn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
During PHY errors, the MAC can sometimes fail to enter an idle state on older
hardware (before AR9380) after an rx stop has been requested.
This typically shows up in the kernel log with messages like these:
ath: Could not stop RX, we could be confusing the DMA engine when we start RX up
------------[ cut here ]------------
WARNING: at drivers/net/wireless/ath/ath9k/recv.c:504 ath_stoprecv+0xcc/0xf0 [ath9k]()
Call Trace:
[<8023f0e8>] dump_stack+0x8/0x34
[<80075050>] warn_slowpath_common+0x78/0xa4
[<80075094>] warn_slowpath_null+0x18/0x24
[<80d66d60>] ath_stoprecv+0xcc/0xf0 [ath9k]
[<80d642cc>] ath_set_channel+0xbc/0x270 [ath9k]
[<80d65254>] ath_radio_disable+0x4a4/0x7fc [ath9k]
When this happens, the state that the MAC enters is easy to identify and
does not result in bogus DMA traffic, however to ensure a working state
after a channel change, the hardware should still be reset.
This patch adds detection for this specific MAC state, after which the above
warnings completely disappear in my tests.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Cc: Kyungwan Nam <Kyungwan.Nam@Atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Otherwise, IWLWIFI_LEGACY has to be selected independently before the
drivers are made available.
Reported-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
