On Wed, 2017-04-26 at 12:05 +0200, Arend van Spriel wrote:
>
> > the mobility domain does not require new 802.1X authentication, but
> > roaming to another mobility domain does.
>
> Not sure about the terminology here. Is "mobility domain" the same
> as "ESS" which stands for extended service se
On Mon, 2017-05-01 at 11:40 +0200, Arend van Spriel wrote:
>
> So I will include this patch in my patchset for PSK/1X offloading
> taken above into account.
Great, thanks!
johannes
From: Johannes Berg
Replace @results_wk with @report_results, which was missed
in an earlier patch between revisions thereof.
Fixes: b34939b98369 ("cfg80211: add request id to cfg80211_sched_scan_*() api")
Signed-off-by: Johannes Berg
---
include/net/cfg80211.h | 2 +-
1 file
On Tue, 2017-05-02 at 13:42 +0100, Arend van Spriel wrote:
> Another change is the
> addition of the flag ATTR_WANT_1X_OFFLOAD that user-space has to pass
> in CONNECT request. Some drivers may need to be aware before the PMK
> is programmed through SET_PMK request.
That naming seems a bit questio
On Wed, 2017-05-03 at 10:10 +0200, Arend van Spriel wrote:
>
> I was asking because we do it for the keys:
correction: the *temporal* keys :)
> /*
>* Delete all the keys ... pairwise keys can't really
>* exist any more anyway, but default keys might.
>*/
> if
From: Johannes Berg
Linus reported hitting the bandwidth warning, but it is indeed
pretty useless - improve it by printing the rate configuration
and make it only warn once, for both warnings here.
Reported-by: Linus Torvalds
Signed-off-by: Johannes Berg
---
net/wireless/util.c | 11
Hi,
> Things still work, but when it starts warning, it generates a *lot*
> of noise (I got 36 of these within about ten minutes).
Yeah, that's kinda dumb - I just sent a patch to make that just warn
once and actually report the configuration.
> I have no idea what triggered it, because when I r
From: Johannes Berg
Due to the way I did the RX bitrate conversions in mac80211 with
spatch, going setting flags to setting the value, many drivers now
don't set the bandwidth value for 20 MHz, since with the flags it
wasn't necessary to (there was no 20 MHz flag, only the others.)
R
On Thu, 2017-05-04 at 11:13 -0400, David Miller wrote:
>
> Johannes, would you like me to merge this in via my tree directly?
I figured I'd give Linus to a chance to try or even apply it, but I
have no objection to you applying it either. I don't have anything else
yet right now, and sending a
> o Use explicit casts to proper types instead of casts to (void *)
> and have the compiler do the implicit cast
I see no advantage in this, why? All it does is make the code longer,
and if anything changes, you have to change it in multiple places now.
johannes
On Fri, 2017-05-05 at 02:34 -0700, Joe Perches wrote:
> On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > > o Use explicit casts to proper types instead of casts to (void *)
> > > and have the compiler do the implicit cast
> >
> > I see no advantage
From: Johannes Berg
Somehow I missed this in my RX rate cleanup series, causing some
drivers to not report correct bandwidth since this flag isn't
used by mac80211 anymore. Fix this, and make hwsim also report
higher bandwidths appropriately.
Signed-off-by: Johannes Berg
---
driver
://bugzilla.kernel.org/show_bug.cgi?id=195299
Signed-off-by: Luca Coelho
Signed-off-by: Johannes Berg
---
net/mac80211/mlme.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 89dff563b1ec..0ea9712bd99e 100644
--- a/net/mac80211/mlme.c
+++ b/net
From: Johannes Berg
When VHT IBSS support was added, the size of the extra elements
wasn't considered in ieee80211_ibss_build_presp(), which makes
it possible that it would overrun the allocated buffer. Fix it
by allocating the necessary space.
Fixes: abcff6ef01f9 ("mac80211: add V
From: Johannes Berg
Since groups 0 and 63 are invalid, we should check for those bits.
Note that the 802.11 spec specifies the *bit* order, but the CPU
doesn't care about bit order since it can't address bits, so it's
always treating BIT(0) as the lowest bit within a byte.
R
for a recently merged change
* fix MU-MIMO group configuration (relevant only for monitor mode)
* more rate flags fix: remove stray RX_ENC_FLAG_40MHZ
* fix IBSS probe response allocation size
----
Johannes Berg (4):
mac80211:
On Tue, 2017-05-09 at 09:50 +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 8 May 2017 22:22:04 +0200
>
> Five single characters (line breaks) should be put into a sequence.
> Thus use the corresponding function "seq_putc".
Please stop, this isn't really an issue worth worryi
On Tue, 2017-05-09 at 14:16 -0400, Michael Skeffington wrote:
> In order to allow wpa_supplicant to correctly identify a perceived
> WPA TKIP key
> recovery attack the michael MIC must be checked before the packet
> decode is
> attempted. A packet with an invalid MIC will always fail a decrypt
> c
On Thu, 2017-05-11 at 16:22 -0400, Michael Skeffington wrote:
> I am using an rt5350 SoC using the rt2x00 driver. We were doing
> WiFi-alliance certification testing on our device and the it wasn't
> issuing countermeasures appropriately.
>
> Your assumption is correct. I had overlooked that dev
On Tue, 2017-05-16 at 13:55 +0200, Stanislaw Gruszka wrote:
>
> In rt2x00 driver we use poor convention in other kind of registers
> accessors like bbp, mac, eeprom. I dislike to changing only rfcsr
> accessors and leaving others in the old way. And changing all
> accessors would be massive and er
On Tue, 2017-05-16 at 15:57 -0400, Michael Skeffington wrote:
> Johannes,
>
> Thank you for that. I need to make a quick hack to send an invalid
> MIC packet from another device to test the countermeasures. Should I
> submit a new patch with this change when I've completed testing or
> are you a
On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:
> > > Now for N900 case there is a similar scenario
> > > alhtough it has additional requirement to go to user-space due to
> > > need to use a proprietary library to obtain the NVS calibration
> > > data. My thought: Why should firmware_c
On Sun, 2017-05-14 at 21:41 -0700, Rajkumar Manoharan wrote:
> Mesh forwarding path checks for address extension mode to fetch
> appropriate proxied address and MPP address. Existing condition
> that looks for 6 address format is not strict enough so that
> frames with improper values are processed
On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> > In fact, why should the *driver* care either? IOW - why should
> > "request_firmware_prefer_user()" even exist?
>
> There are default/example NVS data, which are stored in /lib/firmware
> and installed by linux-firmware package.
[...]
Oh,
Good job :)
Let's merge this - the tiny fixes for things I found can come later.
Some (mostly trivial) comments:
* I'm surprised you don't support WEP - nice :)
* I don't think returning -EFAULT from qtnf_add_virtual_intf is a good
idea - perhaps better propagate the error or use -EIO?
* t
On Thu, 2017-05-04 at 13:13 +, Kalle Valo wrote:
>
> > > This code intentionally checked if TX status was requested, and
> > > if not then it doesn't go to the effort of building it.
> > >
> >
> > What I'm finding puzzling is the fact that the only caller of
> > ieee80211_led_tx() is ieee802
Hi Arend,
Sorry for the long delay.
> I bumped into use of wdev_lock() again with 802.1X 4-way-hs offload
> stuff. So for .set_pmk() and .del_pmk() it takes wdev_lock(). Is
> there a rule of thumb when this lock is needed. What is it
> protecting in general and in the case of pmk configuration
On Wed, 2017-05-17 at 15:21 +0200, Pali Rohár wrote:
> On Wednesday 17 May 2017 15:04:50 Johannes Berg wrote:
> > On Wed, 2017-05-17 at 14:53 +0200, Pali Rohár wrote:
> >
> > > > In fact, why should the *driver* care either? IOW - why should
> > > > &quo
On Wed, 2017-05-17 at 12:08 +0200, Bastian Bittorf wrote:
> * Ben Greear [17.05.2017 11:51]:
> > I have been keeping an 'iw events' program running with a perl
> > script gathering its
> > output and post-processing it. This has been working for several
> > years on 4.7 and earlier
> > kernels, b
On Fri, 2017-05-12 at 17:11 +0300, Sergey Naumov wrote:
> Hi All.
>
> I see that since iw-4.x "iw reg get" reports multiple region
> information - per-phy and global. Moreover, per-phy information could
> be marked as "self-managed".
That's also dependent on the kernel.
> Could somebody clarify
On Fri, 2017-05-12 at 16:51 +0300, Kalle Valo wrote:
>
> But this does not mean that the gates are open for all possible hacks
> via vendor commands, we still want to have generic nl80211 interface
> for all normal functionality. Just to give some examples of something
> which is NOT acceptable:
On Wed, 2017-03-29 at 18:33 +0800, Chun-Yeow Yeoh wrote:
> I would suggest the following modification of commit messages and
> code. Let me know whether this is fine.
>
> -
> I would suggest the following edition to the commit message:
>
> Instead of stopping path discovery when a path is
On Thu, 2017-04-06 at 11:38 +0200, Toke Høiland-Jørgensen wrote:
> CoDel can be too aggressive if a station sends at a very low rate,
> leading reduced throughput. This gets worse the more stations are
> present, as each station gets more bursty the longer the round-robin
> scheduling between stati
Hi,
I think this looks really good. One thing though:
> Another change is the
> addition of the flag ATTR_WANT_1X_4WAY_HS that user-space has to pass
> in CONNECT request. Some drivers may need to be aware before the PMK
> is programmed through SET_PMK request.
I wonder how we really should do t
From: Johannes Berg
Similar to the ancient commit a5fe8e7695dc ("regulatory: add NUL
to alpha2"), add another byte to alpha2 in the request struct so
that when we use nla_put_string(), we don't overrun anything.
Fixes: 73d54c9e74c4 ("cfg80211: add regulatory netlink multic
ection
Felix Fietkau (1):
mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4
Ilan Peer (2):
mac80211: Do not disconnect on invalid operating class
mac80211: Fix sending ADDBA response for an ongoing session
Johannes Berg (3):
cfg80211: use only 1Mbps for bas
wsim: add generation count for netlink dump operation
Colin Ian King (1):
mac80211: remove redundant initialization to pointer 'hdr'
Denis Kenzior (1):
uapi: Add 802.11 Preauthentication to if_ether
Ilan Peer (1):
mac80211: Call mgd_prep_tx before transmitting deau
On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote:
> From: Johannes Berg
> Date: Thu, 22 Feb 2018 21:16:18 +0100
>
> > Wireless is slow ... but we're preparing for HE (802.11ax),
> > so I guess soon we'll have a big chunk of work coming :-)
>
> I won
Hey,
Hadn't really followed this discussion much due to other fires
elsewhere :-)
On Fri, 2018-02-23 at 11:39 +0100, Arend van Spriel wrote:
> > > Well, that depends on the eye of the beholder I guess. From user-space
> > > perspective it is asynchronous regardless. A write access to the coredum
On Fri, 2018-02-23 at 10:06 +0100, Felix Fietkau wrote:
> Signed-off-by: Felix Fietkau
> ---
> net/mac80211/cfg.c | 2 --
> net/mac80211/rx.c | 11 +++
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 6f9d5beec73e..72b5
I've applied 1 to mac80211, and 2/3 to mac80211-next, so please only
resend 4, unless you can convince me it's OK as is :-)
johannes
On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote:
>
> Pulled, thank you!
Thanks. I just realized that I have a patch pending for -next that
depends another commit in net/mac80211 (or would otherwise conflict
badly while applying, and again while merging later), could I ask you
to pull net in
On Thu, 2018-02-22 at 12:15 +0300, Sergey Matyukevich wrote:
> From: Dmitry Lebed
>
> Add wiphy EXT_FEATURE flag to indicate that HW or driver does
> all DFS actions by itself.
> User-space functionality already implemented in hostapd using
> vendor-specific (QCA) OUI to advertise DFS offload sup
On Mon, 2018-02-26 at 10:15 +1300, Ben Caradoc-Davies wrote:
> This reverts commit 7b6ddeaf27eca72795ceeae2f0f347db1b5f9a30.
>
> The above commit causes an Atheros AR9271 ath9k_htc USB WiFi adapter
> connected to an AP with QoS/WME enabled to lose all IP connectivity after
> something like 10 to 9
I'm dropping the patches 11-13 from my list for now - please resend
with the additional fix I just submitted internally :-)
johannes
On Tue, 2018-02-27 at 08:52 +0100, Felix Fietkau wrote:
>
> if (fast_rx->key && !(status->flag & RX_FLAG_IV_STRIPPED)) {
> + if (status->rx_flags & IEEE80211_RX_AMSDU)
> + return false;
This seemed really odd to me.
> /* GCMP header length is t
On Tue, 2018-02-27 at 16:19 -0600, Seth Forshee wrote:
>
> I think it looks okay, but I guess there will be new patches so I will
> take another look then. Is there an example of the db.txt updates for
> the WMM rules?
I'm not sure we have a full db.txt update yet, but Haim definitely has
a patch
On Wed, 2018-02-28 at 15:26 +0100, Lorenzo Bianconi wrote:
>
> const int map_reads = DIV_ROUND_UP(MT_EFUSE_USAGE_MAP_SIZE, 16);
> - u8 data[map_reads * 16];
> + u8 data[round_up(MT_EFUSE_USAGE_MAP_SIZE, 16)];
>
You could turn it upside down and make
const int map_reads = ARRAY_SIZ
On Wed, 2018-02-28 at 17:01 +0100, Lorenzo Bianconi wrote:
> > On Wed, 2018-02-28 at 15:26 +0100, Lorenzo Bianconi wrote:
> > >
> > > const int map_reads = DIV_ROUND_UP(MT_EFUSE_USAGE_MAP_SIZE, 16);
> > > - u8 data[map_reads * 16];
> > > + u8 data[round_up(MT_EFUSE_USAGE_MAP_SIZE, 16
Hi,
Sorry I haven't answered/applied this. I will eventually, you've
convinced me with the answer.
> We are about to send v3 for this feature. Could you please clarify
> your preferences in terms of patchwork procedure ? Should we mark
> previous patch versions as superseded for nl80211/cfg80211
Hi,
> syzbot hit the following crash on upstream commit
> f3afe530d644488a074291da04a69a296ab63046 (Tue Feb 27 22:02:39 2018 +)
> Merge branch 'fixes-v4.16-rc4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
>
> So far this crash happened 4 times on upstream.
> Un
On Thu, 2018-03-01 at 13:32 +0100, Benjamin Beichler wrote:
>
> Could you give me a link to or forward the original email ? I googled
> "KASAN: use-after-free Read in mac80211_hwsim_del_radio", but only your
> answer (without the logs) appears. I try to have a look then in the next
> few days.
>
Hi Dave,
Like before... Thanks for pulling net into net-next, the Add-BA patch
below would otherwise not really be possible :-)
The only sort of interesting thing is the fast-RX improvements from
Felix, they help on routers where these things (A-MSDU and 4-addr mode)
are more important and where
Hi Dave,
Just a few more patches, but I'll be travelling over the next
week and probably won't be able to send things to you then.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 93c62c45ed5fad1b87e3a45835b251cd68de9c46:
rxrpc: Fix se
Hi Arend,
Sorry for the late reply - just returning from Israel now (in fact I'm
on the plane, but it has wifi).
While reworking brcmfmac I stumbled on debugfs code in cfg80211, which
creates the debugfs dir for the wiphy instance. It also creates a
couple of entries, ie. rts and fragmentatio
On Thu, 2018-03-15 at 14:57 +0530, Amitkumar Karwar wrote:
>
> > What I don't like here is that you are duplicating functionality
> > already
> > existing in mac80211 and I hope there is a better way to solve the
> > problem. Just as a a crazy idea what if the driver returns
> > -EOPNOTSUPP
> > wh
On Fri, 2018-03-16 at 15:45 +0100, Lorenzo Bianconi wrote:
> --- a/drivers/net/wireless/mediatek/mt76/Kconfig
> +++ b/drivers/net/wireless/mediatek/mt76/Kconfig
> @@ -1,5 +1,8 @@
> config MT76_CORE
> tristate
> + select MAC80211_LEDS
Should drivers really mess with mac80211's configurat
On Mon, 2018-03-05 at 20:07 +0530, Amitkumar Karwar wrote:
> From: Siva Rebbagondla
>
> This patch adds a check to drop received broadcast/multicast frames
> if
> PN is invalid (i.e. not greater than last PN). bc_mc_pn
> variable added for each interface
>
Can you say why you do this rather than
On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
> Currently autodisconnect_wk assumes that only interface types of
> P2P_CLIENT and STATION use conn_owner_nlportid. Change this so all
> interface types are supported.
Hmm. This sort of duplicates cfg80211_leave() for the most part, apart
f
On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
>
> + if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]) {
> + if (!info->attrs[NL80211_ATTR_SOCKET_OWNER])
> + return -EINVAL;
>
There might be value in adding GENL_SET_ERR_MSG() calls to new
instan
On Fri, 2018-03-09 at 11:57 +0530, mpubb...@codeaurora.org wrote:
> From: Manikanta Pubbisetty
>
> Extending SW_CRYPTO_CONTROL interface so that drivers can advertise
> the interface types on which they can support software encryption.
> Driver's job is not done by advertising the supported vif t
On Tue, 2018-03-20 at 16:52 -0700, Pradeep Kumar Chitrapu wrote:
> It is required to pass the rate information to driver/firmware
> when rate control is offloaded to firmware. This helps in changing
> multicast traffic rates thereby improving the network performance.
Looks like there are two more
From: Johannes Berg
OR'ing in 0x40 before a memcpy() to overwrite the value doesn't
do much good - flip the order of operations are reported and
tested by Jouni.
Fixes: cb1a5bae5684 ("mac80211_hwsim: add permanent mac address option for new
radios")
Reported-by: Jouni Ma
On Thu, 2018-03-08 at 12:49 +0530, Balaji Pothunoori wrote:
> This patch is to display the average ack rssi for data
> frames. "avg ack signal" field diplay limited by host based on
> firmware capablities.
I no longer have a corresponding kernel patch pending, so this is
useless?
johannes
On Mon, 2018-03-19 at 12:57 +1300, Ben Caradoc-Davies wrote:
> Commit 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing") adds an
> argument qos_ok to ieee80211_nullfunc_get to support QoS NDP. Despite
> the claim in the commit log "Change all the drivers to *not* allow
> QoS NDP for now, even th
e a hardware flag to allow such buggy drivers to override the
correct default behaviour of mac80211 of sending QoS NDP packets.
Signed-off-by: Ben Caradoc-Davies
Signed-off-by: Johannes Berg
---
include/net/mac80211.h | 4
net/mac80211/debugfs.c | 1 +
net/mac80211/mlme.c| 3 ++-
3 files c
From: Johannes Berg
When switching mac80211 to use QoS NDP, it turned out that
ath9k_htc is somehow broken by this, e.g. see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891060.
Fix this by using the new mac80211 flag to go back to the
old, incorrect, behaviour for this driver.
Fixes
So I really think this should just be one patch - it's not about
"registration semantics" but about which types of requests get passed
to reg_notifier(), and if you do it in one place you'd better also do
it in the other.
Secondly, this changes behaviour - not only for ath which presumably is
what
mac80211: add ieee80211_hw flag for QoS NDP support
Johannes Berg (1):
ath9k_htc: use non-QoS NDP for AP probing
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
drivers/net/wireless/mac80211_hwsim.c | 1 +
include/net/mac80211.h| 4
net/mac
On Wed, 2018-03-21 at 08:42 -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLAs and replace them
> with dynamic memory allocation instead.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be bot
On Wed, 2018-03-21 at 08:57 -0500, Gustavo A. R. Silva wrote:
>
> SHA_DESC_ON_STACK is currently being used in multiple places. But, yeah,
> I think we can define multiple macros of the same kind and adjust to the
> characteristics of each the component.
>
> How big do you think tfm can get?
I
On Wed, 2018-03-21 at 10:01 -0500, Denis Kenzior wrote:
> Hi Johannes,
>
> On 03/21/2018 02:47 AM, Johannes Berg wrote:
> > On Tue, 2018-03-13 at 16:59 -0500, Denis Kenzior wrote:
> > >
> > > + if (info->attrs[NL80211_ATTR_CONTROL_PORT_OVER_NL80211]
> TODO:
That was well-hidden :)
> - It is unclear to me how AP_VLAN and AP interfaces should synchronize on
> conn_owner_nlportid. This is required for tx_control_port to work.
I'm not really sure what you mean? Technically I guess an AP_VLAN could
have a different owner from an AP, but if the
On Wed, 2018-03-21 at 10:27 -0500, Denis Kenzior wrote:
>
> cfg80211_leave also messes with scans and autodisconnect_wk didn't. So
> I played it safe as I didn't want to introduce any silent semantic changes.
Makes sense, but we could pass an argument and avoid duplicating the
code?
> Also, cf
On Thu, 2018-03-22 at 11:51 +0530, mpubb...@codeaurora.org wrote:
>
> > So IMHO - just get rid of the bitmap and hard-code AP_VLAN.
> >
>
> I agree with you only partially.
>
> Today, I do not see any driver advertising SW_CRYPTO_CONTROL other than
> ath10k. There could be some driver which wo
On Wed, 2018-03-21 at 10:18 -0500, Denis Kenzior wrote:
>
> Sorry. I assumed people read the change log :)
And I should :-)
> > > - It is unclear to me how AP_VLAN and AP interfaces should synchronize on
> > > conn_owner_nlportid. This is required for tx_control_port to work.
> >
> > I'm not
On Wed, 2018-03-21 at 16:54 -0700, Pradeep Kumar Chitrapu wrote:
>
> index 4c99c13..4360765 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -336,6 +336,7 @@ enum ieee80211_bss_change {
> BSS_CHANGED_OCB = 1<<22,
> BSS_CHANGED_MU_GROUPS
On Thu, 2018-03-22 at 11:44 +0100, Arend van Spriel wrote:
> I recall a similar attempt for another driver, but I think the timestamp
> should really be the TSF of the beacon/proberesp received. As you
> already Cc-ed Johannes explicitly maybe he can clarify what is needed
> here as I do not rec
Hi,
> Okay, that makes things easier. However, it does bring up a
> question. Should we be symmetric and remove AP_VLAN as a valid target
> of control port frames? E.g. drop NL80211_IFTYPE_AP_VLAN case in
> patch 2 of the series. In effect we'd require all control port
> frame traffic to go
Hi,
>From a completely different angle than what James just said, are you
sure you're using the 7265 NIC for *only* monitor mode? This behaviour
would also be more or less consistent with the 7265 NIC being connected
to the AP that you're monitoring the beacons, since it would then
suppress beacon
>
> +static void ieee80211_update_rssi_config(struct
> ieee80211_sub_if_data *sdata)
> +{
> + if (!(sdata->vif.driver_flags &
> IEEE80211_VIF_SUPPORTS_CQM_RSSI))
> + return;
> +
> + /* tell the driver upon association, unless already
> associated */
> + if (sdata->vif.type
> +/*
> + * How many frames need to have been used in average station's
> + * signal strength before checking against the threshold
> + */
> +#define IEEE80211_STA_SIGNAL_AVE_MIN_COUNT 4
This seems OK - you want something to start up from?
However, I don't think we do that in "normal" CQM, and
On Sun, 2018-02-25 at 13:19 +0530, Tamizh chelvam wrote:
> From: Tamizh chelvam
>
> This patch extend cqm rssi config and notifier feature to AP mode
> by introducing NL80211_EXT_FEATURE_AP_STA_CQM_RSSI_CONFIG ext
> feature bit. And this patch introduces NL80211_MCGRP_AP_STA_CQM
> for notifying s
On Fri, 2018-03-23 at 19:11 +0530, ako...@codeaurora.org wrote:
>
> > > +
> > > + sinfo->expected_throughput =
> > > +
> > > ewma_sta_txrate_read(&arsta->ave_sta_txrate);
> > > + sinfo->filled |=
> > > BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
> > > +}
On Fri, 2018-03-23 at 11:02 -0400, Tyler Gray wrote:
> I'm positive we're just in monitor mode. [snip]
Ok, it was just a thought.
> To be clear, I'm not claiming I can set two devices up anywhere,
> anytime, and run this test and see huge gaps in beacons, but we've
> tested across multiple devic
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
>
> - * @set_noack_map: Set the NoAck Map for the TIDs.
> + * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not %NULL
> NoAck
> + * map will be applied for that particular peer. When peer is %NULL NoAck
> + * m
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
>
> + * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages noack
> + * policy handling. Hardware (or driver) takes care of setting
> + * noack policy in the qos header and does not wait for the ack based
> + *
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
>
> +u16 ieee80211_get_noack_map(struct ieee80211_sub_if_data *sdata, const u8
> *mac)
> +{
> + struct sta_info *sta;
> + u16 noack_map = 0;
> +
> + /* Retrieve per-station noack_map config for the receiver, if any */
On Tue, 2018-03-27 at 12:18 +0530, Tamizh chelvam wrote:
> Currently bw and smps_mode are u8 type value in sta_opmode_info
> structure. This values filled in mac80211 from ieee80211_sta_rx_bandwidth
> and ieee80211_smps_mode. These enum values are specific to mac80211 and
> userspace/cfg80211 doesn
On Mon, 2018-03-26 at 22:24 +0200, Alexander Wetzel wrote:
> There are quite many interesting things visible here, not the least one
> that ath9k leaks unencrypted frames for both patched and unpatched
> mac80211 which at least for my patched variant probably allow to
> calculate the TK key and en
On Sat, 2018-03-24 at 11:29 +0100, Alexander Wetzel wrote:
> Rekeying a pairwise key with encryption offload and only keyid 0 has two
> potential races which can freeze the wlan conection till rekeyed again:
>
> 1) For incomming packets:
> If the local STA installs the key prior to the remote
On Fri, 2018-03-23 at 20:20 +0530, Amitkumar Karwar wrote:
> > But maybe that's not really true at all? At least in one case it seems
> > you just kick off something called "bgscan".
>
> Yes. We have different scan implementations for device is connected
> and non-connected cases. In connected ca
On Sat, 2018-03-24 at 16:02 -0700, Quytelda Kahja wrote:
> The "document" refers to the file in which the changes were made
> ('include/linux/ieee80211.h').
You're the first person ever to do that, to my knowledge :)
Either way, I don't really want to merge this since it would break
staging, and
On Wed, 2018-03-28 at 13:29 +0530, vthia...@codeaurora.org wrote:
> On 2018-03-28 13:07, Arend van Spriel wrote:
> > On 3/28/2018 8:09 AM, vthia...@codeaurora.org wrote:
> > > On 2018-03-27 22:18, Steve deRosier wrote:
> > > > Hi Vasanthakumar,
> > > >
> > > > On Tue, Mar 27, 2018 at 1:42 AM, Vasa
> I think 0 as the Noack configuration from user can also be a valid one
> in the case
> where user does not want any NoAck policy to be used for a particular
> station even
> when a non-zero NoAck configuration is set for ndev level. In this case,
> the logic
> may need to be modified so that
On Wed, 2018-03-28 at 10:24 +0530, vthia...@codeaurora.org wrote:
> > The question is how that interacts with having enough space - are you
> > sure this is a concern?
>
> This will not be an issue at lest for ath10k. This is mainly for a
> (new)driver
> which implements the offload but has limi
On Wed, 2018-03-28 at 14:20 +0530, vthia...@codeaurora.org wrote:
>
> > Btw, we should probably also have a way to *delete* the per-station
> > configuration, so it uses the default again?
>
> Sure. How about setting it to default when the command is received with
> no NL80211_ATTR_NOACK_MAP att
On Wed, 2018-03-28 at 10:29 -0700, Peter Oh wrote:
> > + if (sdata->vif.type == NL80211_IFTYPE_AP)
> > + wmm_ac = &rrule->wmm_rule->ap[ac];
> > + else
> > + wmm_ac = &rrule->wmm_rule->client[ac];
> > + qparam->cw_min = max_t(u16, qparam->cw_min, wmm_ac->cw_min);
> > + qp
On Wed, 2018-03-28 at 13:24 +0300, Luca Coelho wrote:
>
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -135,12 +135,12 @@ static void restore_regulatory_settings(bool
> reset_user);
>
> static const struct ieee80211_regdomain *get_cfg80211_regdom(void)
> {
> - return rtnl_dere
On Thu, 2018-03-29 at 10:55 +0200, Arend van Spriel wrote:
>
> > No, the regulations say you have to use a long content window, hence
>
> Guess you mean "contention window" :-p
Heh, yes.
> > limiting both min and max at the lower end (hence max_t).
>
> Do you have any reference to the new ETSI
301 - 400 of 4576 matches
Mail list logo
