The controller may have link keys in its own memory and these keys could
be used for secure connections. However, since the interface to access
these keys doesn't provide information about the key types (which would
be needed to infer the level of security each key provides) using these
keys is rather useless. Therefore, simply clear the controller side list
in the initialization procedure.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
To support a more dynamic HCI initialization sequence the __hci_request
behavior requires some more changes. Particularly, the init sequence
should be able to have conditionals in it (sending some HCI commands
depending on the outcome of a previous command) instead of being a fixed
list as it is right now.
The reasons for these additional requirements are the moving all
previously user space driven initialization commands to the kernel side
as well as the support the Low Energy controllers.
To fulfull these requirements the init sequence is made the only special
case for multi-command requests and req_last_cmd is renamed to
init_last_cmd. The hci_send_cmd function is changed to update
init_last_cmd as long as the HCI_INIT flag is set.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds the necessary logic to act accordingly when the
HCI_PAIRABLE flag is not set. In that case PIN code replies as well as
Secure Simple Pairing requests without a NoBonding requirement need to
be rejected.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds a debugfs entry to list the UUIDs that have been
registered through the management interface.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds methods to the management interface for userspace to
notify the kernel of which services have been registered for specific
adapters. This information is needed for setting the appropriate Class
of Device value as well as the Extended Inquiry Response value. This
patch doesn't actually implement setting of these values but just
provides the storage of the UUIDs so the needed functionality can be
built on top of it.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch implements a new set_pairable management command to control
the pairable state of local adapters. The state is represented using a
new HCI_PAIRABLE flag in the hci_dev struct.
For backwards compatibility with older user space versions the
HCI_PAIRABLE flag gets automatically set when the existence of an
adapter is reported to user space through legacy methods and the
HCI_MGMT flag is not set.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Several management commands have similar responses but they are not
always sent asynchronously. To enable synchronous sending (from the
managment command handler function) a send_mode_rsp function is added.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds a HCI_MGMT flag to track adapters which are under the
control of the management interface. This is needed to make sure that
new kernels will work with old user space versions. I.e. behaviour which
could break old user space versions (but is needed by the management
interface) should not be exhibited when the HCI_MGMT flag is not set.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
The powered, connectable and discoverable messages all have the same
format. By using a single struct for all of them a lot of code can be
simplified and reused.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds a set_connectable command as well as a corresponding
event to the management interface. It's mainly useful for setting an
adapter as connectable from a non-initialized state as well as setting
an already initialized adapter as non-connectable (mostly useful for
qualification purposes).
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds a set_discoverable command to the management interface
as well as the corresponding event. The command is used to control the
discoverable state of adapters.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds a set_powered command to the management interface
through which the powered state of local adapters can be controlled.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch adds support for the powered event that's used to indicate to
userspace when the powered state of a local adapter changes.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
This patch implements automatic initialization of basic information
about newly registered Bluetooth adapters. E.g. the address and features
are always needed so it makes sense for the kernel to automatically
power on adapters and read this information. A new HCI_SETUP flag is
added to track this state.
In order to not consume unnecessary amounts of power if there isn't a
user space available that could switch the adapter back off, a timer is
added to do this automatically as long as no Bluetooth user space seems
to be present. A new HCI_AUTO_OFF flag is added that user space needs to
clear to avoid the automatic power off.
Additionally, the management interface index_added event is moved to the
end of the HCI_SETUP stage so a user space supporting the managment
inteface has all the necessary information available for fetching when
it gets notified of a new adapter. The HCI_DEV_REG event is kept in the
same place as before since existing HCI raw socket based user space
versions depend on seeing the kernels initialization sequence
(hci_init_req) to determine when the adapter is ready for use.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Modification of Nick Pelly <npelly@google.com> patch.
With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit
makes ACL data packets non-flushable by default on compatible chipsets, and
adds the BT_FLUSHABLE socket option to explicitly request flushable ACL
data packets for a given L2CAP socket. This is useful for A2DP data which can
be safely discarded if it can not be delivered within a short time (while
other ACL data should not be discarded).
Note that making ACL data flushable has no effect unless the automatic flush
timeout for that ACL link is changed from its default of 0 (infinite).
Default packet types (for compatible chipsets):
Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
Bluetooth HCI H4
Bluetooth HCI ACL Packet
.... 0000 0000 0010 = Connection Handle: 0x0002
..00 .... .... .... = PB Flag: First Non-automatically Flushable Packet (0)
00.. .... .... .... = BC Flag: Point-To-Point (0)
Data Total Length: 8
Bluetooth L2CAP Packet
After setting BT_FLUSHABLE
(sock.setsockopt(274 /*SOL_BLUETOOTH*/, 8 /* BT_FLUSHABLE */, 1 /* flush */))
Frame 34: 13 bytes on wire (104 bits), 13 bytes captured (104 bits)
Bluetooth HCI H4
Bluetooth HCI ACL Packet
.... 0000 0000 0010 = Connection Handle: 0x0002
..10 .... .... .... = PB Flag: First Automatically Flushable Packet (2)
00.. .... .... .... = BC Flag: Point-To-Point (0)
Data Total Length: 8
Bluetooth L2CAP Packet
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
If alloc_skb() fails in read_index_list() we'll return -ENOMEM without
releasing 'hci_dev_list_lock'.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
"ap" is the address of sdata->u.ap so it can never be NULL here. Also
we dereferenced it on the previous line. I removed the check.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add few comments for not parsing DTIM period from mac80211
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 now supports passing MCS index to radiotap, so update the
comments regarding this
Signed-off-by: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since 4-addr frames completely override the source address which will
make it into the converted 802.3 frames, receiving frames for other
4-addr stations will confuse the bridging code.
To be able to handle traffic for all connected devices, the bridge
code will automatically turn on promiscuous mode, which triggers
this problem.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Steve Brown <sbrown@cortland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This allows users to tune the connection-loss algorithms
to be more or less lenient. In particular, larger
null-func retries helps when using lots of virtual
stations on a loaded network.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fast channel change fixes:
a) Always set OFDM timings
b) Don't re-activate PHY
c) Enable only NF calibration, not AGC
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This code, and the places that set the variable
is_internal_short_scan and the vif pointers are
all protected by the mutex, there's no point in
locking the spinlock here as well (any more).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
This should decrease un-necessary flushes, on/off channel work,
and channel changes in cases where the only scanned channel is
the current operating channel.
* Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
and is-scanning flags instead.
* Add helper method to determine if we are currently configured
for the operating channel.
* Do no blindly go off/on channel in work.c Instead, only call
appropriate on/off code when we really need to change channels.
Always enable offchannel-ps mode when starting work,
and disable it when we are done.
* Consolidate ieee80211_offchannel_stop_station and
ieee80211_offchannel_stop_beaconing, call it
ieee80211_offchannel_stop_vifs instead.
* Accept non-beacon frames when scanning on operating channel.
* Scan state machine optimized to minimize on/off channel
transitions. Also, when going on-channel, go ahead and
re-enable beaconing. We're going to be there for 200ms,
so seems like some useful beaconing could happen.
Always enable offchannel-ps mode when starting software
scan, and disable it when we are done.
* Grab local->mtx earlier in __ieee80211_scan_completed_finish
so that we are protected when calling hw_config(), etc.
* Pass probe-responses up the stack if scanning on local
channel, so that mlme can take a look.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since even with the latest changes the false positive issue of the baseband
hang check is not fully solved yet, additional checks are needed.
If the baseband hang occurs, the rx_clear signal will be stuck to high, so
we can use the cycle counters to confirm it.
With this patch, a hardware reset is only triggered if the baseband hang
check returned true three times in a row, with a beacon interval between
each check and if the busy time was also 99% or more during the check
intervals.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I can't think of a valid use case for this aside from debugging (which can
also be done with a real monitor interface), and dropping these frames saves
some precious CPU cycles.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All register writes to the key cache have to be done in pairs. However,
the clearing of a separate MIC entry with hardware revisions that use
combined MIC key layout did not do that with one of the registers. Add
the matching register write to the following register to make the KEY4
register write actually complete.
This is mostly a fix for a theoretical issue since the incorrect entry
that could potentially be left behind in the key cache would not match
with received frames. Anyway, better make this code clean the entry
correctly using paired register writes.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While leaving oper channel, STA informs sleep state to AP to
stop sending data. Till sending ack for the nullfunc, AP
continues to send the data to STA which restarts ps_timer that
is causing unnecessary nullfunc exchange on timer expiry
when the STA was already moved to offchannel. So don't restart ps_timer
on data reception during scan. This issue was identified by
the following warning.
WARNING: at net/mac80211/tx.c:661 invoke_tx_handlers+0xf07/0x1330 [mac80211]
wlan0: Dropped data frame as no usable bitrate found while scanning and
associated. Target station: 00:03:7f:0b:a6:1b on 5 GHz band
Call Trace:
[<ffffffffa0413ba7>] invoke_tx_handlers+0xf07/0x1330 [mac80211]
[<ffffffffa0414056>] ieee80211_tx+0x86/0x2c0 [mac80211]
[<ffffffffa0414345>] ieee80211_xmit+0xb5/0x1d0 [mac80211]
[<ffffffffa04037e0>] ieee80211_dynamic_ps_enable_work+0x0/0xb0 [mac80211]
[<ffffffffa04158cf>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
[<ffffffffa04026e6>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
[<ffffffffa0403885>] ieee80211_dynamic_ps_enable_work+0xa5/0xb0 [mac80211]
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It should be safe to enable AP-mode now.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RX appears to freeze while idle. Resetting rx-urbs appears to be enough to fix
this. Do reset 30 seconds after last rx.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When driver fails to acquire device semaphore lock, device usually
freezes soon afterwards. So failing to acquire lock indicates us that
not everything is going right in device/fw. So reset device when
this happens.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When doing transfers at high speed for long time, tx queue can freeze. So add
tx watchdog. TX-watchdog checks for locked tx-urbs and reset hardware when
such is detected. Merely unlinking urb was not enough, device have to be
reseted. Hw settings are restored so that any open link will stay on after
reset.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We need HW hard reset later in patchset to reset device after TX-stall.
Collect all settings that we have set to driver for later reset and
add restore function.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Device command timeouts are set up very high (1 sec) and this causes
AP beacon to lock up for long for example. Checking timeouts on device
it's easy to see that 1 sec timeout is not needed, when device fails
to response longer timeout doesn't help:
[ 473.074419] zd1211rw 1-1:1.0: print_times() Read times:
[ 473.175163] zd1211rw 1-1:1.0: print_time() 0 - 10 msec: 1506
[ 473.176429] zd1211rw 1-1:1.0: print_time() 11 - 50 msec: 0
[ 473.177955] zd1211rw 1-1:1.0: print_time() 51 - 100 msec: 0
[ 473.180703] zd1211rw 1-1:1.0: print_time() 101 - 250 msec: 0
[ 473.182101] zd1211rw 1-1:1.0: print_time() 251 - 500 msec: 0
[ 473.183221] zd1211rw 1-1:1.0: print_time() 500 - 1000 msec: 20
[ 473.184381] zd1211rw 1-1:1.0: print_time() 1000 - ... msec: 18
Also vendor driver doesn't use this long timeout. Therefore change
timeout to 50msec.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As might lower beacon update CPU usage.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Use stack for allocing small < 64 byte arrays in zd_chip.c and preallocated
buffer in zd_usb.c. This might lower CPU usage for beacon setup.
v2:
- Do not use stack buffers in zd_usb.c as they would be used for urb
transfer_buffer.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Beacon config function writes beacon to hw one write per byte. This is very
slow (usually taking more than 100ms to finish) and causes high CPU usage
when in AP-mode (kworker at ~50% on Intel Atom N270). By batching commands
together zd_mac_config_beacon() runtime can be lowered to 1/5th and lower
CPU usage to saner levels (<10% on Atom).
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When doing tx/rx at high packet rate (for example simply using ping -f),
device starts to fail to respond to control messages. On non-AP modes
this only causes problems for LED updating code but when we are running
in AP-mode we are writing new beacon to HW usually every 100ms. Now if
control message fails in HW beacon setup, device lock is kept locked
and beacon data partially written. This can and usually does cause:
1. HW beacon setup fail now on, as driver cannot acquire device lock.
2. Beacon-done interrupt stop working as device has incomplete beacon.
Therefore make zd_mac_config_beacon() always try to release device lock
and add beacon watchdog to restart beaconing when stall is detected.
Also fix zd_mac_config_beacon() try acquiring device lock for max 500ms,
as what old code appeared to be trying to do using loop and msleep(1).
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On review of 'zd1211rw: implement beacon fetching and handling
ieee80211_get_buffered_bc()', Christian Lamparter noted that [1]:
Since zd_beacon_done also uploads the next beacon so long in advance,
there could be an equally long race between the outdated state of the
next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
which -in your case- was uploaded almost a beacon interval ago and
the xmit of ieee80211_get_buffered_bc *now*.
The dtim bc/mc bit might be not set, when a mc/bc arrived after the
beacon was uploaded, but before the "beacon done event" from the
hardware. So, dozing stations don't expect the broadcast traffic
and of course, they might miss it completely.
It's probably better to fix this in mac80211 (see the attached hack).
[1] http://marc.info/?l=linux-wireless&m=129435041117256&w=2
CC: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add support for AP-mode beacon. Also disable beacon when interface is set
down as otherwise hw will keep flooding NEXT_BCN interrupts.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For reasons not very clear yet to me, filter_ack leaves matching tx-packet
pending with 'ack_pending'. This causes tx-packet to be passed back to upper
layer after next packet has been transfered and tx-packets might end up
coming come out of monitor interface in wrong order vs. rx.
Because of this when enable AP-mode, hostapd monitor interface would get
packets in wrong order causing problems in WPA association.
So don't use mac->ack_pending when in AP-mode.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As bss_info_changed may sleep, we can as well set RTS_CTS register right away.
Keep mac->short_preamble for later use (hw reset).
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Workers not needed anymore since configure_filter may sleep. Keep
mac->multicast_hash for later use (hw reset).
Signed-off-by: Jussi Kivilinna <jussi.kivilina@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Vendor driver uses CR_BNC_INTERVAL at various places, one is HW_EnableBeacon()
that combinies beacon interval with BSS-type flag and DTIM value in upper 16bit
of u32. The other one is HW_UpdateBcnInterval() that set_aw_pt_bi()
appears to be based on. HW_UpdateBcnInterval() takes interval argument as u16
and uses that for calculations, set_aw_pt_bi() uses u32 value that has flags
and dtim in upper part. This clearly seems wrong. Also HW_UpdateBcnInterval()
updates only lower 16bit part of CR_BNC_INTERVAL. So make set_aw_pt_bi() do
calculations on only lower u16 part of s->beacon_interval.
Also set 32bit beacon interval register before reading values from device,
as HW_EnableBeacon() on vendor driver does. This is required to make beacon
work on AP-mode, simply reading and then writing updated values is not enough
at least with zd1211b.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johan Hedberg
Gustavo F. Padovan
Andrei Emeltchenko
Jesper Juhl
Dan Carpenter
Mohammed Shafi Shajakhan
Felix Fietkau
Ben Greear
Nick Kossifidis
Wey-Yi Guy
Johannes Berg
Jouni Malinen
Rajkumar Manoharan
Jussi Kivilinna
Christian Lamparter