Johannes Berg | 22 May 16:25 2015

[PATCH] cfg80211: properly send NL80211_ATTR_DISCONNECTED_BY_AP in disconnect

From: Johannes Berg <johannes.berg@...>

When we disconnect from the AP, drivers call cfg80211_disconnect().
This doesn't know whether the disconnection was initiated locally
or by the AP though, which can cause problems with the supplicant,
for example with WPS. This issue obviously doesn't show up with any
mac80211 based driver since mac80211 doesn't call this function.

Fix this by requiring drivers to indicate whether the disconnect is
locally generated or not. I've tried to update the drivers, but may
not have gotten the values correct, and some drivers may currently
not be able to report correct values. In case of doubt I left it at
false, which is the current behaviour.

Reported-by: Matthieu Mauger <matthieux.mauger@...>
Tested-by: Matthieu Mauger <matthieux.mauger@...>
Signed-off-by: Johannes Berg <johannes.berg@...>
 drivers/net/wireless/ath/ath6kl/cfg80211.c         | 4 ++--
 drivers/net/wireless/ath/wil6210/main.c            | 2 +-
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 4 ++--
 drivers/net/wireless/libertas/cfg.c                | 4 ++--
 drivers/net/wireless/mwifiex/join.c                | 2 +-
 drivers/net/wireless/mwifiex/sta_event.c           | 2 +-
 drivers/net/wireless/rndis_wlan.c                  | 2 +-
 drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c  | 2 +-
 drivers/staging/wlan-ng/cfg80211.c                 | 2 +-
 include/net/cfg80211.h                             | 4 +++-
 net/wireless/core.h                                | 1 +
 net/wireless/sme.c                                 | 4 +++-
(Continue reading)

Alexis Green | 22 May 03:05 2015

[PATCH] mac80211: fix a NULL dereference in ath9k (and likely other drivers) when fixed mesh paths are used

This patch fixes a NULL dereference in ath9k (and likely other drivers) when
fixed mesh paths are used. The problem is that when a station comes up
sta_info_alloc allocates ath_node implicitly via hw->sta_data_size. When it
does that the ath_node is zeroed out. The ath_node isn’t actually initialized
until the station becomes associated and ath9k_sta_state is called.

Normally this is OK because paths won't be formed to a station that isn't
authorized. But when the path is fixed the MAC thinks it knows how to
 route the packet, sends it down to ath9k, and winds up inducing reboots
in places like ath_tx_start when tid->ac is dereferenced.

Signed-off-by: Alexis Green <agreen@...>
CC: Jesse Jones <jjones@...>


diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 214e63b..14e146e 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
 <at>  <at>  -1081,6 +1081,11  <at>  <at>  int mesh_nexthop_resolve(struct
ieee80211_sub_if_data *sdata,
        if (!err)
                goto endlookup;

+       if (err == -EPERM) {
+               mesh_path_discard_frame(sdata, skb);
+               goto endlookup;
+       }
(Continue reading)

Michael Büsch | 21 May 21:44 2015

[PATCH] rtlwifi: Fix EFUSE_ANA8M map value

The map entry EFUSE_ANA8M is supposed to be a bit mask of the SYS_CLK register (see efuse.c)
It doesn't make sense to assign the enumeration value EFUSE_ANA8M. Assign the bitmask ANA8M instead.
rtl8192se does not have ANA8M, so use 0 as bitmask.

Signed-off-by: Michael Buesch <m <at>>


This is RFC, because I don't really know the device.
The rtl8192se part of the patch is just a guess, because this driver's reg.h doesn't have an ANA8M define.

Index: wireless-drivers-next/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
--- wireless-drivers-next.orig/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
+++ wireless-drivers-next/drivers/net/wireless/rtlwifi/rtl8192ce/sw.c
 <at>  <at>  -282,7 +282,7  <at>  <at>  static struct rtl_hal_cfg rtl92ce_hal_cf
 	.maps[EFUSE_PWC_EV12V] = PWC_EV12V,
+	.maps[EFUSE_ANA8M] = ANA8M,
Index: wireless-drivers-next/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
--- wireless-drivers-next.orig/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ wireless-drivers-next/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
 <at>  <at>  -206,7 +206,7  <at>  <at>  static struct rtl_hal_cfg rtl92cu_hal_cf
 	.maps[EFUSE_PWC_EV12V] = PWC_EV12V,
(Continue reading)

Grumbach, Emmanuel | 21 May 21:50 2015

pull request: iwlwifi 2015-05-21

Hi Kalle,

I am aware that this pull request is quite large for 4.1, but I really
think that all these patches are really justified.
A few of them fix 3165 and 8260 which will be supported starting from
4.1. Other patches fix random bugs that were discovered just now.

Note that my availability is limited in the next week, but I'll try to
handle any issues you may have ASAP.

The following changes since commit e7afe89fd67d40a7f5fff8130c5f925d99a94b1f:

  iwlwifi: mvm: force quota update update after FW restart (2015-04-28 15:02:25 +0300)

are available in the git repository at: tags/iwlwifi-for-kalle-2015-05-21

for you to fetch changes up to 292208914d8ca5a41cf68c2f1d2810a2ea2044e9:

  iwlwifi: mvm: avoid use-after-free on iwl_mvm_d0i3_enable_tx() (2015-05-21 22:36:46 +0300)

* fix firmware name and other things to enable 3165
* fix bad APMG configuration for 8000 (no AMPG on these devices)
* fix MAC address assignment for 8000
* fix firmware debugging triggers (MLME)
* fix several bugs in low power states code (net-detect,

(Continue reading)

Jason Scatena | 21 May 19:11 2015

Issues with mesh networking path detection

Hello all,

I am attempting to set up a mesh network between 4 computers with
Atheros 9271 based usb wifi dongles using the ath9k driver.

I followed the guide at:

to set up the network.

When I get all of the computers up and configured they all see each other.
The command "iw dev mesh station dump" shows all the nodes in the
area. However the path selection doesn't seem to work at all. For
instance the command "iw dev mesh mpath dump" returns nothing. However
if I manually add arp entries using the arp command they show up in
the mpath dump.

I am willing to do whatever to troubleshoot however there is very
little documentation that I have been able to find on trouble shooting
these issues. I would also be able to provide a pcap file of the nodes
coming online.

I'm new to the wireless world but have C coding experience and would
be willing to put in the time to learn.

Jason Scatena
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at
(Continue reading)

Mário Lopes | 21 May 18:47 2015

Change random waiting time between frames

Hello all.

Is there a way, by changing ath9k or mac80211 code for example, in  
order to change random waiting time to fixed, which exists between  
consecutive frames sent from same AP/STA/mesh point to another? AFAIK  
it's called "random backoff timer".
It's desired to work both on unicast and broadcast frames.

Thanks for the help.

Mário Lopes.

This message was sent using IMP, the Internet Messaging Program.
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at

Kalle Valo | 21 May 15:39 2015

pull-request: wireless-drivers-next 2015-05-21

Hi Dave,

here's a wireless-drivers pull request for 4.2. This time please pay
extra attention to this pull as there are two problems:

First of all as you can see the diffstat from git-pull-request in the
end is just weird. I was long and hard trying to check everything and to
my understanding all the merges look ok and I cannot explain the reason
for the diffstat, but of course I might be missing something. Maybe
git-request-pull is just buggy? At least with gitk everything looks to
be ok and the patch list below also looks valid.

Secondly there's a non-trivial conflict in
drivers/net/wireless/ath/ath10k/mac.c which is due to removal of
FIF_PROMISC_IN_BSS in commit df1404650c. You need to remove more code
than just the obvious conflicts shown by git. In the end of this mail I
added a git diff output after I fixed the conflict, hopefully that helps
you to fix it. The main points are that you remove
ath10k_mac_should_disable_promisc() and the last ath10k_monitor_recalc()
call from ath10k_vdev_start_restart() along with the obvious conflict
fixes git points out.

There's also a patch from Michal which will also help to fix the
resolution. Michal, please double check the resolution proposal below so
that I didn't miss anything.

Please let me know if there are any problems.

(Continue reading)

Janusz Dziedzic | 21 May 12:10 2015

ath9k: use_chanctx=1 sta + p2p_client - oops


During tests of multi channel concurency with AR9462 (rev 01) I hit such oops

gdb point xmit.c +2378

[70874.035886] BUG: unable to handle kernel NULL pointer dereference
at           (null)
[70874.043725] IP: [<ffffffffc071d589>] ath_tx_start+0x129/0x450 [ath9k]
[70874.050173] PGD cb5e4067 PUD cae20067 PMD 0
[70874.054462] Oops: 0000 [#1] SMP
[70874.057702] Modules linked in: iwlmvm(E) iwlwifi(E) ath10k_pci(OE)
ath10k_core(OE) ath9k(E) ath9k_common(E) ath9k_hw(E) ath(E)
mac80211(OE) cfg80211(OE) ftdi_sio(E) usbserial(E) ctr(E) ccm(E)
arc4(E) dm_crypt(E) cmac(E) dell_wmi(E) sparse_keymap(E) intel_rapl(E)
dell_laptop(E) iosf_mbi(E) dcdbas(E) x86_pkg_temp_thermal(E)
intel_powerclamp(E) i8k(E) coretemp(E) kvm_intel(E) kvm(E) rfcomm(E)
bnep(E) crct10dif_pclmul(E) crc32_pclmul(E) snd_hda_codec_idt(E)
ghash_clmulni_intel(E) snd_hda_codec_generic(E) uvcvideo(E)
aesni_intel(E) videobuf2_vmalloc(E) aes_x86_64(E) videobuf2_memops(E)
lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) videobuf2_core(E)
cryptd(E) snd_hda_intel(E) v4l2_common(E) snd_hda_controller(E)
videodev(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) joydev(E)
serio_raw(E) snd_pcm(E) media(E) ath3k(E) snd_seq_midi(E)
snd_seq_midi_event(E) btusb(E) btbcm(E) snd_rawmidi(E) btintel(E)
bluetooth(E) snd_seq(E) lpc_ich(E) snd_seq_device(E) snd_timer(E)
dell_smo8800(E) mac_hid(E) snd(E) mei_me(E) soundcore(E) shpchp(E)
mei(E) binfmt_misc(E) parport_pc(E) ppdev(E) lp(E) parport(E)
nouveau(E) mxm_wmi(E) i915(E) ttm(E) i2c_algo_bit(E) drm_kms_helper(E)
e1000e(E) sdhci_pci(E) ahci(E) ptp(E) sdhci(E) psmouse(E) libahci(E)
(Continue reading)

Kalle Valo | 21 May 09:40 2015

Re: [PATCH] amth10k: fix promisc handling

Adding John as this involved wireless-testing

Michal Kazior <michal.kazior@...> writes:

> On 12 May 2015 at 14:45, Michal Kazior <michal.kazior@...> wrote:
>> Patch df1404650ccb ("mac80211: remove support for
>> IFF_PROMISC") removed promiscuous flag propagation
>> to drivers.
>> However the patch was designed against ath10k
>> without 548462133d98 ("ath10k: fix interrupt
>> storm").
>> After merge the code drifted into being no longer
>> correct and due to monitor vdev being
>> overzealously started caused IBSS to crash on
>> 999.999.0.636 for QCA988X (this firmware revision
>> is known to have issues with monitor vdev).
>> This patch keeps expectations of commit
>> 548462133d98 (i.e. reduce irq storm by not
>> enabling monitor vdev for AP) and doesn't break
>> existing (known) setups that imply promiscuous
>> mode on network interfaces.
>> Contrary to what it looks like 548462133d98
>> functionality is not reverted since the intention
>> was a subset of what df1404650ccb did.
>> Fixes: c17c997d5613 ("Merge git://")
(Continue reading)

Rafał Miłecki | 20 May 20:10 2015

[PATCH] brcmfmac: allow NVRAM values to contain space and '#' chars

Both chars often require special handling (and brcmf_nvram_handle_idle
already takes care of them) but they should be allowed when parsing
entry value. Some example entries from SR400ac device NVRAM:

Signed-off-by: Rafał Miłecki <zajec5@...>
 drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
index 45d7191..64e2491 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
 <at>  <at>  -66,14 +66,15  <at>  <at>  struct nvram_parser {
 	bool multi_dev_v2;

-static bool is_nvram_char(char c)
+ * is_printable_char() - check if char is ASCII printable one
+ *
+ * Please note that '#' may require different handling depending on the context.
+ * It's used as comment beginning and it's not allowed in key name.
+ */
+static bool is_printable_char(char c)
-	/* comment marker excluded */
-	if (c == '#')
(Continue reading)

Larry Finger | 20 May 18:39 2015

Re: [PATCH] staging: rtl8712: prevent buffer overrun in recvbuf2recvframe

On 05/20/2015 01:17 AM, Haggai Eran wrote:
> On May 19, 2015 08:47, "Haggai Eran" <haggai.eran@...
> <mailto:haggai.eran@...>> wrote:
>  >
>  > With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
>  > packet are set, but the packet length is too large. Truncate the packet
>  > to prevent memory corruption.
>  >
>  > Signed-off-by: Haggai Eran <haggai.eran@... <mailto:haggai.eran@...>>
>  > ---
>  >
>  > Hi,
>  >
>  > I think this solves the issue for me. I'll test it more thoroughly later. I
>  > still don't know why a fragmented packet has such a large pkt_len value though.
>  >
>  > Thanks,
>  > Haggai
>  >
> I guess I was too quick with this patch. It prevents the kernel page faults, but
> with it I still see sometimes the connectivity disappear for a minute or two.

Is anything logged when that happens?

I'm still trying to see where that magic number of 1658 comes from, and how that 
affects the RX buffer size.

When I unconditionally set alloc_sz to tmp_len as in the attached patch (I 
remembered to refresh it this time), nothing bad has happened here yet. What 
(Continue reading)