linux-toradex.git/net/mac80211/mlme.c, branch v2.6.31.4

mac80211: do not queue work after suspend in the dynamic ps timer

2009-07-27T19:19:38+00:00

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

mac80211: fix wext bssid/ssid setting

2009-06-15T19:05:59+00:00

When changing to a new BSSID or SSID, the code in
ieee80211_set_disassoc() needs to have the old data
still valid to be able to disconnect and clean up
properly. Currently, however, the old data is thrown
away before ieee80211_set_disassoc() is ever called,
so fix that by calling the function _before_ the old
data is overwritten.

This is (one of) the issue(s) causing mac80211 to hold
cfg80211's BSS structs forever, and them thus being
returned in scan results after they're long gone.

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2015

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: disconnect when user changes channel

2009-06-15T19:05:58+00:00

If we do not disconnect when a channel switch is requested,
we end up eventually detection beacon loss from the AP and
then disconnecting, without ever really telling the AP, so
we might just as well disconnect right away.

Additionally, this fixes a problem with iwlwifi where the
driver will clear some internal state on channel changes
like this and then get confused when we actually go clear
that state from mac80211.

It may look like this patch drops the no-IBSS check, but
that is already handled by cfg80211 in the wext handler it
provides for IBSS (cfg80211_ibss_wext_siwfreq).

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: Do not try to associate with an empty SSID

2009-06-15T19:05:51+00:00

It looks like some programs (e.g., NM) are setting an empty SSID with
SIOCSIWESSID in some cases. This seems to trigger mac80211 to try to
associate with an invalid configuration (wildcard SSID) which will
result in failing associations (or odd issues, potentially including
kernel panic with some drivers) if the AP were to actually accept this
anyway).

Only start association process if the SSID is actually set. This
speeds up connection with NM in number of cases and avoids sending out
broken association request frames.

Signed-off-by: Jouni Malinen 
Signed-off-by: John W. Linville

mac80211: disable PS while probing AP

2009-06-10T17:28:41+00:00

When associated, but probing the AP because we detected
beacon loss, we need to disable powersave to be able to
receive the probe response. Change the code to do that by
checking whether we're trying to probe when determining
the possibility of going into PS, and recalculate the PS
ability at the necessary spots.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: disable moving between PS modes during scan

2009-06-10T17:28:40+00:00

We don't want to trigger moving between PS mode during scan,
because then we will sometimes end up sending nullfunc frames
during scan. We're supposed to only send one prior to scan
and after scan.

This fixes an oops which occured due to an assert in ath9k:

http://marc.info/?l=linux-wireless&m=124277331319024

The assert was happening because the rate control algorithm
figures it should find at least one valid dual stream or
single stream rate. Since we allow mac80211 to send nullfunc
frames during scan and dynamic PS was enabled at times we ended
up trying to send nullfunc frames for the target sta on the
wrong band for which we have no valid rate to communicate with
it. This breaks the assumptions in rate control.

We determine we also need to disable moving between PS modes
when not associated so lets just add that now as well, and we
should not have a ps_sdata when that interface cannot actually
go into PS because it's not associated.

Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: don't use master netdev name

2009-06-10T17:28:39+00:00

Always use the wiphy name instead.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: correct probe wait time

2009-05-22T18:06:01+00:00

My first patch submission used 200ms, which I then somehow
managed to revert back to the earlier 50ms I had used for
some tests in the second patch submission -- but that was
wrong, I should have used 200ms here. Correct that.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: fix probe response wait timing

2009-05-22T18:05:59+00:00

In "mac80211: split out and decrease probe wait time" I tried
to reduce the time waiting for a probe response, but failed to
take into account the case where we are detecting beacon loss
in software -- in that case we still wait the monitoring time
rather than the probe wait time. Fix this by refactoring the
mod_timer() calls in ieee80211_associated().

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

mac80211: fix managed mode BSSID handling

2009-05-20T18:46:37+00:00

Currently, we will ask the driver to configure right away
when somebody changes the desired BSSID. That's totally
strange because then we will configure the driver without
even knowing whether the BSS exists. Change this to only
configure the BSSID when associated, and configure a zero
BSSID when not associated.

As a side effect, this fixes an issue with the iwlwifi
driver which doesn't implement sta_notify properly and
uses the BSSID instead and gets very confused if the
BSSID is cleared before we disassociate, which results
in the warning Marcel posted [1] and iwlwifi bug 1995 [2].

[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/32598
[2] http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1995

Cc: Marcel Holtmann 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville