* [RTL8723AE] Driver problems
From: André Martins @ 2013-10-18 0:55 UTC (permalink / raw)
To: linux-wireless
Hi!
This is a copy I've sent to Larry Finger and his bot told me to sent to
this e-mail address instead.
Basically I've bought a computer with the 8723ae card and unfortunately the
wireless connection is really bad. Although I'm a last year student on
MSc in
computers and telematics engineering I don't have any skills what so
ever on
kernel's source code. Thus, I want to ask you if you could help me out
and tell
me where to begin to fix this and create a great rtl8723ae driver for
Linux. I
could help you with the tests what whatever I could. The main problem
with this
card is the connection on my university, it's always dropping and
impossible to
have a stable connection. On my house I'm a few meters way of my AP and
the link
quality is either on 38/70 or 70/70.
Since you take the time to read this e-mail I thank you already.
Thanks,
André Martins
^ permalink raw reply
* Re: pull request: wireless-next 2013-10-17
From: David Miller @ 2013-10-17 20:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20131017182339.GC1812@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 17 Oct 2013 14:23:40 -0400
> This is a batch of updates intended for the 3.13 stream...
>
> The biggest item of interest in here is wcn36xx, the new mac80211
> driver for Qualcomm WCN3660/WCN3680 hardware.
>
> Regarding the mac80211 bits, Johannes says:
>
> "We have an assortment of cleanups and new features, of which the
> biggest one is probably the channel-switch support in IBSS. Nothing
> else really stands out much."
>
> On top of that, the ath9k and rt2x00 get a lot of update action from
> Felix Fietkau and Gabor Juhos, respectively. There are a handful of
> updates to other drivers here and there as well.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: pull request: wireless 2013-10-15
From: David Miller @ 2013-10-17 20:06 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20131015175611.GA15706@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 15 Oct 2013 13:56:12 -0400
> Please pull this batch of fixes intended for the 3.12 stream!
>
> For the mac80211 bits, Johannes says:
>
> "Jouni fixes a remain-on-channel vs. scan bug, and Felix fixes client TX
> probing on VLANs."
>
> And also:
>
> "This time I have two fixes from Emmanuel for RF-kill issues, and fixed
> two issues reported by Evan Huus and Thomas Lindroth respectively."
>
> On top of those...
>
> Avinash Patil adds a couple of mwifiex fixes to properly inform cfg80211
> about some different types of disconnects, avoiding WARNINGs.
>
> Mark Cave-Ayland corrects a pointer arithmetic problem in rtlwifi,
> avoiding incorrect automatic gain calculations.
>
> Solomon Peachy sends a cw1200 fix for locking around calls to
> cw1200_irq_handler, addressing "lost interrupt" problems.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* Centrino Wireless-N 2200 authentication time-outs and unexpected deauthentication
From: Kenneth Berland @ 2013-10-17 18:23 UTC (permalink / raw)
To: linux-wireless, ilw
All,
I'm having a hard time keeping a connection to a Ruckus ZoneFlex 7982 AP.
The SSID is running WPA2/PSK/AES. I'm running a recent iwlwifi kernel
(3.12.0-rc3-wl+) and have a Centrino chipset. After an hour or so, the
interface is disconnected. It can only reauthenticate when the iwlwifi
module is removed and re-inserted.
Thanks in advance,
Ken
I'm running a recent wpa_supplicant with nl80211 like this:
/sbin/wpa_supplicant -Dnl80211 -s -i wlan0 -c ./gr-test.conf
The relevant log output is the following (I think):
Oct 17 10:39:26 ken-x230 wpa_supplicant[15828]: Successfully initialized wpa_supplicant
Oct 17 10:39:26 ken-x230 kernel: [19456.093074] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
Oct 17 10:39:26 ken-x230 kernel: [19456.100991] iwlwifi 0000:03:00.0: Radio type=0x2-0x0-0x0
Oct 17 10:39:26 ken-x230 kernel: [19456.173751] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 17 10:39:27 ken-x230 wpa_supplicant[15828]: wlan0: SME: Trying to authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
Oct 17 10:39:27 ken-x230 kernel: [19456.930480] wlan0: authenticate with 2c:e6:cc:84:8d:98
Oct 17 10:39:27 ken-x230 kernel: [19456.935141] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 1/3)
Oct 17 10:39:28 ken-x230 kernel: [19458.156795] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 2/3)
Oct 17 10:39:29 ken-x230 kernel: [19459.169462] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 3/3)
Oct 17 10:39:30 ken-x230 kernel: [19460.170078] wlan0: authentication with 2c:e6:cc:84:8d:98 timed out
Oct 17 10:39:31 ken-x230 wpa_supplicant[15828]: wlan0: SME: Trying to authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
Oct 17 10:39:31 ken-x230 kernel: [19460.932095] wlan0: authenticate with 2c:e6:cc:84:8d:98
Oct 17 10:39:31 ken-x230 kernel: [19460.935224] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 1/3)
Oct 17 10:39:32 ken-x230 kernel: [19462.159432] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 2/3)
Oct 17 10:39:33 ken-x230 kernel: [19463.148066] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 3/3)
Oct 17 10:39:34 ken-x230 kernel: [19464.148711] wlan0: authentication with 2c:e6:cc:84:8d:98 timed out
Oct 17 10:39:35 ken-x230 wpa_supplicant[15828]: wlan0: SME: Trying to authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
Oct 17 10:39:35 ken-x230 kernel: [19465.307056] wlan0: authenticate with 2c:e6:cc:84:8d:98
Oct 17 10:39:35 ken-x230 kernel: [19465.311719] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 1/3)
Oct 17 10:39:36 ken-x230 kernel: [19466.162056] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 2/3)
Oct 17 10:39:37 ken-x230 kernel: [19467.162688] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 3/3)
Oct 17 10:39:38 ken-x230 kernel: [19468.139372] wlan0: authentication with 2c:e6:cc:84:8d:98 timed out
or, sometimes, like this:
Oct 16 18:35:20 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-CONNECTED - Connection to 2c:e6:cc:84:8d:98 completed [id=0 id_str=]
Oct 16 18:35:22 ken-x230 kernel: [ 5141.751420] wlan0: deauthenticated from 2c:e6:cc:84:8d:98 (Reason: 6)
Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-DISCONNECTED bssid=2c:e6:cc:84:8d:98 reason=6
Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: SME: Trying to authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
Oct 16 18:35:22 ken-x230 kernel: [ 5141.806347] wlan0: authenticate with 2c:e6:cc:84:8d:98
Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: Trying to associate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
Oct 16 18:35:22 ken-x230 kernel: [ 5141.810436] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 1/3)
Oct 16 18:35:22 ken-x230 kernel: [ 5141.812469] wlan0: authenticated
Oct 16 18:35:22 ken-x230 kernel: [ 5141.813760] wlan0: associate with 2c:e6:cc:84:8d:98 (try 1/3)
Oct 16 18:35:22 ken-x230 kernel: [ 5141.817635] wlan0: RX AssocResp from 2c:e6:cc:84:8d:98 (capab=0x431 status=0 aid=3)
Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: Associated with 2c:e6:cc:84:8d:98
Oct 16 18:35:22 ken-x230 kernel: [ 5141.836654] wlan0: associated
Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: WPA: Key negotiation completed with 2c:e6:cc:84:8d:98 [PTK=CCMP GTK=CCMP]
Oct 16 18:35:22 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-CONNECTED - Connection to 2c:e6:cc:84:8d:98 completed [id=0 id_str=]
Oct 16 18:35:25 ken-x230 kernel: [ 5144.220601] wlan0: deauthenticated from 2c:e6:cc:84:8d:98 (Reason: 6)
Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-DISCONNECTED bssid=2c:e6:cc:84:8d:98 reason=6
Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: SME: Trying to authenticate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
Oct 16 18:35:25 ken-x230 kernel: [ 5144.263904] wlan0: authenticate with 2c:e6:cc:84:8d:98
Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: Trying to associate with 2c:e6:cc:84:8d:98 (SSID='GR-Test' freq=2457 MHz)
Oct 16 18:35:25 ken-x230 kernel: [ 5144.268060] wlan0: send auth to 2c:e6:cc:84:8d:98 (try 1/3)
Oct 16 18:35:25 ken-x230 kernel: [ 5144.269809] wlan0: authenticated
Oct 16 18:35:25 ken-x230 kernel: [ 5144.271371] wlan0: associate with 2c:e6:cc:84:8d:98 (try 1/3)
Oct 16 18:35:25 ken-x230 kernel: [ 5144.275280] wlan0: RX AssocResp from 2c:e6:cc:84:8d:98 (capab=0x431 status=0 aid=3)
Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: Associated with 2c:e6:cc:84:8d:98
Oct 16 18:35:25 ken-x230 kernel: [ 5144.294692] wlan0: associated
Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: WPA: Key negotiation completed with 2c:e6:cc:84:8d:98 [PTK=CCMP GTK=CCMP]
Oct 16 18:35:25 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-CONNECTED - Connection to 2c:e6:cc:84:8d:98 completed [id=0 id_str=]
Oct 16 18:35:26 ken-x230 kernel: [ 5145.809824] wlan0: deauthenticated from 2c:e6:cc:84:8d:98 (Reason: 6)
Oct 16 18:35:26 ken-x230 wpa_supplicant[5490]: wlan0: CTRL-EVENT-DISCONNECTED bssid=2c:e6:cc:84:8d:98 reason=6
Here is the other, I hope relevant, info:
$ uname -a
Linux ken-x230 3.12.0-rc3-wl+ #1 SMP Tue Oct 8 11:47:43 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux # git-sha 1f117d
# wpa_supplicant version:
$ git remote -v | head -1
origin git://w1.fi/srv/git/hostap.git (fetch)
$ git log --decorate | head -1
commit 5bfd7e91685e65977c8db72afdca0cab310f8667 (HEAD, origin/master, origin/HEAD, master)
$ lspci -v # edited
03:00.0 Network controller: Intel Corporation Centrino Wireless-N 2200 (rev c4)
Subsystem: Intel Corporation Centrino Wireless-N 2200 BGN
Flags: bus master, fast devsel, latency 0, IRQ 46
Memory at f1c00000 (64-bit, non-prefetchable) [size=8K]
Capabilities: <access denied>
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
$ iw dev wlan0 info # before it locks up
Interface wlan0
ifindex 14
type managed
wiphy 0
$ iw dev wlan0 link #again, before it locks up
Connected to 2c:e6:cc:84:8d:98 (on wlan0)
SSID: GR-Test
freq: 2457
RX: 14757340 bytes (45075 packets)
TX: 2596610 bytes (8879 packets)
signal: -37 dBm
tx bitrate: 130.0 MBit/s MCS 14 short GI
bss flags: short-preamble short-slot-time
dtim period: 0
beacon int: 100
$ iw list
Wiphy phy0
Band 1:
Capabilities: 0x1072
HT20/HT40
Static SM Power Save
RX Greenfield
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 4 usec (0x05)
HT TX/RX MCS rate indexes supported: 0-15, 32
Frequencies:
* 2412 MHz [1] (15.0 dBm)
* 2417 MHz [2] (15.0 dBm)
* 2422 MHz [3] (15.0 dBm)
* 2427 MHz [4] (15.0 dBm)
* 2432 MHz [5] (15.0 dBm)
* 2437 MHz [6] (15.0 dBm)
* 2442 MHz [7] (15.0 dBm)
* 2447 MHz [8] (15.0 dBm)
* 2452 MHz [9] (15.0 dBm)
* 2457 MHz [10] (16.0 dBm)
* 2462 MHz [11] (15.0 dBm)
* 2467 MHz [12] (15.0 dBm) (passive scanning, no IBSS)
* 2472 MHz [13] (15.0 dBm) (passive scanning, no IBSS)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 20
max scan IEs length: 195 bytes
Coverage class: 0 (up to 0m)
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
software interface modes (can always be added):
* AP/VLAN
* monitor
valid interface combinations:
* #{ managed } <= 1, #{ AP } <= 1,
total <= 2, #channels <= 1, STA/AP BI must match
* #{ managed } <= 2,
total <= 2, #channels <= 1
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* new_mpath
* set_mesh_params
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* join_mesh
* set_tx_bitrate_mask
* action
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* Unknown command (84)
* Unknown command (87)
* Unknown command (85)
* Unknown command (89)
* Unknown command (92)
* testmode
* connect
* disconnect
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* Unknown mode (10): 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* Unknown mode (10): 0x40 0xd0
Device supports RSN-IBSS.
WoWLAN support:
* wake up on disconnect
* wake up on magic packet
* wake up on pattern match, up to 20 patterns of 16-128 bytes
* can do GTK rekeying
* wake up on GTK rekey failure
* wake up on EAP identity request
* wake up on rfkill release
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
$ lsmod | grep iwlwifi
iwlwifi 165203 1 iwldvm
cfg80211 494159 3 iwldvm,mac80211,iwlwifi
^ permalink raw reply
* RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Chauhan, Rajesh @ 2013-10-17 19:51 UTC (permalink / raw)
To: Dan Williams
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Rodriguez, Luis,
Malinen, Jouni, Bahini, Henri, Chang, Leo, Luo, Xun,
Chauhan, Rajesh
In-Reply-To: <1382035171.22901.13.camel@dcbw.foobar.com>
SGkgRGFuLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoNCkN1cnJlbnQgcGF0Y2ggaXMg
dG8gcmVwb3J0IGV2ZW50IGFzeW5jaHJvbm91c2x5IGFuZCB0aGF0IHdvdWxkIGJlIG5lZWRlZCBl
dmVuIGlmIHdlIGhhdmUgeW91ciBzdWdnZXN0ZWQgaW50ZXJmYWNlIG9mIGNsaWVudCBjb2xsZWN0
aW5nIHRoYXQgaW5mb3JtYXRpb24gdXBmcm9udCwgd2hpY2ggc2VlbXMgbGlrZSB5b3UgYWxzbyBr
aW5kIG9mIGFncmVlLCBiZWNhdXNlIFJGIGVudmlyb25tZW50IG1heSBjaGFuZ2UgbGF0ZXIgYW5k
IGdlbmVyYXRpbmcgYW4gZXZlbnQgYXQgdGhhdCB0aW1lIHdpdGggZnJlcXVlbmN5IGRldGFpbHMg
d291bGQgaGVscC4gU28geW91ciBzdWdnZXN0ZWQgYXBwcm9hY2ggb2YgIm1lY2hhbmlzbSBmb3Ig
dGhlIGNsaWVudCB0byBnZXQgdGhpcyBpbmZvcm1hdGlvbiIgaW4gaXRzZWxmIHNlZW1zIGxpa2Ug
YSBjYW5kaWRhdGUgZm9yIGEgc2VwYXJhdGUgcGF0Y2guDQoNCk9uIHRoZSByYWNlIGNvbmRpdGlv
biB3aGljaCB5b3UgZGVzY3JpYmVkIC0gdGhhbmtzISwgYnV0IGl0IGlzIHNvbWV0aGluZyB3aGlj
aCBpbXBsZW1lbnRhdGlvbiBvZiBkcml2ZXIgd291bGQgbmVlZCB0byB0YWtlIGNhcmUuIFNpbWls
YXJseSwgdXNlciBzcGFjZSBjYW4gaGF2ZSBpbXBsZW1lbnRhdGlvbiB0byBjYWNoZSBpbmZvcm1h
dGlvbiBvbiByZWNlaXB0IG9mIHRoZSBldmVudCB0byB1c2UgaXQgbGF0ZXIuDQoNClJlZ2FyZHMs
DQpSYWplc2ggQ2hhdWhhbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBE
YW4gV2lsbGlhbXMgW21haWx0bzpkY2J3QHJlZGhhdC5jb21dIA0KU2VudDogVGh1cnNkYXksIE9j
dG9iZXIgMTcsIDIwMTMgMTE6NDAgQU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBKb2hhbm5l
cyBCZXJnOyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFJvZHJpZ3VleiwgTHVpczsg
TWFsaW5lbiwgSm91bmk7IEJhaGluaSwgSGVucmk7IENoYW5nLCBMZW87IEx1bywgWHVuDQpTdWJq
ZWN0OiBSZTogW1BBVENIXSBjZmc4MDIxMS9ubDgwMjExOiBBZGQgc3VwcG9ydCB0byByZXBvcnQg
dW5zYWZlIGZyZXF1ZW5jeSByYW5nZXMocykNCg0KT24gVGh1LCAyMDEzLTEwLTE3IGF0IDE3OjQ2
ICswMDAwLCBDaGF1aGFuLCBSYWplc2ggd3JvdGU6DQo+IEhpIEpvaGFubmVzLA0KPiANCj4gTGV0
IG1lIGFsc28gcmVwbGFjZSBTQVAgd2l0aCBTb2Z0QVAuDQo+IA0KPiBTbyBub3cgY29tbWl0IHRl
eHQgd291bGQgYmU6DQo+IA0KPiBjZmc4MDIxMS9ubDgwMjExOiBBZGQgQVBJIHRvIHJlcG9ydCBm
cmVxdWVuY3kgcmFuZ2UocykgdG8gYmUgYXZvaWRlZA0KPiANCj4gQWRkIHN1cHBvcnQgZm9yIFdM
QU4gZHJpdmVyIHRvIHJlcG9ydCBmcmVxdWVuY3kgcmFuZ2UocykgdG8gYmUgYXZvaWRlZCBiZWNh
dXNlIG9mIGludGVyZmVyZW5jZS4gSWYgU29mdEFQL1AyUC1HTyBpcyBvcGVyYXRpbmcgb24gaW50
ZXJmZXJpbmcgZnJlcXVlbmN5IHRoZW4gdXNlciBzcGFjZSBzaG91bGQgc3RvcCBhbmQgcmVzdGFy
dCB0aGVtIGF2b2lkaW5nIGludGVyZmVyaW5nIGZyZXF1ZW5jeSByYW5nZShzKS4gVXNlciBzcGFj
ZSBtYXkgZGVjaWRlIHRvIGNvbnRpbnVlIG9wZXJhdGlvbiBvbiBpbnRlcmZlcmluZyBmcmVxdWVu
Y3ksIGJ1dCBpbiBzdWNoIGNhc2UsIHRoZXJlIG1pZ2h0IGJlIGltcGFjdCBvbiBwZXJmb3JtYW5j
ZS4NCg0KV291bGRuJ3QgYSBiZXR0ZXIgaW50ZXJmYWNlIGJlIHRvOg0KDQphKSBwcm92aWRlIGEg
bGlzdCBvZiB1bmRlc2lyYWJsZSBmcmVxdWVuY2llcyBhdCBhbGwgdGltZXMsIGluc3RlYWQgb2Yg
YW4gZXZlbnQsIHNvIHRoYXQgdXNlcnNwYWNlIGNhbiBkZWNpZGUgKmJlZm9yZSogY3JlYXRpbmcg
YSBTb2Z0IEFQIG9yIFAyUCB3aGljaCBpcyB0aGUgYmVzdCBjaGFubmVsIHRvIHVzZSwgaWYgaXQg
d2FudHMuICBQb3NzaWJseSB0aHJvdWdoIHRoZSBzYW1lIG1lY2hhbmlzbXMgdGhhdCBpdCdzIG90
aGVyIGNhcGFiaWxpdGllcyBhcmUgZXhwb3NlZCB0aHJvdWdoIChsaWtlIHRoZSBmdWxsIGxpc3Qg
b2Ygc3VwcG9ydGVkIGZyZXF1ZW5jaWVzLCBlZyAiaXcgcGh5IHBoeTAgaW5mbyIpLg0KDQpEcml2
ZXIgY2FuIHVwZGF0ZSB0aGlzIGxpc3QgYXQgYW55IHRpbWUgaWYgaXQgbm90aWNlcyBjaGFuZ2Vz
IHRvIHRoZSBSRiBlbnZpcm9ubWVudC4NCg0KYikgaWYgdGhlIGN1cnJlbnQgb3BlcmF0aW5nIGNo
YW5uZWwgZm9yIHNvbWUgU29mdCBBUCBvciBQMlAgaW50ZXJmYWNlIGJlY29tZXMgdW5kZXNpcmFi
bGUsIGVtaXQgYW4gZXZlbnQgaW5kaWNhdGluZyB0aGF0IHRoaXMgY2hhbm5lbCBpcyB1bmRlc2ly
YWJsZS4gIFVzZXJzcGFjZSBjYW4gdGhlbiBkZWNpZGUgdG8gY29udGludWUgb3BlcmF0aW5nIG9u
IHRoYXQgY2hhbm5lbCwgb3IgaXQgY2FuIGNoZWNrIHRoZSBsaXN0IG9mICJ1bmRlc2lyYWJsZSIg
Y2hhbm5lbHMgZnJvbSAoYSkgYW5kIHBpY2sgYSBkaWZmZXJlbnQgb25lLCBhbmQgbW92ZSB0byBp
dC4gIFRoaXMgaXMgZXNzZW50aWFsbHkgeW91ciBjdXJyZW50IHBhdGNoLCBidXQgdGhlIGV2ZW50
IG5lZWQgbm90IGNhcnJ5IHRoZSBjaGFubmVsIGxpc3QsIHNpbmNlIHRoYXQncyBleHBvc2VkIGJ5
IChhKSBhbHJlYWR5Lg0KDQpUaGVyZSBpcyBhIHNtYWxsIHJhY2UgYmV0d2VlbiBhIGNsaWVudCBy
ZWFkaW5nIChhKSBhbmQgYSBjbGllbnQgY3JlYXRpbmcgdGhlIFNvZnRBUC9QMlAgaW50ZXJmYWNl
LCBzbyBpdCB3b3VsZCBhbHNvIGJlIHVzZWZ1bCB0aGF0IGlmIHRoZSBjaGFubmVsIGEgY2xpZW50
IGlzIGNyZWF0aW5nIHRoZSBTb2Z0QVAvUDJQIG9uIGlzIHVuZGVzaXJhYmxlIHRoZSBldmVudCBn
ZXRzIGVtaXR0ZWQgaW1tZWRpYXRlbHkgYWZ0ZXIgY3JlYXRpb24uDQoNCk15IGlzc3VlIHdpdGgg
dGhlIG9yaWdpbmFsIHBhdGNoIGlzIHRoYXQgaXQgb25seSBkZWZpbmVzIHRoZSBldmVudCwgaXQg
ZG9lc24ndCBkZWZpbmUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgdG8gZ2V0IHRoaXMgaW5m
b3JtYXRpb24NCipiZWZvcmUqIGRvaW5nIHRoZSBvcGVyYXRpb24gdGhhdCBtYXkgYmUgdW5kZXNp
cmFibGUuDQoNCkRhbg0KDQo+IFJlZ2FyZHMsDQo+IFJhamVzaCBDaGF1aGFuDQo+IA0KPiANCj4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2hhdWhhbiwgUmFqZXNoDQo+IFNl
bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDEwOjIwIEFNDQo+IFRvOiAnSm9oYW5uZXMg
QmVyZycNCj4gQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZzsgUm9kcmlndWV6LCBM
dWlzOyBNYWxpbmVuLCBKb3VuaTsgDQo+IEJhaGluaSwgSGVucmk7IENoYW5nLCBMZW87IEx1bywg
WHVuOyBDaGF1aGFuLCBSYWplc2gNCj4gU3ViamVjdDogUkU6IFtQQVRDSF0gY2ZnODAyMTEvbmw4
MDIxMTogQWRkIHN1cHBvcnQgdG8gcmVwb3J0IHVuc2FmZSANCj4gZnJlcXVlbmN5IHJhbmdlcyhz
KQ0KPiANCj4gSGkgSm9oYW5uZXMsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudC4gUHVy
cG9zZSBvZiB0aGlzIHBhdGNoIGlzIHRvIGFkZCBhbiBBUEkgZm9yIFdMQU4gZHJpdmVyIHRvIHJl
cG9ydCBmcmVxdWVuY3kgcmFuZ2VzIHdoaWNoIHNob3VsZCBiZSBhdm9pZGVkIGZvciBTQVAvUDJQ
LUdPIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KPiANCj4gSG93IGFib3V0IGlmIEkgcmV3b3Jk
IGNvbW1pdCB0ZXN0IGFzIGJlbG93Pw0KPiANCj4gY2ZnODAyMTEvbmw4MDIxMTogQWRkIEFQSSB0
byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2b2lkZWQNCj4gDQo+IEFkZCBzdXBw
b3J0IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2
b2lkZWQgYmVjYXVzZSBvZiBpbnRlcmZlcmVuY2UuIElmIFNBUC9QMlAtR08gaXMgb3BlcmF0aW5n
IG9uIGludGVyZmVyaW5nIGZyZXF1ZW5jeSB0aGVuIHVzZXIgc3BhY2Ugc2hvdWxkIHN0b3AgYW5k
IHJlc3RhcnQgdGhlbSBhdm9pZGluZyBpbnRlcmZlcmluZyBmcmVxdWVuY3kgcmFuZ2UocykuIFVz
ZXIgc3BhY2UgbWF5IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gaW50ZXJmZXJpbmcg
ZnJlcXVlbmN5LCBidXQgaW4gc3VjaCBjYXNlLCB0aGVyZSBtaWdodCBiZSBpbXBhY3Qgb24gcGVy
Zm9ybWFuY2UuDQo+IA0KPiBSZWdhcmRzLA0KPiBSYWplc2ggQ2hhdWhhbg0KPiANCj4gDQo+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaGFubmVzIEJlcmcgW21haWx0bzpq
b2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNywg
MjAxMyA3OjQxIEFNDQo+IFRvOiBDaGF1aGFuLCBSYWplc2gNCj4gQ2M6IGxpbnV4LXdpcmVsZXNz
QHZnZXIua2VybmVsLm9yZzsgUm9kcmlndWV6LCBMdWlzOyBNYWxpbmVuLCBKb3VuaQ0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIXSBjZmc4MDIxMS9ubDgwMjExOiBBZGQgc3VwcG9ydCB0byByZXBvcnQg
dW5zYWZlIA0KPiBmcmVxdWVuY3kgcmFuZ2VzKHMpDQo+IA0KPiBPbiBXZWQsIDIwMTMtMTAtMTYg
YXQgMjE6NTcgLTA3MDAsIFJhamVzaCBDaGF1aGFuIHdyb3RlOg0KPiA+IEFkZCBzdXBwb3J0IGZv
ciBXTEFOIGRyaXZlciB0byByZXBvcnQgdW5zYWZlIGZyZXF1ZW5jeSByYW5nZShzKS4gDQo+IA0K
PiBXaHk/DQo+IA0KPiA+IFVzZXINCj4gPiBzcGFjZSBzaG91bGQgbW92ZSBTQVAvUDJQLUdPIG91
dCBvZiB0aG9zZSB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlKHMpLg0KPiA+IFVzZXIgc3BhY2UgbWF5
IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gdW5zYWZlIGZyZXF1ZW5jeSBidXQgDQo+
ID4gaW4gc3VjaCBjYXNlIHRoZXJlIG1pZ2h0IGJlIGltcGFjdCBvbiBwZXJmb3JtYW5jZSBiZWNh
dXNlIG9mIGludGVyZmVyZW5jZS4NCj4gDQo+IFNBUD8gSSBkb24ndCB0aGluayBTQVAgd2lsbCBt
b3ZlIC0gdGhleSdyZSBwcmV0dHkgc3R1Y2sgaW4gV2FsbGRvcmYgOlANCj4gDQo+IFRoaXMgaXMg
cHJldHR5IHN0cmFuZ2UgcGF0Y2gsIGFuZCB2ZXJ5IGxpdHRsZSBqdXN0aWZpY2F0aW9uLg0KPiAN
Cj4gIlVuc2FmZSIgaXMgYWxzbyBhIHJlYWxseSBiYWQgd29yZC4NCj4gDQo+IGpvaGFubmVzDQo+
IA0KPiBOcnliWMendl4p3rp7Lm4reyrelSx7YXkdyofamSxqIGZoeh53DQpqOit2d2ptIHpaK92i
aiIhDQoNCg0K
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Dan Williams @ 2013-10-17 18:39 UTC (permalink / raw)
To: Chauhan, Rajesh
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Rodriguez, Luis,
Malinen, Jouni, Bahini, Henri, Chang, Leo, Luo, Xun
In-Reply-To: <D19FD2B13A40CD4B8DA64DB9B8F112E9218DAD14@nasanexd01a.na.qualcomm.com>
On Thu, 2013-10-17 at 17:46 +0000, Chauhan, Rajesh wrote:
> Hi Johannes,
>
> Let me also replace SAP with SoftAP.
>
> So now commit text would be:
>
> cfg80211/nl80211: Add API to report frequency range(s) to be avoided
>
> Add support for WLAN driver to report frequency range(s) to be avoided because of interference. If SoftAP/P2P-GO is operating on interfering frequency then user space should stop and restart them avoiding interfering frequency range(s). User space may decide to continue operation on interfering frequency, but in such case, there might be impact on performance.
Wouldn't a better interface be to:
a) provide a list of undesirable frequencies at all times, instead of an
event, so that userspace can decide *before* creating a Soft AP or P2P
which is the best channel to use, if it wants. Possibly through the
same mechanisms that it's other capabilities are exposed through (like
the full list of supported frequencies, eg "iw phy phy0 info").
Driver can update this list at any time if it notices changes to the RF
environment.
b) if the current operating channel for some Soft AP or P2P interface
becomes undesirable, emit an event indicating that this channel is
undesirable. Userspace can then decide to continue operating on that
channel, or it can check the list of "undesirable" channels from (a) and
pick a different one, and move to it. This is essentially your current
patch, but the event need not carry the channel list, since that's
exposed by (a) already.
There is a small race between a client reading (a) and a client creating
the SoftAP/P2P interface, so it would also be useful that if the channel
a client is creating the SoftAP/P2P on is undesirable the event gets
emitted immediately after creation.
My issue with the original patch is that it only defines the event, it
doesn't define a mechanism for the client to get this information
*before* doing the operation that may be undesirable.
Dan
> Regards,
> Rajesh Chauhan
>
>
> -----Original Message-----
> From: Chauhan, Rajesh
> Sent: Thursday, October 17, 2013 10:20 AM
> To: 'Johannes Berg'
> Cc: linux-wireless@vger.kernel.org; Rodriguez, Luis; Malinen, Jouni; Bahini, Henri; Chang, Leo; Luo, Xun; Chauhan, Rajesh
> Subject: RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
>
> Hi Johannes,
>
> Thanks for your comment. Purpose of this patch is to add an API for WLAN driver to report frequency ranges which should be avoided for SAP/P2P-GO because of interference.
>
> How about if I reword commit test as below?
>
> cfg80211/nl80211: Add API to report frequency range(s) to be avoided
>
> Add support for WLAN driver to report frequency range(s) to be avoided because of interference. If SAP/P2P-GO is operating on interfering frequency then user space should stop and restart them avoiding interfering frequency range(s). User space may decide to continue operation on interfering frequency, but in such case, there might be impact on performance.
>
> Regards,
> Rajesh Chauhan
>
>
> -----Original Message-----
> From: Johannes Berg [mailto:johannes@sipsolutions.net]
> Sent: Thursday, October 17, 2013 7:41 AM
> To: Chauhan, Rajesh
> Cc: linux-wireless@vger.kernel.org; Rodriguez, Luis; Malinen, Jouni
> Subject: Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
>
> On Wed, 2013-10-16 at 21:57 -0700, Rajesh Chauhan wrote:
> > Add support for WLAN driver to report unsafe frequency range(s).
>
> Why?
>
> > User
> > space should move SAP/P2P-GO out of those unsafe frequency range(s).
> > User space may decide to continue operation on unsafe frequency but in
> > such case there might be impact on performance because of interference.
>
> SAP? I don't think SAP will move - they're pretty stuck in Walldorf :P
>
> This is pretty strange patch, and very little justification.
>
> "Unsafe" is also a really bad word.
>
> johannes
>
> NrybXǧv^){.n+{*ޕ,{ay\x1dʇڙ,j\afhz\x1ew\fj:+vwjm\azZ+ݢj"!
^ permalink raw reply
* pull request: wireless-next 2013-10-17
From: John W. Linville @ 2013-10-17 18:23 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 11716 bytes --]
Dave,
This is a batch of updates intended for the 3.13 stream...
The biggest item of interest in here is wcn36xx, the new mac80211
driver for Qualcomm WCN3660/WCN3680 hardware.
Regarding the mac80211 bits, Johannes says:
"We have an assortment of cleanups and new features, of which the
biggest one is probably the channel-switch support in IBSS. Nothing
else really stands out much."
On top of that, the ath9k and rt2x00 get a lot of update action from
Felix Fietkau and Gabor Juhos, respectively. There are a handful of
updates to other drivers here and there as well.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit ccdbb6e96beca362db876d820ac1e560ff6d9579:
tcp: tcp_transmit_skb() optimizations (2013-10-11 17:48:18 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
for you to fetch changes up to 9f96da4dd2ccf685b506a21104cb13b1aadd907a:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem (2013-10-17 14:02:07 -0400)
----------------------------------------------------------------
Amitkumar Karwar (1):
mwifiex: use alloc_workqueue() function
Arik Nemtsov (1):
mac80211: implement STA CSA for drivers using channel contexts
Eliad Peller (2):
mac80211: fix some snprintf misuses
ieee80211: fix vht cap definitions
Eugene Krasnikov (1):
wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
Felipe Balbi (1):
net: wireless: wl1251: update firmware path
Felix Fietkau (10):
ath9k: use a separate data structure for rx buffers
ath9k_hw: remove direct accesses to channel mode flags
ath9k_hw: remove IS_CHAN_B()
ath9k_hw: remove IS_CHAN_OFDM()
ath9k_hw: simplify channel flags
ath9k: make ath9k_cmn_update_ichannel static
ath9k: move channel change code to ath_set_channel
ath9k: remove sc->config.cabqReadyTime
ath9k: make ath9k_uses_beacons static
ath9k_hw: remove references to hw->conf
Fengguang Wu (1):
wcn36xx: fix coccinelle warnings
Fred Zhou (2):
mac80211: use exact-size allocation for authentication frame
mac80211: improve default WMM parameter setting
Gabor Juhos (14):
rt2x00: rt2800lib: remove TXMIXER_GAIN entries from the extended EEPROM map
rt2x00: rt2800lib: remove TXPOWER_DELTA entry from extended EEPROM map
rt2x00: rt2800lib: fix default VGC values for RT3593
rt2x00: rt2800lib: fix VGC programming for RT3572 and RT3593
rt2x00: rt2800lib: fix default VGC values for RT3572 for the 5GHz band
rt2x00: use generic EWMA functions for average RSSI calculations
rt2x00: rt2800lib: fix VGC adjustment for RT5592
rt2x00: rt2800lib: fix VGC adjustment for RT3572 and RT3593
rt2x00: cleanup indentation in rt2800.h
rt2x00: add rt2x00_has_cap_* helpers
rt2x00: rt2x00lib: use rt2x00_has_cap_* helpers
rt2x00: rt2800lib: use rt2x00_has_cap_* helpers
rt2x00: rt61pci: use rt2x00_has_cap_* helpers
rt2x00: rt73usb: use rt2x00_has_cap_* helpers
Hauke Mehrtens (3):
bcma: reject PCI cards in bcma.
bcma: add PCI id 0x4313
brcmsmac: add support for a BCM4313 with PCI id 0x4313
Janusz Dziedzic (1):
cfg80211: parse dfs region for internal regdb option
Johannes Berg (4):
mac80211: add ieee80211_iterate_active_interfaces_rtnl()
mac80211: use ERR_CAST()
mac80211: add explicit IBSS driver operations
regulatory: enable channels 52-64 and 100-144 for world roaming
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Kevin Lo (3):
rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
rt2x00: rt2800lib: fix RF registers for RT5390/RT5392
rt2x00: rt2800lib: remove duplicate rf_vals for RF3053
Kirill Tkhai (1):
rt2x00_pci: Fix interrupt handler name (visible at /proc/interrupts)
Lorenzo Bianconi (2):
mac80211: add fixed_rate management to minstrel rc
mac80211: do not override fixed_rate_idx in minstrel_ht_update_stats
Michael Opdenacker (1):
net: p54spi: remove deprecated IRQF_DISABLED
Michal Kazior (1):
mac80211: support reporting A-MSDU subframes individually
Peter Senna Tschudin (1):
mwifiex: Change variable type to bool
Sergey Ryazanov (1):
mac80211: Remove superfluous is_multicast_ether_addr() call
Simon Wunderlich (7):
cfg80211: export cfg80211_chandef_dfs_required
mac80211: split off channel switch parsing function
mac80211: split off ibss disconnect
mac80211: add support for CSA in IBSS mode
mac80211: send a CSA action frame when changing channel
nl80211: enable IBSS support for channel switch announcements
nl80211: allow CAC only if no operation is going on
Stanislaw Gruszka (2):
mac80211: change beacon/connection polling
rt2x00: do not pause queue on flush
cedric Voncken (1):
cfg80211: vlan priority handling in WMM
MAINTAINERS | 8 +
drivers/bcma/host_pci.c | 8 +-
drivers/net/wireless/ath/Kconfig | 1 +
drivers/net/wireless/ath/Makefile | 1 +
drivers/net/wireless/ath/ath9k/ani.c | 6 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 43 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 7 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 26 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 113 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 12 +-
drivers/net/wireless/ath/ath9k/calib.c | 9 +-
drivers/net/wireless/ath/ath9k/common.c | 91 +-
drivers/net/wireless/ath/ath9k/common.h | 7 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 32 +-
drivers/net/wireless/ath/ath9k/hw.c | 67 +-
drivers/net/wireless/ath/ath9k/hw.h | 82 +-
drivers/net/wireless/ath/ath9k/init.c | 87 +-
drivers/net/wireless/ath/ath9k/mac.c | 6 +-
drivers/net/wireless/ath/ath9k/mac.h | 2 -
drivers/net/wireless/ath/ath9k/main.c | 157 +-
drivers/net/wireless/ath/ath9k/mci.c | 8 +-
drivers/net/wireless/ath/ath9k/recv.c | 48 +-
drivers/net/wireless/ath/ath9k/xmit.c | 12 +-
drivers/net/wireless/ath/wcn36xx/Kconfig | 16 +
drivers/net/wireless/ath/wcn36xx/Makefile | 7 +
drivers/net/wireless/ath/wcn36xx/debug.c | 181 +
drivers/net/wireless/ath/wcn36xx/debug.h | 49 +
drivers/net/wireless/ath/wcn36xx/dxe.c | 805 ++++
drivers/net/wireless/ath/wcn36xx/dxe.h | 284 ++
drivers/net/wireless/ath/wcn36xx/hal.h | 4657 ++++++++++++++++++++++++
drivers/net/wireless/ath/wcn36xx/main.c | 1036 ++++++
drivers/net/wireless/ath/wcn36xx/pmc.c | 62 +
drivers/net/wireless/ath/wcn36xx/pmc.h | 33 +
drivers/net/wireless/ath/wcn36xx/smd.c | 2126 +++++++++++
drivers/net/wireless/ath/wcn36xx/smd.h | 127 +
drivers/net/wireless/ath/wcn36xx/txrx.c | 284 ++
drivers/net/wireless/ath/wcn36xx/txrx.h | 160 +
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 238 ++
drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/mwifiex/cmdevt.c | 2 +-
drivers/net/wireless/mwifiex/join.c | 2 +-
drivers/net/wireless/mwifiex/main.c | 4 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
drivers/net/wireless/mwifiex/wmm.c | 2 +-
drivers/net/wireless/p54/p54spi.c | 2 +-
drivers/net/wireless/rt2x00/Kconfig | 1 +
drivers/net/wireless/rt2x00/rt2800.h | 42 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 173 +-
drivers/net/wireless/rt2x00/rt2x00.h | 103 +-
drivers/net/wireless/rt2x00/rt2x00crypto.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00debug.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 8 +-
drivers/net/wireless/rt2x00/rt2x00link.c | 74 +-
drivers/net/wireless/rt2x00/rt2x00mac.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 39 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +
drivers/net/wireless/rt2x00/rt61pci.c | 20 +-
drivers/net/wireless/rt2x00/rt73usb.c | 18 +-
drivers/net/wireless/ti/wl1251/wl1251.h | 4 +-
include/linux/ieee80211.h | 4 +-
include/net/cfg80211.h | 9 +
include/net/mac80211.h | 42 +
net/mac80211/cfg.c | 92 +-
net/mac80211/chan.c | 5 -
net/mac80211/debugfs.c | 55 +-
net/mac80211/driver-ops.h | 27 +
net/mac80211/ibss.c | 608 +++-
net/mac80211/ieee80211_i.h | 30 +-
net/mac80211/iface.c | 4 +
net/mac80211/key.c | 2 +-
net/mac80211/mlme.c | 334 +-
net/mac80211/rc80211_minstrel.c | 14 +
net/mac80211/rc80211_minstrel_ht.c | 23 +-
net/mac80211/rc80211_pid_debugfs.c | 26 +-
net/mac80211/rx.c | 39 +-
net/mac80211/scan.c | 3 +-
net/mac80211/spectmgmt.c | 162 +
net/mac80211/trace.h | 35 +
net/mac80211/tx.c | 39 +-
net/mac80211/util.c | 162 +-
net/mac80211/vht.c | 4 +-
net/wireless/chan.c | 1 +
net/wireless/core.h | 9 -
net/wireless/debugfs.c | 24 +-
net/wireless/genregdb.awk | 6 +
net/wireless/nl80211.c | 52 +-
net/wireless/reg.c | 14 +-
net/wireless/util.c | 9 +
89 files changed, 11937 insertions(+), 1309 deletions(-)
create mode 100644 drivers/net/wireless/ath/wcn36xx/Kconfig
create mode 100644 drivers/net/wireless/ath/wcn36xx/Makefile
create mode 100644 drivers/net/wireless/ath/wcn36xx/debug.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/debug.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/dxe.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/dxe.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/hal.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/main.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/pmc.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/pmc.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/smd.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/smd.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/txrx.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/txrx.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/wcn36xx.h
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/2] cfg80211: update dfs_state_entered upon dfs_state change
From: Michal Kazior @ 2013-10-17 18:21 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1382034072-13541-1-git-send-email-michal.kazior@tieto.com>
The timestamp wasn't updated after transitioning
to the NL80211_DFS_USABLE state after NOP time.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
net/wireless/mlme.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index edfe6de..6a6b1c8 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -712,6 +712,8 @@ void cfg80211_dfs_channels_update_work(struct work_struct *work)
if (time_after_eq(jiffies, timeout)) {
c->dfs_state = NL80211_DFS_USABLE;
+ c->dfs_state_entered = jiffies;
+
cfg80211_chandef_create(&chandef, c,
NL80211_CHAN_NO_HT);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 1/2] cfg80211: fix DFS channel recovery timeout
From: Michal Kazior @ 2013-10-17 18:21 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Michal Kazior
The timeout was not properly converted from msecs
to jiffies. As a result channel transition to
NL80211_DFS_USABLE was delayed depending on
CONFIG_HZ configuration, e.g. HZ=100 would delay
the NOP from 30 minutes to 300 minutes.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
net/wireless/mlme.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 8d49c1c..edfe6de 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -707,8 +707,8 @@ void cfg80211_dfs_channels_update_work(struct work_struct *work)
if (c->dfs_state != NL80211_DFS_UNAVAILABLE)
continue;
- timeout = c->dfs_state_entered +
- IEEE80211_DFS_MIN_NOP_TIME_MS;
+ timeout = c->dfs_state_entered + msecs_to_jiffies(
+ IEEE80211_DFS_MIN_NOP_TIME_MS);
if (time_after_eq(jiffies, timeout)) {
c->dfs_state = NL80211_DFS_USABLE;
--
1.8.4.rc3
^ permalink raw reply related
* RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Chauhan, Rajesh @ 2013-10-17 17:46 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Rodriguez, Luis, Malinen, Jouni,
Bahini, Henri, Chang, Leo, Luo, Xun, Chauhan, Rajesh
In-Reply-To: <1382020835.14410.16.camel@jlt4.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCkxldCBtZSBhbHNvIHJlcGxhY2UgU0FQIHdpdGggU29mdEFQLg0KDQpT
byBub3cgY29tbWl0IHRleHQgd291bGQgYmU6DQoNCmNmZzgwMjExL25sODAyMTE6IEFkZCBBUEkg
dG8gcmVwb3J0IGZyZXF1ZW5jeSByYW5nZShzKSB0byBiZSBhdm9pZGVkDQoNCkFkZCBzdXBwb3J0
IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRvIGJlIGF2b2lk
ZWQgYmVjYXVzZSBvZiBpbnRlcmZlcmVuY2UuIElmIFNvZnRBUC9QMlAtR08gaXMgb3BlcmF0aW5n
IG9uIGludGVyZmVyaW5nIGZyZXF1ZW5jeSB0aGVuIHVzZXIgc3BhY2Ugc2hvdWxkIHN0b3AgYW5k
IHJlc3RhcnQgdGhlbSBhdm9pZGluZyBpbnRlcmZlcmluZyBmcmVxdWVuY3kgcmFuZ2UocykuIFVz
ZXIgc3BhY2UgbWF5IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gaW50ZXJmZXJpbmcg
ZnJlcXVlbmN5LCBidXQgaW4gc3VjaCBjYXNlLCB0aGVyZSBtaWdodCBiZSBpbXBhY3Qgb24gcGVy
Zm9ybWFuY2UuDQoNClJlZ2FyZHMsDQpSYWplc2ggQ2hhdWhhbg0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBDaGF1aGFuLCBSYWplc2ggDQpTZW50OiBUaHVyc2RheSwgT2N0
b2JlciAxNywgMjAxMyAxMDoyMCBBTQ0KVG86ICdKb2hhbm5lcyBCZXJnJw0KQ2M6IGxpbnV4LXdp
cmVsZXNzQHZnZXIua2VybmVsLm9yZzsgUm9kcmlndWV6LCBMdWlzOyBNYWxpbmVuLCBKb3VuaTsg
QmFoaW5pLCBIZW5yaTsgQ2hhbmcsIExlbzsgTHVvLCBYdW47IENoYXVoYW4sIFJhamVzaA0KU3Vi
amVjdDogUkU6IFtQQVRDSF0gY2ZnODAyMTEvbmw4MDIxMTogQWRkIHN1cHBvcnQgdG8gcmVwb3J0
IHVuc2FmZSBmcmVxdWVuY3kgcmFuZ2VzKHMpDQoNCkhpIEpvaGFubmVzLA0KDQpUaGFua3MgZm9y
IHlvdXIgY29tbWVudC4gUHVycG9zZSBvZiB0aGlzIHBhdGNoIGlzIHRvIGFkZCBhbiBBUEkgZm9y
IFdMQU4gZHJpdmVyIHRvIHJlcG9ydCBmcmVxdWVuY3kgcmFuZ2VzIHdoaWNoIHNob3VsZCBiZSBh
dm9pZGVkIGZvciBTQVAvUDJQLUdPIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KDQpIb3cgYWJv
dXQgaWYgSSByZXdvcmQgY29tbWl0IHRlc3QgYXMgYmVsb3c/DQoNCmNmZzgwMjExL25sODAyMTE6
IEFkZCBBUEkgdG8gcmVwb3J0IGZyZXF1ZW5jeSByYW5nZShzKSB0byBiZSBhdm9pZGVkDQoNCkFk
ZCBzdXBwb3J0IGZvciBXTEFOIGRyaXZlciB0byByZXBvcnQgZnJlcXVlbmN5IHJhbmdlKHMpIHRv
IGJlIGF2b2lkZWQgYmVjYXVzZSBvZiBpbnRlcmZlcmVuY2UuIElmIFNBUC9QMlAtR08gaXMgb3Bl
cmF0aW5nIG9uIGludGVyZmVyaW5nIGZyZXF1ZW5jeSB0aGVuIHVzZXIgc3BhY2Ugc2hvdWxkIHN0
b3AgYW5kIHJlc3RhcnQgdGhlbSBhdm9pZGluZyBpbnRlcmZlcmluZyBmcmVxdWVuY3kgcmFuZ2Uo
cykuIFVzZXIgc3BhY2UgbWF5IGRlY2lkZSB0byBjb250aW51ZSBvcGVyYXRpb24gb24gaW50ZXJm
ZXJpbmcgZnJlcXVlbmN5LCBidXQgaW4gc3VjaCBjYXNlLCB0aGVyZSBtaWdodCBiZSBpbXBhY3Qg
b24gcGVyZm9ybWFuY2UuDQoNClJlZ2FyZHMsDQpSYWplc2ggQ2hhdWhhbg0KDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWlsdG86am9oYW5uZXNA
c2lwc29sdXRpb25zLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDc6NDEg
QU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5v
cmc7IFJvZHJpZ3VleiwgTHVpczsgTWFsaW5lbiwgSm91bmkNClN1YmplY3Q6IFJlOiBbUEFUQ0hd
IGNmZzgwMjExL25sODAyMTE6IEFkZCBzdXBwb3J0IHRvIHJlcG9ydCB1bnNhZmUgZnJlcXVlbmN5
IHJhbmdlcyhzKQ0KDQpPbiBXZWQsIDIwMTMtMTAtMTYgYXQgMjE6NTcgLTA3MDAsIFJhamVzaCBD
aGF1aGFuIHdyb3RlOg0KPiBBZGQgc3VwcG9ydCBmb3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IHVu
c2FmZSBmcmVxdWVuY3kgcmFuZ2UocykuIA0KDQpXaHk/DQoNCj4gVXNlcg0KPiBzcGFjZSBzaG91
bGQgbW92ZSBTQVAvUDJQLUdPIG91dCBvZiB0aG9zZSB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlKHMp
Lg0KPiBVc2VyIHNwYWNlIG1heSBkZWNpZGUgdG8gY29udGludWUgb3BlcmF0aW9uIG9uIHVuc2Fm
ZSBmcmVxdWVuY3kgYnV0IGluIA0KPiBzdWNoIGNhc2UgdGhlcmUgbWlnaHQgYmUgaW1wYWN0IG9u
IHBlcmZvcm1hbmNlIGJlY2F1c2Ugb2YgaW50ZXJmZXJlbmNlLg0KDQpTQVA/IEkgZG9uJ3QgdGhp
bmsgU0FQIHdpbGwgbW92ZSAtIHRoZXkncmUgcHJldHR5IHN0dWNrIGluIFdhbGxkb3JmIDpQDQoN
ClRoaXMgaXMgcHJldHR5IHN0cmFuZ2UgcGF0Y2gsIGFuZCB2ZXJ5IGxpdHRsZSBqdXN0aWZpY2F0
aW9uLg0KDQoiVW5zYWZlIiBpcyBhbHNvIGEgcmVhbGx5IGJhZCB3b3JkLg0KDQpqb2hhbm5lcw0K
DQo=
^ permalink raw reply
* RE: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Chauhan, Rajesh @ 2013-10-17 17:19 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Rodriguez, Luis, Malinen, Jouni,
Bahini, Henri, Chang, Leo, Luo, Xun, Chauhan, Rajesh
In-Reply-To: <1382020835.14410.16.camel@jlt4.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50LiBQdXJwb3NlIG9mIHRoaXMg
cGF0Y2ggaXMgdG8gYWRkIGFuIEFQSSBmb3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IGZyZXF1ZW5j
eSByYW5nZXMgd2hpY2ggc2hvdWxkIGJlIGF2b2lkZWQgZm9yIFNBUC9QMlAtR08gYmVjYXVzZSBv
ZiBpbnRlcmZlcmVuY2UuDQoNCkhvdyBhYm91dCBpZiBJIHJld29yZCBjb21taXQgdGVzdCBhcyBi
ZWxvdz8NCg0KY2ZnODAyMTEvbmw4MDIxMTogQWRkIEFQSSB0byByZXBvcnQgZnJlcXVlbmN5IHJh
bmdlKHMpIHRvIGJlIGF2b2lkZWQNCg0KQWRkIHN1cHBvcnQgZm9yIFdMQU4gZHJpdmVyIHRvIHJl
cG9ydCBmcmVxdWVuY3kgcmFuZ2UocykgdG8gYmUgYXZvaWRlZCBiZWNhdXNlIG9mIGludGVyZmVy
ZW5jZS4gSWYgU0FQL1AyUC1HTyBpcyBvcGVyYXRpbmcgb24gaW50ZXJmZXJpbmcgZnJlcXVlbmN5
IHRoZW4gdXNlciBzcGFjZSBzaG91bGQgc3RvcCBhbmQgcmVzdGFydCB0aGVtIGF2b2lkaW5nIGlu
dGVyZmVyaW5nIGZyZXF1ZW5jeSByYW5nZShzKS4gVXNlciBzcGFjZSBtYXkgZGVjaWRlIHRvIGNv
bnRpbnVlIG9wZXJhdGlvbiBvbiBpbnRlcmZlcmluZyBmcmVxdWVuY3ksIGJ1dCBpbiBzdWNoIGNh
c2UsIHRoZXJlIG1pZ2h0IGJlIGltcGFjdCBvbiBwZXJmb3JtYW5jZS4NCg0KUmVnYXJkcywNClJh
amVzaCBDaGF1aGFuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvaGFu
bmVzIEJlcmcgW21haWx0bzpqb2hhbm5lc0BzaXBzb2x1dGlvbnMubmV0XSANClNlbnQ6IFRodXJz
ZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDc6NDEgQU0NClRvOiBDaGF1aGFuLCBSYWplc2gNCkNjOiBs
aW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IFJvZHJpZ3VleiwgTHVpczsgTWFsaW5lbiwg
Sm91bmkNClN1YmplY3Q6IFJlOiBbUEFUQ0hdIGNmZzgwMjExL25sODAyMTE6IEFkZCBzdXBwb3J0
IHRvIHJlcG9ydCB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlcyhzKQ0KDQpPbiBXZWQsIDIwMTMtMTAt
MTYgYXQgMjE6NTcgLTA3MDAsIFJhamVzaCBDaGF1aGFuIHdyb3RlOg0KPiBBZGQgc3VwcG9ydCBm
b3IgV0xBTiBkcml2ZXIgdG8gcmVwb3J0IHVuc2FmZSBmcmVxdWVuY3kgcmFuZ2UocykuIA0KDQpX
aHk/DQoNCj4gVXNlcg0KPiBzcGFjZSBzaG91bGQgbW92ZSBTQVAvUDJQLUdPIG91dCBvZiB0aG9z
ZSB1bnNhZmUgZnJlcXVlbmN5IHJhbmdlKHMpLg0KPiBVc2VyIHNwYWNlIG1heSBkZWNpZGUgdG8g
Y29udGludWUgb3BlcmF0aW9uIG9uIHVuc2FmZSBmcmVxdWVuY3kgYnV0IGluIA0KPiBzdWNoIGNh
c2UgdGhlcmUgbWlnaHQgYmUgaW1wYWN0IG9uIHBlcmZvcm1hbmNlIGJlY2F1c2Ugb2YgaW50ZXJm
ZXJlbmNlLg0KDQpTQVA/IEkgZG9uJ3QgdGhpbmsgU0FQIHdpbGwgbW92ZSAtIHRoZXkncmUgcHJl
dHR5IHN0dWNrIGluIFdhbGxkb3JmIDpQDQoNClRoaXMgaXMgcHJldHR5IHN0cmFuZ2UgcGF0Y2gs
IGFuZCB2ZXJ5IGxpdHRsZSBqdXN0aWZpY2F0aW9uLg0KDQoiVW5zYWZlIiBpcyBhbHNvIGEgcmVh
bGx5IGJhZCB3b3JkLg0KDQpqb2hhbm5lcw0KDQo=
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Will Hawkins @ 2013-10-17 16:19 UTC (permalink / raw)
To: Johannes Berg, Detlev Casanova
Cc: Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <1382020735.14410.14.camel@jlt4.sipsolutions.net>
On 10/17/2013 10:38 AM, Johannes Berg wrote:
> On Fri, 2013-10-11 at 17:43 +0200, Detlev Casanova wrote:
>
>>>>>> occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
>>>>
>>>> ("cfg80211:
>>>>>> use DS or HT operation IEs to determine BSS channel")
>>>
>>> [...]
>>>
>>>> I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
>>>> the problem seems to be fixed.
>>>
>>> Huh, that's odd. Did 0.7.3 use wext driver?
>>
>> Yes it did.
>
> Hmm. Even taking that into account though I don't really see any
> difference.
>
> Maybe you could check if there's any difference in iwlist scan output
> before/after the patch (for the affected AP)?
>
> johannes
Not to clog up the channel, but I was running into exactly the same
problem. I expected to see the problem somewhere in the kernel, etc. I
turned on debugging and kernel tracing and saw nothing. The fix for me
is almost identical to the fix that Detlev first described.
However, the problem for me was somewhere else entirely. The access
point was sending out malformed beacon messages that kept it from
showing up.
I *hope* that this helps. However, I hope, at least, this was not a
waste of bits. :-)
Will
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v5 4/5] {nl,cfg,mac}80211: implement mesh channel switch userspace API
From: Johannes Berg @ 2013-10-17 16:02 UTC (permalink / raw)
To: Chun-Yeow Yeoh
Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <CAHS2MGMgTp9homs-moVXTVfyFtcuYPPbHBiiW0XD9kBYJ0hb5w@mail.gmail.com>
On Thu, 2013-10-17 at 23:52 +0800, Chun-Yeow Yeoh wrote:
> > If this fails, do we leak the CSA settings?
> If failed, beacon won't include the CSA settings. But If there is any
> other calling mesh_rebuild_beacon and succeed, the it will be included
> up if the channel switch count is not expired. At the same time, CSA
> action frame is also transmitted, so others may use this to start the
> CSA process.
That part makes sense. But we propagate the error up, and then we
probably never call the finish function?
johannes
^ permalink raw reply
* Re: [PATCH v5 4/5] {nl,cfg,mac}80211: implement mesh channel switch userspace API
From: Chun-Yeow Yeoh @ 2013-10-17 15:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville, devel, distro11s@cozybit.com
In-Reply-To: <1382022683.14410.18.camel@jlt4.sipsolutions.net>
> If this fails, do we leak the CSA settings?
If failed, beacon won't include the CSA settings. But If there is any
other calling mesh_rebuild_beacon and succeed, the it will be included
up if the channel switch count is not expired. At the same time, CSA
action frame is also transmitted, so others may use this to start the
CSA process.
Am I answer your question?
----
Chun-Yeow
^ permalink raw reply
* Re: [PATCH v5 0/5] Add Mesh Channel Switch Support
From: Johannes Berg @ 2013-10-17 15:12 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381802911-3921-1-git-send-email-yeohchunyeow@cozybit.com>
I've applied patches 1-3 and there's one question on patch 4.
johannes
^ permalink raw reply
* Re: [PATCH v5 4/5] {nl,cfg,mac}80211: implement mesh channel switch userspace API
From: Johannes Berg @ 2013-10-17 15:11 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1381802911-3921-5-git-send-email-yeohchunyeow@cozybit.com>
On Mon, 2013-10-14 at 19:08 -0700, Chun-Yeow Yeoh wrote:
> +int ieee80211_mesh_csa_beacon(struct ieee80211_sub_if_data *sdata,
> + struct cfg80211_csa_settings *csa_settings,
> + bool csa_action)
> +{
> + struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
> + struct mesh_csa_settings *tmp_csa_settings;
> + int ret = 0;
> +
> + if (csa_action)
> + ieee80211_send_action_csa(sdata, csa_settings);
> +
> + tmp_csa_settings = kmalloc(sizeof(*tmp_csa_settings),
> + GFP_ATOMIC);
> + if (!tmp_csa_settings)
> + return -ENOMEM;
> +
> + memcpy(&tmp_csa_settings->settings, csa_settings,
> + sizeof(struct cfg80211_csa_settings));
> +
> + rcu_assign_pointer(ifmsh->csa, tmp_csa_settings);
> +
> + ret = ieee80211_mesh_rebuild_beacon(sdata);
> + if (ret)
> + return -EINVAL;
If this fails, do we leak the CSA settings?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Antonio Quartulli @ 2013-10-17 14:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1382021488.14410.17.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
On Thu, Oct 17, 2013 at 04:51:28PM +0200, Johannes Berg wrote:
> On Thu, 2013-10-17 at 16:48 +0200, Antonio Quartulli wrote:
> > On Thu, Oct 17, 2013 at 04:36:28PM +0200, Johannes Berg wrote:
> > > On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> > > > From: Antonio Quartulli <antonio@open-mesh.com>
> > > >
> > > > To allow cfg80211 to use the real channel to pick up the
> > > > proper (i)bss object, store the used channel in
> > > > wdev->channel during ibss_join
> > >
> > > WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
> >
> > Mh, ok. :)
> >
> > What about setting wdev->channel in __cfg80211_join_ibss() right after having
> > set wdev->ssid ?
> > This way we leave mac80211 out and we totally handle this thing in cfg80211
> > only.
>
> Locking might be problematic though. I also don't know where else the
> channel might be used?
I don't think it is used elsewhere in IBSS mode
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Johannes Berg @ 2013-10-17 14:51 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <20131017144824.GH2596@neomailbox.net>
On Thu, 2013-10-17 at 16:48 +0200, Antonio Quartulli wrote:
> On Thu, Oct 17, 2013 at 04:36:28PM +0200, Johannes Berg wrote:
> > On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> > > From: Antonio Quartulli <antonio@open-mesh.com>
> > >
> > > To allow cfg80211 to use the real channel to pick up the
> > > proper (i)bss object, store the used channel in
> > > wdev->channel during ibss_join
> >
> > WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
>
> Mh, ok. :)
>
> What about setting wdev->channel in __cfg80211_join_ibss() right after having
> set wdev->ssid ?
> This way we leave mac80211 out and we totally handle this thing in cfg80211
> only.
Locking might be problematic though. I also don't know where else the
channel might be used?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Antonio Quartulli @ 2013-10-17 14:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1382020588.14410.12.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Thu, Oct 17, 2013 at 04:36:28PM +0200, Johannes Berg wrote:
> On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> > From: Antonio Quartulli <antonio@open-mesh.com>
> >
> > To allow cfg80211 to use the real channel to pick up the
> > proper (i)bss object, store the used channel in
> > wdev->channel during ibss_join
>
> WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
Mh, ok. :)
What about setting wdev->channel in __cfg80211_join_ibss() right after having
set wdev->ssid ?
This way we leave mac80211 out and we totally handle this thing in cfg80211
only.
(I think with this change patch 1/2 makes more sense?)
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Johannes Berg @ 2013-10-17 14:40 UTC (permalink / raw)
To: Rajesh Chauhan; +Cc: linux-wireless, rodrigue, jouni
In-Reply-To: <1381985833-31312-1-git-send-email-rajeshc@qca.qualcomm.com>
On Wed, 2013-10-16 at 21:57 -0700, Rajesh Chauhan wrote:
> Add support for WLAN driver to report unsafe frequency range(s).
Why?
> User
> space should move SAP/P2P-GO out of those unsafe frequency range(s).
> User space may decide to continue operation on unsafe frequency but in
> such case there might be impact on performance because of interference.
SAP? I don't think SAP will move - they're pretty stuck in Walldorf :P
This is pretty strange patch, and very little justification.
"Unsafe" is also a really bad word.
johannes
^ permalink raw reply
* Re: [PATCH 3.12] rt2800usb: slow down TX status polling
From: Larry Finger @ 2013-10-17 14:39 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: users
In-Reply-To: <20131017100431.GA9603@redhat.com>
On 10/17/2013 05:04 AM, Stanislaw Gruszka wrote:
> Polling TX statuses too frequently has two negative effects. First is
> randomly peek CPU usage, causing overall system functioning delays.
> Second bad effect is that device is not able to fill TX statuses in
> H/W register on some workloads and we get lot of timeouts like below:
>
> ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
> ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
> ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
>
> This not only cause flood of messages in dmesg, but also bad throughput,
> since rate scaling algorithm can not work optimally.
>
> In the future, we should probably make polling interval be adjusted
> automatically, but for now just increase values, this make mentioned
> problems gone.
>
> Resolve:
> https://bugzilla.kernel.org/show_bug.cgi?id=62781
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 96677ce5..e095e61 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -176,8 +176,8 @@ static bool rt2800usb_tx_sta_fifo_read_completed(struct rt2x00_dev *rt2x00dev,
> queue_work(rt2x00dev->workqueue, &rt2x00dev->txdone_work);
>
> if (rt2800usb_txstatus_pending(rt2x00dev)) {
> - /* Read register after 250 us */
> - hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 250000),
> + /* Read register after 1 ms */
> + hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 1000000),
> HRTIMER_MODE_REL);
> return false;
> }
> @@ -202,8 +202,8 @@ static void rt2800usb_async_read_tx_status(struct rt2x00_dev *rt2x00dev)
> if (test_and_set_bit(TX_STATUS_READING, &rt2x00dev->flags))
> return;
>
> - /* Read TX_STA_FIFO register after 500 us */
> - hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 500000),
> + /* Read TX_STA_FIFO register after 2 ms */
> + hrtimer_start(&rt2x00dev->txstatus_timer, ktime_set(0, 2000000),
> HRTIMER_MODE_REL);
> }
I suggest getting rid of the magic numbers as long as you are making this
change. A single define could handle the delay time for the two cases.
Larry
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Johannes Berg @ 2013-10-17 14:38 UTC (permalink / raw)
To: Detlev Casanova; +Cc: Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <3301062.MLBKDh0Ksv@naboo>
On Fri, 2013-10-11 at 17:43 +0200, Detlev Casanova wrote:
> > > > > occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
> > >
> > > ("cfg80211:
> > > > > use DS or HT operation IEs to determine BSS channel")
> >
> > [...]
> >
> > > I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
> > > the problem seems to be fixed.
> >
> > Huh, that's odd. Did 0.7.3 use wext driver?
>
> Yes it did.
Hmm. Even taking that into account though I don't really see any
difference.
Maybe you could check if there's any difference in iwlist scan output
before/after the patch (for the affected AP)?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: add ieee80211_tx_prepare_skb() helper function
From: Johannes Berg @ 2013-10-17 14:37 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1381766460-84515-1-git-send-email-nbd@openwrt.org>
On Mon, 2013-10-14 at 18:01 +0200, Felix Fietkau wrote:
> This can be used by a driver to prepare skbs for transmission, which were
> obtained via functions such as ieee80211_probereq_get or
> ieee80211_nullfunc_get.
>
> This is useful for drivers that want to send those frames directly, but
> need rate control information to be prepared first.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: store the channel in wdev upon ibss_join
From: Johannes Berg @ 2013-10-17 14:36 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1381790282-1146-2-git-send-email-antonio@meshcoding.com>
On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> To allow cfg80211 to use the real channel to pick up the
> proper (i)bss object, store the used channel in
> wdev->channel during ibss_join
WTF? No, mac80211 can't just randomly modify cfg80211-owned data.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: on ibss_joined use the channel to get the proper bss object
From: Johannes Berg @ 2013-10-17 14:35 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1381790282-1146-1-git-send-email-antonio@meshcoding.com>
On Tue, 2013-10-15 at 00:38 +0200, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> It may be the case that the same IBSS (same bssid and essid)
> exists on two different channels (i.e. two IBSSes created
> with different but fixed freq) and therefore the latter must
> be also used to distinguish them.
>
> Fix wdev->current_bss assignment by passing the channel to
> cfg80211_get_bss() on ibss_joined.
> This ensures that cfg80211_get_bss() picks up the proper bss
> object.
This makes no sense, wdev->channel should always be NULL (unless the
same wdev was in AP or mesh mode first and that somehow leaked out?)
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox