IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Since drivers can support several BSS / P2P Client
interfaces, the rssi callback needs to inform the driver
about the interface teh rssi event relates to.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Depending on the driver, having ARP filtering for
some addresses may be possible. Remove the logic
that tracks whether ARP filter is enabled or not
and give the driver the total number of addresses
instead of the length of the list so it can make
its own decision.
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The initiator/tx doesn't really identify why an
aggregation session is stopped, give a reason
for stopping that more clearly identifies what's
going on. This will help tell the driver clearly
what is expected of it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In interoperability testing some APs showed bad behaviour
if some of the VHT capabilities of the station are better
than their own. Restrict the assoc request parameters
- beamformee capabable,
- RX STBC and
- RX MCS set
to the subset that the AP can support.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The probe response/beacon management frame RX code passes a
bool parameter to differentiate beacons and probe responses.
This is useless since we have the frame and can thus use its
frame control field. Moreover it is buggy since there is one
call to ieee80211_rx_bss_info with a beacon frame that is
indicated as a probe response, which is also fixed by using
the frame control field, so do that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The last fixes re-added the RCU synchronize penalty
on roaming to fix the races. Split up sta_info_flush()
now to get rid of that again, and let managed mode
(and only it) delay the actual destruction.
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When all interfaces have been removed, there can't
be any stations left over, so there's no need to
flush again. Remove this, and all code associated
with it, which also simplifies the function.
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When AP's SSID is hidden the BSS can appear several times in
cfg80211's BSS list: once with a zero-length SSID that comes
from the beacon, and once for each SSID from probe reponses.
Since the mac80211 stores its data in ieee80211_bss which
is embedded into cfg80211_bss, mac80211's data will be
duplicated too.
This becomes a problem when a driver needs the dtim_period
since this data exists only in the beacon's instance in
cfg80211 bss table which isn't the instance that is used
when associating.
Remove the DTIM period from the BSS table and track it
explicitly to avoid this problem.
Cc: stable@vger.kernel.org
Tested-by: Efi Tubul <efi.tubul@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If channel contexts are enabled, the CSA should not be processed
further. A return is missing here.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a BSS struct is updated, the IEs are currently
overwritten or freed. This can lead to races if some
other CPU is accessing the BSS struct and using the
IEs concurrently.
Fix this by always allocating the IEs in a new struct
that holds the data and length and protecting access
to this new struct with RCU.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Determine the VHT channel from the AP's VHT operation IE
(if present) and configure the hardware to that channel
if it is supported. If channel contexts cause a channel
to not be usable, try a smaller bandwidth.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Convert mac80211 (and where necessary, some drivers a
little bit) to the new channel definition struct.
This will allow extending mac80211 for VHT, which is
currently restricted to channel contexts since there
are no drivers using that which makes it easier. As
I also don't care about VHT for drivers not using the
channel context API, I won't convert the previous API
to VHT support.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If ieee80211_prep_channel() decides that HT should be
disabled (because the HT IEs from the AP were invalid)
it will set the IEEE80211_STA_DISABLE_HT to not send
HT capabilities to the AP when associating. If this
happens during authentication, the flag will be lost
and we send HT frames, even if the channel config was
set up for non-HT. This can lead to issues.
Fix this by always resetting the ifmgd flags to zero
when the channel context is released so that the flag
resetting in ieee80211_mgd_assoc() isn't necessary.
To make the code a bit easier move the call to release
the channel in ieee80211_set_disassoc() to the end of
the function together with the flag resetting (which
needs to be at the end to avoid timers setting flags.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the AP doesn't support HT, or more importantly if
it does but we have to disable it because its IEs are
broken, don't advertise HT support in our association
request. Otherwise, we configure our channel to be a
20 MHz non-HT channel but the AP might still think we
support HT, or even 40 MHz.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since the 11n spec amendment was rolled into the
2012 version, "11n" no longer makes sense. Use
"HT" instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the driver doesn't support 40 MHz channels, then
mac80211 erroneously sets number of RX chains to one
although the number of chains is independent of the
support for 40 MHz channels.
Fix this by checking the 40 MHz support only for the
code that sets the 40 MHz channel not the complete
HT code block.
This also means the HT20 channel type will always be
set in the changed code block so there's no need to
set it in case we override the AP due to invalid IEs
in the probe response/beacon.
The indentation is a bit quirky, but I'm rewriting
this code for VHT support so this will change again
very soon.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
While connected to a GO, parse the P2P NoA attribute
and pass the CT Window and opportunistic powersave
parameters to the driver.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When userspace asks to deauthenticate and we're just
authenticated (or still authenticating) send a deauth
frame instead of deleting the auth request.
On the other hand, if we've just disassociated and
therefore deleted all our state already, drop the
deauth request because we no longer have a channel
context to send it on.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Even before channel contexts/multi-channel, having a
single global TX power limit was already problematic,
in particular if two managed interfaces connected to
two APs with different power constraints. The channel
context introduction completely broke this though and
in fact I had disabled TX power configuration there
for drivers using channel contexts.
Change everything to track TX power per interface so
that different user settings and different channel
maxima are treated correctly. Also continue tracking
the global TX power though for compatibility with
applications that attempt to configure the wiphy's
TX power globally.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove a duplicate check in ieee80211_rx_mgmt_beacon,
there is no need to make again the same check for the
IEEE80211_HW_PS_NULLFUNC_STACK twice; the two ifs can
be consolidated.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[reword commit message & break long lines and also
clean up variable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a number of unused variables that gcc
pointed out (when building with W=1) as well as
some conditions that can never be true due to
the datatypes used: unsigned values can't be
less than zero. Remove this code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some changes to fix issues with HT40 APs in Korea
and follow-up changes to allow using HT40 even if
the local regulatory database disallows it caused
issues with iwlwifi (and could cause issues with
other devices); iwlwifi firmware would assert if
you tried to connect to an AP that has an invalid
configuration (e.g. using HT40- on channel 140.)
Fix this, while avoiding the "Korean AP" issue by
disabling HT40 and advertising HT20 to the AP
when connecting.
Cc: stable@vger.kernel.org [3.6]
Reported-by: Florian Reitmeir <florian@reitmeir.org>
Tested-by: Florian Reitmeir <florian@reitmeir.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Save the AP's VHT capabilities (in managed
mode) and make them available to the driver
in the station information.
Unlike HT capabilities, they aren't restricted
to the common capabilities, so drivers must be
aware of their own capabilities.
Signed-off-by: Mahesh Palivela <maheshp@posedge.com>
[fix endian conversion bug ...]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Rename struct ieee80211_vht_capabilities to ieee80211_vht_cap
and renamed its member vht_capabilities_info to vht_cap_info.
Signed-off-by: Mahesh Palivela <maheshp@posedge.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
SAE uses two rounds of Authentication frames and both rounds require
considerable calculation to be done. This commit extends the existing
station mode authentication request to allow more control for user
space programs to build the SAE fields and to run the authentication
step ones. Only the second round with authentication transaction
sequence 2 will result in moving to authenticated state.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is useful when debugging authentication process issues.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Non-zero status code may be needed for Authentication frames, e.g.,
when using SAE.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On each channel that the device is operating on, it
may need to listen using one or more chains depending
on the SMPS settings of the interfaces using it. The
previous channel context changes completely removed
this ability (before, it was available as the SMPS
mode).
Add per-context tracking of the required static and
dynamic RX chains and notify the driver on changes.
To achieve this, track the chains and SMPS mode used
on each virtual interface and update the channel
context whenever this changes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of operating on a single channel only,
use the new channel context infrastructure in
all mac80211 code.
This enables drivers that want to use the new
channel context infrastructure to use multiple
channels, while nothing should change for all
the other drivers that don't support it.
Right now this disables both TX power settings
and spatial multiplexing powersave. Both need
to be re-enabled on a channel context basis.
Additionally, when channel contexts are used
drop the connection when channel switch is
received rather than trying to handle it. This
will have to be improved later.
[With fixes from Eliad and Emmanuel incorporated]
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Avoid situation when we are on associate state in mac80211 and
on disassociate state in cfg80211. This can results on crash
during modules unload (like showed on this thread:
http://marc.info/?t=134373976300001&r=1&w=2) and possibly other
problems.
Reported-by: Pedro Francisco <pedrogfrancisco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When we disassociate, it's not really useful to
send delBA action frames since we're going to send
disassoc/deauth anyway, so change that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, mac80211 uses the power constraint IE, and reduces
the regulatory max TX power by it. This can cause issues if
the AP is advertising a large power constraint value matching
a high TX power in its country IE, for example in this case:
...
Country: US Environment: Indoor/Outdoor
...
Channels [157 - 157] @ 30 dBm
...
Power constraint: 13 dB
...
What happened here is that our local regulatory TX power is
15 dBm, and gets reduced by 13 dB so we end up with only
2 dBm effective TX power, which is way too low.
Instead, handle the country IE/power constraint IE combined
and restrict our TX power to the max of the regulatory power
and the maximum power advertised by the AP, in this case
17 dBm (= 30 dBm - 13 dB).
Also print a message when this happens to let the user know
and help us debug issues with it.
Reported-by: Carl A. Cook <CACook@quantum-equities.com>
Tested-by: Carl A. Cook <CACook@quantum-equities.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move ieee80211_send_deauth_disassoc() to util.c to make it
available for the rest of the mac80211 code.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
[reword commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The power constraint IE is always a single byte
so check the size when parsing instead of later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Disconnect from the AP if channel switching in the
driver failed or if the new channel is unavailable.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Pull in mac80211.git to let the next patch apply
without conflicts, also resolving a hwsim conflict.
Conflicts:
drivers/net/wireless/mac80211_hwsim.c
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ifmgd->bssid wasn't cleared properly in some
auth/assoc failure cases, causing mac80211 and
the low-level driver to go out of sync.
Clear ifmgd->bssid on failure, and notify the driver.
Cc: stable@kernel.org # 3.4+
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In multi-channel scenarios, the channel that we will
transmit a probe request on isn't always the current
channel (which will be NULL anyway) but will instead
be the channel that the AP is on. Pass the channel
to the ieee80211_send_probe_req() function so it can
be used in the different scenarios. The scan code
continues to pass the current channel, of course.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to declare the function in the
header file since it's only used in a single
place, so make it static.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The channel switch IE has a fixed size, so we can
discard it in parsing if it's not the right size
and use the right struct pointer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The time until the channel switch is in TU,
not in milliseconds, so use TU_TO_EXP_TIME()
to correctly program the timer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Clean up the CSA handling code by moving some
of it out of the if and using a C99 initializer
for the struct passed to the driver method.
While at it, also add a comment that we should
wait for a beacon after switching the channel.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's a corner case that can happen when we
suspend with a timer running, then resume and
disconnect. If we connect again, suspend and
resume we might start timers that shouldn't be
running. Reset the timer flags to avoid this.
This affects both mesh and managed modes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When associating anew, the old station MLME flags should
be cleared. The only exception is the 40 MHz disable
flag as it might have been set while the channel was set
in a previous authentication attempt so it needs to be
kept intact.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When sending probe requests, e.g. during software scanning,
these will go out on the *current* channel, so their IEs
need to be built from the current channel. At other times,
e.g. for beacons or probe request templates, the IEs will
be used on the *operating* channel and using the current
channel instead might result in errors.
Add the appropriate parameters to respect the difference.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Using hw.conf.channel is wrong as it could be the
temporary channel if any function like the beacon
get function is called while scanning or during
other temporary out-of-channel activities.
Use oper_channel instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need to set up the channel during auth
and again during assoc, just do it once. Currently
this doesn't result in any changes since calling
hw_config() with an unchanged channel will return
early, but with the channel context work this has
an impact on channel context assignment.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In ieee80211_prep_connection(), the station (if not NULL)
is the new station (representing the AP) that needs to be
added. Rename the variable to "new_sta" to clarify this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If HT/VHT isn't supported by us we shouldn't print
a message that we disabled it, do that only if the
AP didn't support WMM and we therefore disable it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, ps mode is indicated per device (rather than
per interface), which doesn't make a lot of sense.
Moreover, there are subtle bugs caused by the inability
to indicate ps change along with other changes
(e.g. when the AP deauth us, we'd like to indicate
CHANGED_PS | CHANGED_ASSOC, as changing PS before
notifying about disassociation will result in null-packets
being sent (if IEEE80211_HW_SUPPORTS_DYNAMIC_PS) while
the sta is already disconnected.)
Keep the current per-device notifications, and add
parallel per-vif notifications.
In order to keep it simple, the per-device ps and
the per-vif ps are orthogonal - the per-vif ps
configuration is determined only by the user
configuration (enable/disable) and the connection
state, and is not affected by other vifs state and
(temporary) dynamic_ps/offchannel operations
(unlike per-device ps).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This doesn't make any sense since we are expected to be on
the medium or at least to Tx only when we are on the right
channel and the AP/GO can hear us.
Move the call to mgd_prepare_tx() for deauth to be only
done in case we're sending a deauth while not associated.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the HW is monitoring connection loss (as advertised
by IEEE80211_HW_CONNECTION_MONITOR) but not filtering
beacons (IEEE80211_VIF_BEACON_FILTER) then mac80211 will
still start the beacon loss timer and if a few beacons
are lost, e.g. due to scanning, drop the connection.
If the hardware doesn't advertise connection monitoring,
then it won't drop the connection right away but probe
the AP, which is intended, but due to the logic in the
timer when connection monitoring is done it assumes the
connection was actually lost.
Fix this problem by not starting the timer when the HW
does connection monitoring.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Insert VHT IEs into association frames to allow
mac80211 to connect as a VHT client.
Signed-off-by: Mahesh Palivela <maheshp@posedge.com>
[clarify commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
on disassoc, ieee80211_set_disassoc() goes out of PS
before indicating BSS_CHANGED_ASSOC (not sure why this
is needed, but some drivers might count on the current
behavior).
However, it does it after sending the disassoc
frame, which results in null-data frame being sent
(in order to go out of ps) after we were already sent
the disassoc, which is invalid.
Fix it by going out of ps before sending the disassoc.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some drivers (iwlegacy, iwlwifi and rt2x00) today use the
bss_conf.last_tsf value. By itself though that value is
completely worthless since it may be ancient. What really
is needed is synchronisation between some device time and
the TSF.
To clarify this, rename bss_conf.last_tsf to sync_tsf and
add sync_device_ts which is obtained from rx_status which
gets a new field device_timestamp for this purpose. This
is intentionally not using the mactime field since that
is used for other things and in IBSS is expected to sync
with the IBSS's TSF which isn't necessarily true for the
device timestamp.
Also, since we have the information and it's useful even
before the connection has been established, give all the
timing details to the driver before authenticating.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If association failed due to internal error (e.g. no
supported rates IE), we call ieee80211_destroy_assoc_data()
with assoc=true, while we actually reject the association.
This results in the BSSID not being zeroed out.
After passing assoc=false, we no longer have to call
sta_info_destroy_addr() explicitly. While on it, move
the "associated" message after the assoc_success check.
Cc: stable@vger.kernel.org [3.4+]
Signed-off-by: Eliad Peller <eliad@wizery.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_mlme_notify_scan_completed() iterates all
interfaces and doesn't need to assign anything to
the sdata variable before the loop.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the AC parameters change, drivers might rely
on getting a bss_info_changed notification with
BSS_CHANGED_QOS in addition to the conf_tx call.
Always call the function when userspace updates
are made (in AP/GO modes) and also set the change
flag when updates were made by the AP (in managed
mode.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some drivers require setup before being able to send
management frames in managed mode, in particular in
multi-channel cases.
Introduce API to allow the drivers to do such setup
while being able to sleep waiting for the setup to
finish in the device. This isn't possible inside the
TX call since that can't sleep.
A future patch may also restructure the TX retry to
wait for the driver to report the frame status, as
suggested by Arik in
http://mid.gmane.org/CA+XVXffKSEL6ZQPQ98x-zO-NL2=TNF1uN==mprRyUmAaRn254g@mail.gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Drivers might need getting the probe request
(e.g. in order to extract the ssid) even during
auth/assoc.
Make ieee80211_ap_probereq_get() support it
by considering auth_data/assoc_data as well.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
beacon_ies is needed only in order to extract the dtim
period. However, even if it's missing we can still enter
ps with dtim=1 (which also happens if the TIM ie is invalid).
Most drivers don't use conf.max_sleep_period/ps_dtim_period
anyway, and this check prevents them from entering ps if
they don't have beacon (but only probe response), even though
the beacon is not needed at all.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
On deauth/disassoc we tear down all BA sessions. These
DELBA packets are sent on the appropriate TID, while
deauth/disassoc is always sent on VO. This sometimes
ends with the DELBA being sent after the deauth was
already sent.
Fix it by flushing all the pending frames before
sending deauth/disassoc.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are a few things that make the logging and
debugging in mac80211 less useful than it should
be right now:
* a lot of messages should be pr_info, not pr_debug
* wholesale use of pr_debug makes it require *both*
Kconfig and dynamic configuration
* there are still a lot of ifdefs
* the style is very inconsistent, sometimes the
sdata->name is printed in front
Clean up everything, introducing new macros and
separating out the station MLME debugging into
a new Kconfig symbol.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ieee80211_set_disassoc() clears ifmgd->bssid before
building DELBA frames, resulting in frames with invalid
bssid ("00:00:00:00:00:00").
Fix it by clearing ifmgd->bssid only after building
all the needed frames.
After this change, we no longer need to save the
bssid (before clearing it), so remove the local array.
Reported-by: Ido Yariv <ido@wizery.com>
Cc: stable@vger.kernel.org
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Save and configure the wmm_acm per sdata, rather than
per hardware.
If wmm_acm is saved per hardware when running two
interfaces simultaneously on the same hardware one
interface's wmm policy will be affected by the other
interface.
Signed-off-by: Yoni Divinsky <yoni.divinsky@ti.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If an AP is beaconing with different capabilities than the one we get
in the associate response, we were still using the capabilities
received in the beacons. One example is when the AP is beaconing with
the short slot bit set to zero and then we try to connect to it with
long slot. In this case, we would keep using long slot until the next
beacon was received.
Fix this by using the correct capability value when calling
ieee80211_handle_bss_capability(). We were using cbss->capability,
but we should use the bss_conf->assoc_capability instead.
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some compilers (eg. gcc 4.4.1 for ARM) report a false positive warning
in mlme.c:
net/mac80211/mlme.c: In function 'ieee80211_prep_connection':
net/mac80211/mlme.c:3035: warning: 'sta' may be used uninitialized in this function
This is a false positive because the place where 'sta' is used is
inside an if with the same condition of where it is set:
[...]
if (!have_sta) {
sta = sta_info_alloc(sdata, cbss->bssid, GFP_KERNEL);
if (!sta)
return -ENOMEM;
}
[...]
if (!have_sta) {
[...]
sta->sta.supp_rates[cbss->channel->band] = rates;
[...]
For some reason the compiler doesn't understand this and warns.
While this is not a problem in the code itself, we can avoid polluting
the build logs with false positives by setting sta to NULL on
declaration and checking for sta instead of !have_sta in the second if.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Stop connection monitor poll during disassociation.
This clears the polling flags and if a scan was
deferred it will be run.
Without this fix, if a scan was deferred due to
connection monitoring while disassociation happens,
this scan blocks further scan requests until interface
down/up which causes problems connecting to another AP.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
commit 24398e39c8
Author: Johannes Berg <johannes.berg@intel.com>
Date: Wed Mar 28 10:58:36 2012 +0200
mac80211: set HT channel before association
removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config,
which is required by iwl4965 driver, otherwise that driver does not
configure channel properly and is not able to associate.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The IDLE handling in HW off-channel is broken right
now since we turn off IDLE only when the off-channel
period already started. Therefore, all drivers that
use it today (only iwlwifi!) must support off-channel
while idle, so playing with idle isn't needed at all.
Off-channel in general, since it's no longer used for
authentication/association, shouldn't affect PS, so
also remove that logic.
Also document a small caveat for reporting TX status
from off-channel frames in HW remain-on-channel.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make mac80211 print a message when it disables
HT due to the connection using WEP/TKIP or due
to the AP not supporting WMM/QoS.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Instead of passing around the entire HT information
IE, extract only the HT parameters field and disable
HT if the HT information IE isn't present and well-
formed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_get_operstate() was used by drivers in order to
know whether the sta link is up, but it's no longer needed
(nor used) as mac80211 notifies the drivers about
authorization changes (via the sta_state callback)
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Standardize the debugging to be able to use dynamic_debug.
Coalesce formats, align arguments.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Send beacon loss events to userspace, so it will be
able to initiate roaming before disconnection
Signed-off-by: Holger Schurig <holgerschurig@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ieee80211_rx_mgmt_auth() doesn't handle denied authentication
properly - it authenticates the station and waits for association
(for 5 seconds) instead of failing the authentication.
Fix it by destroying auth_data and bailing out instead.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@vger.kernel.org #3.4
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 133d40f9a2
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Wed Mar 28 16:01:19 2012 +0200
mac80211: do not scan and monitor connection in parallel
add bug, which make possible to start a scan and never finish it, so
make every new scanning request finish with -EBUSY error. This can
happen on code paths where we finish connection monitoring and clear
IEEE80211_STA_*_POLL flags, but do not check if scan was deferred.
This patch fixes those code paths.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 tries to verify the existence of the current AP by
probing or sending a NULL frame in function
ieee80211_mgd_probe_ap_send. It 1st sends a null frame to the AP,
increments probe_send_count and waits for the ACK to the NULL
frame for a finite duration of time. At times, it happens that by
the time mac80211 gets to increment probe_send_count, the ACK for
the NULL frame transmitted has already been processed. This leads
to a race condition where mac80211 times out waiting for the ACK
for the NULL frame causing unnecessary disconnection with the AP.
Signed-off-by: Soumik Das <soumik.das@stericsson.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Standardize the net core ratelimited logging functions.
Coalesce formats, align arguments.
Change a printk then vprintk sequence to use printf extension %pV.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The rate control updation never be called on 2040 BSS change.
The station should update its rate control on receiving beacon
with different HT mode in the HT operation IE. Not doing so,
leads to sending frames with higher(ht40) rates whereas AP is
operating in lower mode (ht20).
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Conflicts:
drivers/net/ethernet/intel/e1000e/param.c
drivers/net/wireless/iwlwifi/iwl-agn-rx.c
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
drivers/net/wireless/iwlwifi/iwl-trans.h
Resolved the iwlwifi conflict with mainline using 3-way diff posted
by John Linville and Stephen Rothwell. In 'net' we added a bug
fix to make iwlwifi report a more accurate skb->truesize but this
conflicted with RX path changes that happened meanwhile in net-next.
In e1000e a conflict arose in the validation code for settings of
adapter->itr. 'net-next' had more sophisticated logic so that
logic was used.
Signed-off-by: David S. Miller <davem@davemloft.net>
