Re: [PATCH v2] mac80211: mesh - always do every discovery retry

> They are only reliable when compared to individual rate controlled frames. > But, in general, they are most certainly not reliable. Even in a shielded > and conductive (i.e. with physical wires connecting antennas) environment > lost PREQ frames are not hard to see. Did you try to reduce

[PATCH] staging: wilc1000: Fix sparse warnings incorrect type assignment

Fixed sparse warnings drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2011:52: warning: incorrect type in assignment (different base types) drivers/staging/wilc1000//wilc_wfi_cfgoperations.c:2011:52:expected unsigned short [unsigned] [assigned] [usertype] ht_ext_params

Re: ath9k driver : Support for Continuous Test Tone mode

Hi Julien, Thanks so much for the pointers. I back ported the patch at http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=89f927af7f3389e20c8ad24abfb3d1369f3ffc10 to the 3.12 kernel. Now able to set the tx99 mode and configure the moni0 interface. But I am not seeing any

RE: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

> > Well it certainly attempts to via stuff like carrier sense. But that > > is not fool proof and any time two routers hear a frame and both > > decide to forward it immediately there is a chance that they will both > > sense the air at the same time, decide that it is clear, and lose both > >

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

Am 06.03.2017 um 22:51 schrieb Johannes Berg: >> I realized I also have a Win10 installation on that machine - and may >> as well try WoWLAN with it. >> Enabling (in the dreaded device manager) wake via the WiFi device, >> magic packet mode, I also cannot wake the machine. > > Ok. I didn't even

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

Am 06.03.2017 um 09:11 schrieb Johannes Berg: > On Sun, 2017-03-05 at 16:12 +0100, Oliver Freyermuth wrote: > > [snip] > >> With tcp-mode, and using the small testing code I found from you >> somewhere on the web: >> https://bugs.chromium.org/p/chromium/issues/detail?id=361435#c21 >> indeed I

[PATCH] mac80211: ignore VHT membership selector when parsing rates

From: Johannes Berg There isn't really much harm in not ignoring, since it doesn't represent a valid rate, but since we already ignore the HT one also ignore VHT. Also simplify the code a bit. Signed-off-by: Johannes Berg ---

[PATCH 3/3] mac80211: remove ieee80211_tx_rate_control.max_rate_idx

From: Johannes Berg As promised a little more than 7 years ago, remove it now since nothing uses it anymore. Signed-off-by: Johannes Berg --- include/net/mac80211.h | 4 net/mac80211/tx.c | 8 2 files changed, 12

[PATCH 1/3] iwlegacy: remove usage of txrc->max_rate_idx

From: Johannes Berg Just calculate it like mac80211 does today, so we can get rid of the calculation in mac80211 for everyone else. Signed-off-by: Johannes Berg --- drivers/net/wireless/intel/iwlegacy/3945-rs.c | 2 +-

[PATCH 2/3] iwlwifi: dvm: remove usage of txrc->max_rate_idx

From: Johannes Berg Just calculate it like mac80211 does today, so we can get rid of the calculation in mac80211 for everyone else. Signed-off-by: Johannes Berg --- drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 2 +- 1 file changed, 1

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

> > Agree, nothing looks bad. Try running "iw event" while you suspend > > - if > > the NIC thought it woke up the system there will be an event > > indicating > > so. > > > > Indeed, I get: > 1488836432.153465: wlan0 (phy #0): WoWLAN wakeup > * packet (might be truncated): >

Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

On Mon, Mar 6, 2017 at 5:19 PM, Kalle Valo wrote: > Arend Van Spriel writes: > >> On 2-3-2017 17:38, Arnd Bergmann wrote: >>> With KASAN and a couple of other patches applied, this driver is one >>> of the few remaining ones that actually use

Re: [PATCH v4] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

Two more comments. Please note I don't find these things critical, this would be fine to fix them in incremental patch for me. On 01/09/2017 10:07 AM, igor.mitsyanko...@quantenna.com wrote: > +static int qtnf_core_mac_init(struct qtnf_bus *bus, int macid) > +{ > + struct qtnf_wmac *mac; > +

Re: [PATCH v4] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

On 01/09/2017 10:07 AM, igor.mitsyanko...@quantenna.com wrote: From: Igor Mitsyanko This patch adds support for new FullMAC WiFi driver for Quantenna QSR10G chipsets. QSR10G (aka Pearl) is Quantenna's 8x8, 160M, 11ac offering. QSR10G supports 2 simultaneous

RE: [PATCH v2] mac80211: mesh - always do every discovery retry

> >> Well A-D is going to have a much smaller RTT than A-B-C-D. And, yes, > >> using multiple hops is going to reduce throughput but I'd much rather > >> use multiple > >> 120 Mbps links than a link that only supports 12 Mbps. > >> > > > > Airtime link metrics should choose the multiple links if

Re: [PATCH 10/26] brcmsmac: reindent split functions

Arend Van Spriel writes: > On 2-3-2017 17:38, Arnd Bergmann wrote: >> In the previous commit I left the indentation alone to help reviewing >> the patch, this one now runs the three new functions through 'indent -kr -8' >> with some manual fixups to avoid silliness.

Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

Arend Van Spriel writes: > On 2-3-2017 17:38, Arnd Bergmann wrote: >> With KASAN and a couple of other patches applied, this driver is one >> of the few remaining ones that actually use more than 2048 bytes of >> kernel stack: >> >>

Re: [PATCH] 4.9.13 brcmfmac: fix use-after-free on resume

On 6 March 2017 at 21:00, Arend Van Spriel wrote: > + linux-wireless > > On 6-3-2017 8:14, Daniel J Blueman wrote: >> KASAN reported 'struct wireless_dev wdev' was read after being freed. >> Fix by freeing after the access. > > I would rather like to see the KASAN

[PATCH v3] cfg80211: add set/get link loss profile

>From ca61946032a47c8daf1b9013de9f4c72c6e7aaaf Mon Sep 17 00:00:00 2001 From: Alexei Avshalom Lazar Date: Mon, 6 Mar 2017 15:47:08 +0200 Subject: [PATCH] cfg80211: add set/get link loss profile Introduce NL80211_CMD_SET_LINK_LOSS_PROFILE and

Re: cfg80211: add set/get link loss profile

On 1/2/2017 12:45 PM, Johannes Berg wrote: > On Mon, 2016-12-19 at 12:58 +0200, Lazar, Alexei Avshalom wrote: > >>> What you're doing here is *extremely* vague. No definitions of what >>> this means, no description of how it's intended to be implemented, >>> no note even on whether or not this is

Re: [PATCH v2 1/4] mac80211-hwsim: notify user-space about channel change.

> + * @HWSIM_ATTR_CH_FREQ1: Configured center-freq-1. CENTER_FREQ1 might be better? CH will be equated with "channel", and that's kinda wrong. johannes

Re: [PATCH v2 1/4] mac80211-hwsim: notify user-space about channel change.

> + if (nla_put_u32(skb, HWSIM_ATTR_CH_FREQ2, data- > >center_freq2)) > + goto nla_put_failure; I'd prefer this to be conditional on it being non-zero. I'd have fixed it, but none of these patches apply cleanly to my tree. johannes

ANNOUNCE: New talk accepted on IO no Things

The tech committee would like to announce a new accepted talk. Alexander Aring will give a talk on IOT _without the things_ ;-> Building virtual 6LoWPAN Mesh Networks Details on the talk: Operating IEEE 802.15.4 6LoWPAN IOT networks often requires to deal with lossy wireless connections.

Atheros ath9k superchannel

hi, I am reading ath9k code. And try use superchannel (2312 ~ 2732) on openwrt. I have successfully opened these channels, and verified by mikrotik. But when use hostapd on these superchannel , ath9k can not send out any packets. A large number of Global Tx Timeout (GTT) and Carrier Sense Timeout

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

On Mon, 2017-03-06 at 13:25 +0100, Johannes Berg wrote: > On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote: > > From: Ondřej Lysoněk > > > > Use setup_timer() and setup_deferrable_timer() to set the data and > > function timer fields. It makes the code cleaner and

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote: > From: Ondřej Lysoněk > > Use setup_timer() and setup_deferrable_timer() to set the data and > function timer fields. It makes the code cleaner and will allow for > easier change of the timer struct internals.

Re: [RFC] mac80211_hwsim: report survey data for scanned channels

On Sat, 2017-03-04 at 11:10 +0200, Jouni Malinen wrote: > On Tue, Feb 21, 2017 at 11:31:18AM +0100, Johannes Berg wrote: > > Currently, hwsim is reporting survey data (only a fake noise floor) > > for the current channel. This breaks when the multi-channel support > > is enabled since then there's

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote: > From: Ondřej Lysoněk > > Use setup_timer() and setup_deferrable_timer() to set the data and > function timer fields. It makes the code cleaner and will allow for > easier change of the timer struct internals. Btw,

Re: [PATCH] 4.9.13 brcmfmac: fix use-after-free on resume

+ linux-wireless On 6-3-2017 8:14, Daniel J Blueman wrote: > KASAN reported 'struct wireless_dev wdev' was read after being freed. > Fix by freeing after the access. I would rather like to see the KASAN report, because something is off here. This function is called with wdev as a parameter so

Re: [PATCH V2 0/3] Pre-CAC and sharing DFS state across multiple radios

All three applied. johannes

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

> Well it certainly attempts to via stuff like carrier sense. But that > is not fool proof and any time two routers hear a frame and both > decide to forward it immediately there is a chance that they will > both sense the air at the same time, decide that it is clear, and > lose both their

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

> Not really. This is one of assignments for students I lead, so this > is done by hand every end of winter semester (Note the From line.) You really should teach them about coccinelle then :-) > > Care to send a patch for that one too? > > I am just a forwarder, he received this request too,

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

On 03/06/2017, 01:25 PM, Johannes Berg wrote: > On Fri, 2017-03-03 at 13:45 +0100, Jiri Slaby wrote: >> From: Ondřej Lysoněk >> >> Use setup_timer() and setup_deferrable_timer() to set the data and >> function timer fields. It makes the code cleaner and will allow for >>

Re: [PATCH] mac80211_hwsim: Add channel 169 (5845 MHz)

On Mon, 2017-03-06 at 11:56 +0200, Jouni Malinen wrote: > This channel is defined in the IEEE 802.11 standard and available in > number of countries, so extend the mac80211_hwsim channel list to > cover > channel 169 to enable additional testing. Makes sense, applied. johannes

[PATCH 3/4] mac80211: add ability to parse CCFS2

From: Johannes Berg With newer VHT implementations, it's necessary to look at the HT operation's CCFS2 field to identify the actual bandwidth used. Signed-off-by: Johannes Berg --- net/mac80211/ibss.c| 4 +++-

[PATCH 1/4] ieee80211: add new VHT capability fields/parsing

From: Johannes Berg IEEE 802.11-2016 extended the VHT capability fields to allow indicating the number of spatial streams depending on the actually used bandwidth, add support for decoding this. Signed-off-by: Johannes Berg ---

[PATCH 4/4] mac80211: copy VHT EXT NSS BW Support/Capable data to station

From: Johannes Berg When taking VHT capabilities for a station, copy the new fields if we support them as a transmitter. Also adjust the maximum bandwidth the station supports appropriately. Also, since it was missing, copy tx_highest and rx_highest. Signed-off-by:

[PATCH 2/4] mac80211: introduce capability flags for VHT EXT NSS support

From: Johannes Berg Depending on whether or not rate control supports selecting rates depending on the bandwidth, we can use VHT extended NSS support. In essence, this is dot11VHTExtendedNSSBWCapable from the spec, since depending on that we'll need to parse the

[PATCH] mac80211_hwsim: Add channel 169 (5845 MHz)

This channel is defined in the IEEE 802.11 standard and available in number of countries, so extend the mac80211_hwsim channel list to cover channel 169 to enable additional testing. Signed-off-by: Jouni Malinen --- drivers/net/wireless/mac80211_hwsim.c | 1 + 1 file

Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

On Mon, Mar 6, 2017 at 12:16 PM, Arnd Bergmann wrote: > On Mon, Mar 6, 2017 at 12:02 PM, Arend Van Spriel > wrote: >> On 6-3-2017 11:38, Arnd Bergmann wrote: >>> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel >>>

Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

On Mon, Mar 6, 2017 at 12:02 PM, Arend Van Spriel wrote: > On 6-3-2017 11:38, Arnd Bergmann wrote: >> On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel >> wrote: >>> On 2-3-2017 17:38, Arnd Bergmann wrote: The

Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

On 6-3-2017 11:38, Arnd Bergmann wrote: > On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel > wrote: >> On 2-3-2017 17:38, Arnd Bergmann wrote: >>> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put >>> an object >>> on the stack, which will

Re: [4.9.13] brcmf use-after-free on resume

+ linux-wireless On 6-3-2017 8:04, Daniel J Blueman wrote: > When resuming from suspend with a BCM43602 on Ubuntu 16.04 with > 4.9.13, we see use after free [1]. > > We see the struct cfg80211_ops is accessed in the resume path, after > it was previously freed: > > (gdb) list

Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

On Mon, Mar 6, 2017 at 10:16 AM, Arend Van Spriel wrote: > On 2-3-2017 17:38, Arnd Bergmann wrote: >> The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an >> object >> on the stack, which will each require a redzone with KASAN and lead to >>

Re: [PATCH 07/26] brcmsmac: reduce stack size with KASAN

On 2-3-2017 17:38, Arnd Bergmann wrote: > The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an > object > on the stack, which will each require a redzone with KASAN and lead to > possible > stack overflow: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:

Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)

On Sun, 2017-03-05 at 16:12 +0100, Oliver Freyermuth wrote: [snip] > With tcp-mode, and using the small testing code I found from you > somewhere on the web: > https://bugs.chromium.org/p/chromium/issues/detail?id=361435#c21 > indeed I get: > "new client!" > after the machine has suspended.  >

Re: [PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy

On 2-3-2017 17:38, Arnd Bergmann wrote: > The stack consumption in this driver is still relatively high, with one > remaining warning if the warning level is lowered to 1536 bytes: > > drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: > the frame size of 1880 bytes is

Re: [PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

On 2-3-2017 17:38, Arnd Bergmann wrote: > With KASAN and a couple of other patches applied, this driver is one > of the few remaining ones that actually use more than 2048 bytes of > kernel stack: > > broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function > 'wlc_phy_workarounds_nphy_gainctrl': >