* Re: [PATCH 1/8] mwifiex: prevent register accesses after host is sleeping
From: Brian Norris @ 2016-10-04 22:20 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
Hi,
On Wed, Sep 28, 2016 at 06:18:21PM +0530, Amitkumar Karwar wrote:
> Following is mwifiex driver-firmware host sleep handshake.
> It involves three threads. suspend handler, interrupt handler, interrupt
> processing in main work queue.
>
> 1) Enter suspend handler
> 2) Download HS_CFG command
> 3) Response from firmware for HS_CFG
> 4) Suspend thread waits until handshake completes(i.e hs_activate becomes
> true)
> 5) SLEEP from firmware
> 6) SLEEP confirm downloaded to firmware.
> 7) SLEEP confirm response from firmware
> 8) Driver processes SLEEP confirm response and set hs_activate to wake up
> suspend thread
> 9) Exit suspend handler
> 10) Read sleep cookie in loop and wait until it indicates firmware is
> sleep.
> 11) After processing SLEEP confirm response, we are at the end of interrupt
> processing routine. Recheck if there are interrupts received while we were
> processing them.
>
> During suspend-resume stress test, it's been observed that we may end up
> acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads
> to a kernel crash.
>
> This patch solves the problem with below changes.
> a) action 10 above can be done before 8
> b) Skip 11 if hs_activated is true. SLEEP confirm response
> is the last interrupt from firmware. No need to recheck for
> pending interrupts.
> c) Add flush_workqueue() in suspend handler.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 3c3c4f1..2833d47 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -118,6 +118,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
> adapter = card->adapter;
>
> hs_actived = mwifiex_enable_hs(adapter);
> + flush_workqueue(adapter->workqueue);
>
> /* Indicate device suspended */
> adapter->is_suspended = true;
> @@ -1669,9 +1670,6 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter)
>
> if (!adapter->curr_cmd) {
> if (adapter->ps_state == PS_STATE_SLEEP_CFM) {
> - mwifiex_process_sleep_confirm_resp(adapter, skb->data,
> - skb->len);
> - mwifiex_pcie_enable_host_int(adapter);
> if (mwifiex_write_reg(adapter,
> PCIE_CPU_INT_EVENT,
> CPU_INTR_SLEEP_CFM_DONE)) {
> @@ -1684,6 +1682,9 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter)
> while (reg->sleep_cookie && (count++ < 10) &&
> mwifiex_pcie_ok_to_access_hw(adapter))
> usleep_range(50, 60);
> + mwifiex_pcie_enable_host_int(adapter);
> + mwifiex_process_sleep_confirm_resp(adapter, skb->data,
> + skb->len);
> } else {
> mwifiex_dbg(adapter, ERROR,
> "There is no command but got cmdrsp\n");
> @@ -2322,6 +2323,8 @@ static int mwifiex_process_pcie_int(struct mwifiex_adapter *adapter)
> ret = mwifiex_pcie_process_cmd_complete(adapter);
> if (ret)
> return ret;
> + if (adapter->hs_activated)
> + return ret;
> }
>
> if (card->msi_enable) {
>
^ permalink raw reply
* Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister
From: Brian Norris @ 2016-10-04 21:58 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, Xinming Hu
In-Reply-To: <1475600905-2997-1-git-send-email-akarwar@marvell.com>
Hi,
On Tue, Oct 04, 2016 at 10:38:24PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> card->adapter gets initialized during device registration.
> As it's not cleared, we may end up accessing invalid memory
> in some corner cases. This patch fixes the problem.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Same as v1
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 1 +
> drivers/net/wireless/marvell/mwifiex/sdio.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index f1eeb73..ba9e068 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
> pci_disable_msi(pdev);
> }
> }
> + card->adapter = NULL;
I think you have a similar problem here as in patch 2; there is no
locking to protect fields in struct pcie_service_card or struct
sdio_mmc_card below. That problem kind of already exists, except that
you only write the value of card->adapter once at registration time, so
it's not actually unsafe. But now that you're introducing a second
write, you have a problem.
Brian
> }
>
> /* This function initializes the PCI-E host memory space, WCB rings, etc.
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index 8718950..4cad1c2 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -2066,6 +2066,7 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
> struct sdio_mmc_card *card = adapter->card;
>
> if (adapter->card) {
> + card->adapter = NULL;
> sdio_claim_host(card->func);
> sdio_disable_func(card->func);
> sdio_release_host(card->func);
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: M. Braun @ 2016-10-04 21:57 UTC (permalink / raw)
To: Johannes Berg
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
linux-wireless, projekt-wlan
In-Reply-To: <1475570219.5324.28.camel@sipsolutions.net>
> * pass both for IBSS mode (I think)
two more aspects for IBSS
1. the PSK is shared by all stations, so a passive attacker on any
authenticated station in range will be able to derive it, right?
2. iff at all the source mac might be used for access control so
a TA==SA A-AMSDU filter might still be reasonable.
Michael
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: M. Braun @ 2016-10-04 21:12 UTC (permalink / raw)
To: Johannes Berg
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
linux-wireless, projekt-wlan
In-Reply-To: <1475570219.5324.28.camel@sipsolutions.net>
> Obviously, now that I think about it, your patch also would break
> client mode since it would refuse to accept any A-MSDU with SA != TA,
> which is highly unlikely in most cases, since traffic doesn't usually
> originate from the AP.
I still don't think my patch would break anything here, as it does only
filter on AP/AP_VLAN interfaces so stations are not affected at all.
I agree that asking for more cases to be filtered seems natural. But is
fixing all possible A-MSDU address mismatch problems required to fix the
one I currently care about most?
> We verify today that only multicast frames can be encrypted with the
> GTK, but that applies to the outer header, so we're susceptible to a
> variant of the hole-196 attack, afaict?
That exploited that an unicast arp reply can be injected using GTK, thus
bypassing AP filtering, right?
To counter, it would suffice to required multicast A-MSDU frames to only
carry multicast (inner) MSDUs?
I don't see how this could be inversed, that is an attack exploiting
multicast encrypted with PTK.
> Overall, it seems to me we should do the following:
I'm wondering if all this filtering is actually required or if it
filters out more than required?
> * pass DA == RA for client mode (not when 4-addr)
If this implies that encapsulating multicast as unicast A-MSDU is not
permitted, then why? This would break multicast to unicast using A-MSDU
frames, which currently works with most clients for me.
In order to fully counter hole-196, one has to remove the shared key
property of GTK. That is, each multicast packet is send once for each
station using a different encryption key. This currently is slow due to
multicast rate and makes each station wake up and receive each copy of
the multicast frame, including all those it cannot decrypt.
Using A-MSDU based multicast to unicast, these effects can be mitigated
regardless of packet payload type by using faster unicast transmissions
instead, as the wireless stack is supposed to restore the original
(inner) frame.
> * pass both on TDLS links
I don't know why TDLS links should carry multicast at all, so this seems
reasonable to me.
> * pass both for IBSS mode (I think)
Why is multicast to unicast not permitted within IBSS?
Hole-196 does not really seem to apply, as we're lacking the AP filter
rules to be bypassed anyway?
michael
^ permalink raw reply
* Re: [PATCH v2 2/2] mwifiex: check hw_status in suspend and resume handlers
From: Brian Norris @ 2016-10-04 21:04 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, Xinming Hu
In-Reply-To: <1475600905-2997-2-git-send-email-akarwar@marvell.com>
Hi,
On Tue, Oct 04, 2016 at 10:38:25PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> We have observed a kernel crash when system immediately suspends
> after booting. There is a race between suspend and driver
> initialization paths.
> This patch adds hw_status checks to fix the problem
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Return failure in suspend/resume handler in this scenario.
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index ba9e068..fa6bf85 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -122,9 +122,10 @@ static int mwifiex_pcie_suspend(struct device *dev)
>
> if (pdev) {
> card = pci_get_drvdata(pdev);
> - if (!card || !card->adapter) {
> + if (!card || !card->adapter ||
> + card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
Wait, is there no locking on the 'hw_status' field? That is inherently
an unsafe race all on its own; you're not guaranteed that this will be
read/written atomically. And you also aren't guaranteed that writes to
this happen in the order they appear in the code -- in other words,
reading this flag doesn't necessarily guarantee that initialization is
actually complete (even if that's very likely to be true, given that
it's probably just a single-instruction word-access, and any prior HW
polling or interrupts likely have done some synchronization and can't be
reordered).
This is probably better than nothing, but it's not very good.
> pr_err("Card or adapter structure is not valid\n");
> - return 0;
> + return -EBUSY;
So the above cases all mean that the driver hasn't finished loading,
right?
!card => can't happen (PCIe probe() would have failed
mwifiex_add_card()), but fine to check
!card->adapter => only happens after patch 1; i.e., when tearing down
the device and detaching it from the driver
card->adapter->hw_status != MWIFIEX_HW_STATUS_READY => FW is not loaded
(i.e., in the process of starting or stopping FW?)
I guess all of those cases make sense to be -EBUSY.
> }
> } else {
> pr_err("PCIE device is not specified\n");
I was going to complain about this branch (!pdev) returning 0, since
that looked asymmetric. But this case will never happen, actually, since
to_pci_dev() is just doing struct offset arithmetic on struct device,
and struct device is never going to be NULL. It probably makes more
sense to just remove this branch entirely, but that's for another patch.
> @@ -166,9 +167,10 @@ static int mwifiex_pcie_resume(struct device *dev)
>
> if (pdev) {
> card = pci_get_drvdata(pdev);
> - if (!card || !card->adapter) {
> + if (!card || !card->adapter ||
> + card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
Same complaint, except if you've screwed up here, you probably already
screwed up in suspend().
Brian
> pr_err("Card or adapter structure is not valid\n");
> - return 0;
> + return -EBUSY;
> }
> } else {
> pr_err("PCIE device is not specified\n");
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v3] mwifiex: report wakeup for wowlan
From: Rajat Jain @ 2016-10-04 20:37 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: Rajat Jain, Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain
In-Reply-To: <87vax8p9is.fsf@kamboji.qca.qualcomm.com>
Register the WLAN device as a wakeup source since it can
wake the system via wake-on-wireless-lan. In an actual wowlan
event, notify the PM core that we are the current wakeup source.
This allows the PM core to update the wakeup attributes in /sys.
This was causing wakeup issues on chromeos as the system was
apparently confused about the wakeup source.
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Signed-off-by: Rajat Jain <rajatja@google.com>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
---
v3: Fix the commit log
v2: Fix the commit log
drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index d3e1561..a5f63e4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void *priv)
disable_irq_nosync(irq);
}
+ /* Notify PM core we are wakeup source */
+ pm_wakeup_event(cfg->dev, 0);
+
return IRQ_HANDLED;
}
@@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
GFP_KERNEL);
cfg = card->plt_wake_cfg;
if (cfg && card->plt_of_node) {
+ cfg->dev = dev;
cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_wifi) {
dev_dbg(dev,
@@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device *dev, struct sdio_mmc_card *card)
}
}
+ ret = device_init_wakeup(dev, true);
+ if (ret)
+ dev_err(dev, "fail to init wakeup for mwifiex");
+
return 0;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h b/drivers/net/wireless/marvell/mwifiex/sdio.h
index db837f1..07cdd23 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -155,6 +155,7 @@
} while (0)
struct mwifiex_plt_wake_cfg {
+ struct device *dev;
int irq_wifi;
bool wake_by_wifi;
};
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 3/3] mac80211: multicast to unicast conversion
From: Michael Braun @ 2016-10-04 20:31 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan
In-Reply-To: <1475613109-17609-1-git-send-email-michael-dev@fami-braun.de>
This patch adds support for sending multicast data packets with ARP, IPv4 and
IPv6 payload (possible 802.1q tagged) as 802.11 unicast frames to all stations.
IEEE 802.11 multicast has well known issues, among them:
1. packets are not acked and hence not retransmitted, resulting in decreased
reliablity
2. packets are send at low rate, increasing time required on air
When used with AP_VLAN, there is another disadvantage:
3. all stations in the BSS are woken up, regardsless of their AP_VLAN
assignment.
By doing multicast to unicast conversion, all three issus are solved.
IEEE802.11-2012 proposes directed multicast service (DMS) using A-MSDU frames
and a station initiated control protocol. It has the advantage that the station
can recover the destination multicast mac address, but it is not backward
compatible with non QOS stations and does not enable the administrator of a BSS
to force this mode of operation within a BSS. Additionally, it would require
both the ap and the station to implement the control protocol, which is
optional on both ends. Furthermore, I've seen a few mobile phone stations
locally that indicate qos support but won't complete DHCP if their broadcasts
are encapsulated as A-MSDU. Though they work fine with this series approach.
This patch therefore does not opt to implement DMS but instead just replicates
the packet and changes the destination address. As this works fine with ARP,
IPv4 and IPv6, it is limited to these protocols and normal 802.11 multicast
frames are send out for all other payload protocols.
There is a runtime toggle to enable multicast conversion in a per-bss fashion.
When there is only a single station assigned to the AP_VLAN interface, no
packet replication will occur. 4addr mode of operation is unchanged.
This change opts for iterating all BSS stations for finding the stations
assigned to this AP/AP_VLAN interface, as there currently is no per AP_VLAN
list to iterate and multicast packets are expected to be few. If needed, such
a list could be added later.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--
v2: add nl80211 toggle
rename tx_dnat to change_da
change int to bool unicast
---
include/net/cfg80211.h | 5 ++
include/uapi/linux/nl80211.h | 7 +++
net/mac80211/cfg.c | 14 ++++++
net/mac80211/debugfs_netdev.c | 29 ++++++++++++
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/tx.c | 103 ++++++++++++++++++++++++++++++++++++++++++
net/wireless/nl80211.c | 33 ++++++++++++++
net/wireless/rdev-ops.h | 11 +++++
net/wireless/trace.h | 6 +++
9 files changed, 209 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index d768fcd..89049d9 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2460,6 +2460,8 @@ struct cfg80211_qos_map {
*
* @set_wds_peer: set the WDS peer for a WDS interface
*
+ * @set_ap_unicast: set the multicast to unicast flag for a AP interface
+ *
* @rfkill_poll: polls the hw rfkill line, use cfg80211 reporting
* functions to adjust rfkill hw state
*
@@ -2722,6 +2724,9 @@ struct cfg80211_ops {
int (*set_wds_peer)(struct wiphy *wiphy, struct net_device *dev,
const u8 *addr);
+ int (*set_ap_unicast)(struct wiphy *wiphy, struct net_device *dev,
+ const bool unicast);
+
void (*rfkill_poll)(struct wiphy *wiphy);
#ifdef CONFIG_NL80211_TESTMODE
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 2206941..cfbeebc 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -599,6 +599,9 @@
*
* @NL80211_CMD_SET_WDS_PEER: Set the MAC address of the peer on a WDS interface.
*
+ * @NL80211_CMD_SET_AP_UNICAST: Set the multicast to unicast toggle on a AP
+ * interface.
+ *
* @NL80211_CMD_JOIN_MESH: Join a mesh. The mesh ID must be given, and initial
* mesh config parameters may be given.
* @NL80211_CMD_LEAVE_MESH: Leave the mesh network -- no special arguments, the
@@ -1026,6 +1029,8 @@ enum nl80211_commands {
NL80211_CMD_ABORT_SCAN,
+ NL80211_CMD_SET_AP_UNICAST,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -2261,6 +2266,8 @@ enum nl80211_attrs {
NL80211_ATTR_MESH_PEER_AID,
+ NL80211_ATTR_UNICAST,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1edb017..a543e46 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2242,6 +2242,19 @@ static int ieee80211_set_wds_peer(struct wiphy *wiphy, struct net_device *dev,
return 0;
}
+static int ieee80211_set_ap_unicast(struct wiphy *wiphy, struct net_device *dev,
+ const bool unicast)
+{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+
+ if (sdata->vif.type != NL80211_IFTYPE_AP)
+ return -1;
+
+ sdata->u.ap.unicast = unicast;
+
+ return 0;
+}
+
static void ieee80211_rfkill_poll(struct wiphy *wiphy)
{
struct ieee80211_local *local = wiphy_priv(wiphy);
@@ -3400,6 +3413,7 @@ const struct cfg80211_ops mac80211_config_ops = {
.set_tx_power = ieee80211_set_tx_power,
.get_tx_power = ieee80211_get_tx_power,
.set_wds_peer = ieee80211_set_wds_peer,
+ .set_ap_unicast = ieee80211_set_ap_unicast,
.rfkill_poll = ieee80211_rfkill_poll,
CFG80211_TESTMODE_CMD(ieee80211_testmode_cmd)
CFG80211_TESTMODE_DUMP(ieee80211_testmode_dump)
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 7fe468e..03ff0ab 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -487,6 +487,34 @@ static ssize_t ieee80211_if_fmt_num_buffered_multicast(
}
IEEE80211_IF_FILE_R(num_buffered_multicast);
+static ssize_t
+ieee80211_if_fmt_unicast(const struct ieee80211_sub_if_data *sdata,
+ char *buf, int buflen)
+{
+ const struct ieee80211_if_ap *ifap = &sdata->u.ap;
+
+ return snprintf(buf, buflen, "0x%x\n", ifap->unicast);
+}
+
+static ssize_t
+ieee80211_if_parse_unicast(struct ieee80211_sub_if_data *sdata,
+ const char *buf, int buflen)
+{
+ struct ieee80211_if_ap *ifap = &sdata->u.ap;
+ u8 val;
+ int ret;
+
+ ret = kstrtou8(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ ifap->unicast = val ? 1 : 0;
+
+ return buflen;
+}
+
+IEEE80211_IF_FILE_RW(unicast);
+
/* IBSS attributes */
static ssize_t ieee80211_if_fmt_tsf(
const struct ieee80211_sub_if_data *sdata, char *buf, int buflen)
@@ -642,6 +670,7 @@ static void add_ap_files(struct ieee80211_sub_if_data *sdata)
DEBUGFS_ADD(dtim_count);
DEBUGFS_ADD(num_buffered_multicast);
DEBUGFS_ADD_MODE(tkip_mic_test, 0200);
+ DEBUGFS_ADD_MODE(unicast, 0600);
}
static void add_vlan_files(struct ieee80211_sub_if_data *sdata)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 933688e..99f990a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -293,6 +293,7 @@ struct ieee80211_if_ap {
driver_smps_mode; /* smps mode request */
struct work_struct request_smps_work;
+ bool unicast;
};
struct ieee80211_if_wds {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index aed375f..b230aa2 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/skbuff.h>
+#include <linux/if_vlan.h>
#include <linux/etherdevice.h>
#include <linux/bitmap.h>
#include <linux/rcupdate.h>
@@ -1770,6 +1771,104 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_tx_prepare_skb);
+/* rewrite destination mac address */
+static int ieee80211_change_da(struct sk_buff *skb, struct sta_info *sta)
+{
+ struct ethhdr *eth;
+ int err;
+
+ err = skb_ensure_writable(skb, ETH_HLEN);
+ if (unlikely(err))
+ return err;
+
+ eth = (void *)skb->data;
+ ether_addr_copy(eth->h_dest, sta->sta.addr);
+
+ return 0;
+}
+
+/* Check if multicast to unicast conversion is needed and do it.
+ * Returns 1 if skb was freed and should not be send out. */
+static int
+ieee80211_tx_multicast_to_unicast(struct ieee80211_sub_if_data *sdata,
+ struct sk_buff *skb, u32 info_flags)
+{
+ struct ieee80211_local *local = sdata->local;
+ const struct ethhdr *eth = (void *)skb->data;
+ const struct vlan_ethhdr *ethvlan = (void *)skb->data;
+ struct sta_info *sta, *prev = NULL;
+ struct sk_buff *cloned_skb;
+ u16 ethertype;
+
+ /* multicast to unicast conversion only for AP interfaces */
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_AP_VLAN:
+ sta = rcu_dereference(sdata->u.vlan.sta);
+ if (sta) /* 4addr */
+ return 0;
+ case NL80211_IFTYPE_AP:
+ break;
+ default:
+ return 0;
+ }
+
+ /* check runtime toggle for this bss */
+ if (!sdata->bss->unicast)
+ return 0;
+
+ /* check if this is a multicast frame */
+ if (!is_multicast_ether_addr(eth->h_dest))
+ return 0;
+
+ /* info_flags would not get preserved, used only by TLDS */
+ if (info_flags)
+ return 0;
+
+ /* multicast to unicast conversion only for some payload */
+ ethertype = ntohs(eth->h_proto);
+ if (ethertype == ETH_P_8021Q && skb->len >= VLAN_ETH_HLEN)
+ ethertype = ntohs(ethvlan->h_vlan_encapsulated_proto);
+ switch (ethertype) {
+ case ETH_P_ARP:
+ case ETH_P_IP:
+ case ETH_P_IPV6:
+ break;
+ default:
+ return 0;
+ }
+
+ /* clone packets and update destination mac */
+ list_for_each_entry_rcu(sta, &local->sta_list, list) {
+ if (sdata != sta->sdata)
+ continue;
+ if (unlikely(!memcmp(eth->h_source, sta->sta.addr, ETH_ALEN)))
+ /* do not send back to source */
+ continue;
+ if (unlikely(is_multicast_ether_addr(sta->sta.addr))) {
+ WARN_ONCE(1, "sta with multicast address %pM",
+ sta->sta.addr);
+ continue;
+ }
+ if (prev) {
+ cloned_skb = skb_clone(skb, GFP_ATOMIC);
+ if (likely(!ieee80211_change_da(cloned_skb, prev)))
+ ieee80211_subif_start_xmit(cloned_skb,
+ cloned_skb->dev);
+ else
+ dev_kfree_skb(cloned_skb);
+ }
+ prev = sta;
+ }
+
+ if (likely(prev)) {
+ ieee80211_change_da(skb, prev);
+ return 0;
+ }
+
+ /* no STA connected, drop */
+ return 1;
+}
+
/*
* Returns false if the frame couldn't be transmitted but was queued instead.
*/
@@ -3353,6 +3452,10 @@ void __ieee80211_subif_start_xmit(struct sk_buff *skb,
rcu_read_lock();
+ /* AP multicast to unicast conversion */
+ if (ieee80211_tx_multicast_to_unicast(sdata, skb, info_flags))
+ goto out_free;
+
if (ieee80211_lookup_ra_sta(sdata, skb, &sta))
goto out_free;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index f02653a..2eefee7 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -409,6 +409,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
.len = VHT_MUMIMO_GROUPS_DATA_LEN
},
[NL80211_ATTR_MU_MIMO_FOLLOW_MAC_ADDR] = { .len = ETH_ALEN },
+ [NL80211_ATTR_UNICAST] = { .type = NLA_U8, },
};
/* policy for the key attributes */
@@ -1538,6 +1539,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
goto nla_put_failure;
}
CMD(set_wds_peer, SET_WDS_PEER);
+ CMD(set_ap_unicast, SET_AP_UNICAST);
if (rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_TDLS) {
CMD(tdls_mgmt, TDLS_MGMT);
CMD(tdls_oper, TDLS_OPER);
@@ -2164,6 +2166,29 @@ static int nl80211_set_wds_peer(struct sk_buff *skb, struct genl_info *info)
return rdev_set_wds_peer(rdev, dev, bssid);
}
+static int nl80211_set_ap_unicast(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct net_device *dev = info->user_ptr[1];
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+ bool unicast;
+
+ if (!info->attrs[NL80211_ATTR_UNICAST])
+ return -EINVAL;
+
+ if (netif_running(dev))
+ return -EBUSY;
+
+ if (!rdev->ops->set_ap_unicast)
+ return -EOPNOTSUPP;
+
+ if (wdev->iftype != NL80211_IFTYPE_AP)
+ return -EOPNOTSUPP;
+
+ unicast = nla_data(info->attrs[NL80211_ATTR_UNICAST]);
+ return rdev_set_ap_unicast(rdev, dev, unicast);
+}
+
static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev;
@@ -11574,6 +11599,14 @@ static const struct genl_ops nl80211_ops[] = {
NL80211_FLAG_NEED_RTNL,
},
{
+ .cmd = NL80211_CMD_SET_AP_UNICAST,
+ .doit = nl80211_set_ap_unicast,
+ .policy = nl80211_policy,
+ .flags = GENL_UNS_ADMIN_PERM,
+ .internal_flags = NL80211_FLAG_NEED_NETDEV |
+ NL80211_FLAG_NEED_RTNL,
+ },
+ {
.cmd = NL80211_CMD_JOIN_MESH,
.doit = nl80211_join_mesh,
.policy = nl80211_policy,
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 85ff30b..af3ca14 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -562,6 +562,17 @@ static inline int rdev_set_wds_peer(struct cfg80211_registered_device *rdev,
return ret;
}
+static inline int rdev_set_ap_unicast(struct cfg80211_registered_device *rdev,
+ struct net_device *dev,
+ const bool unicast)
+{
+ int ret;
+ trace_rdev_set_ap_unicast(&rdev->wiphy, dev, unicast);
+ ret = rdev->ops->set_ap_unicast(&rdev->wiphy, dev, unicast);
+ trace_rdev_return_int(&rdev->wiphy, ret);
+ return ret;
+}
+
static inline void rdev_rfkill_poll(struct cfg80211_registered_device *rdev)
{
trace_rdev_rfkill_poll(&rdev->wiphy);
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 72b5255..5bce212 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -773,6 +773,12 @@ DEFINE_EVENT(wiphy_netdev_mac_evt, rdev_set_wds_peer,
TP_ARGS(wiphy, netdev, mac)
);
+DEFINE_EVENT(wiphy_netdev_mac_evt, rdev_set_ap_unicast,
+ TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
+ const bool unicast),
+ TP_ARGS(wiphy, netdev, mac)
+);
+
TRACE_EVENT(rdev_dump_station,
TP_PROTO(struct wiphy *wiphy, struct net_device *netdev, int idx,
u8 *mac),
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] mac80211: filter multicast data packets on AP / AP_VLAN
From: Michael Braun @ 2016-10-04 20:31 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan
In-Reply-To: <1475613109-17609-1-git-send-email-michael-dev@fami-braun.de>
This patch adds filtering for multicast data packets on AP_VLAN interfaces that
have no authorized station connected and changes filtering on AP interfaces to
not count stations assigned to AP_VLAN interfaces.
This saves airtime and avoids waking up other stations currently authorized in
this BSS. When using WPA, the packets dropped could not be decrypted by any
station.
The behaviour when there are no AP_VLAN interfaces is left unchanged.
When there are AP_VLAN interfaces, this patch
1. adds filtering multicast data packets sent on AP_VLAN interfaces that
have no authorized station connected.
No filtering happens on 4addr AP_VLAN interfaces.
2. makes filtering of multicast data packets sent on AP interfaces depend on
the number of authorized stations in this bss not assigned to an AP_VLAN
interface.
Therefore, two new num_mcast_sta like counters are added: one for the number of
authorized stations connected to an AP_VLAN interface and one for the number of
authorized stations connected to the bss and not assigned to any AP_VLAN. The
already existing num_mcast_sta counter is left unchanged as it is used by SMPS.
The new counters are exposed in debugfs.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--
v3:
- reuse existing num_mcast_sta
v2:
- use separate function to inc/dec mcast_sta counters
- do not filter in 4addr mode
- change description
- change filtering on AP interface (do not count AP_VLAN sta)
- use new counters regardless of 4addr or not
- simplify cfg.c:change_station
- remove no-op change in __cleanup_single_sta
---
net/mac80211/cfg.c | 20 ++++++--------------
net/mac80211/debugfs_netdev.c | 11 +++++++++++
net/mac80211/ieee80211_i.h | 42 ++++++++++++++++++++++++++++++++++++++++++
net/mac80211/rx.c | 5 +++--
net/mac80211/sta_info.c | 10 ++--------
net/mac80211/tx.c | 5 ++---
6 files changed, 66 insertions(+), 27 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 24133f5..1edb017 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1357,9 +1357,6 @@ static int ieee80211_change_station(struct wiphy *wiphy,
goto out_err;
if (params->vlan && params->vlan != sta->sdata->dev) {
- bool prev_4addr = false;
- bool new_4addr = false;
-
vlansdata = IEEE80211_DEV_TO_SUB_IF(params->vlan);
if (params->vlan->ieee80211_ptr->use_4addr) {
@@ -1369,26 +1366,21 @@ static int ieee80211_change_station(struct wiphy *wiphy,
}
rcu_assign_pointer(vlansdata->u.vlan.sta, sta);
- new_4addr = true;
__ieee80211_check_fast_rx_iface(vlansdata);
}
if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- sta->sdata->u.vlan.sta) {
+ sta->sdata->u.vlan.sta)
RCU_INIT_POINTER(sta->sdata->u.vlan.sta, NULL);
- prev_4addr = true;
- }
+
+ if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ ieee80211_vif_dec_num_mcast(sta->sdata);
sta->sdata = vlansdata;
ieee80211_check_fast_xmit(sta);
- if (sta->sta_state == IEEE80211_STA_AUTHORIZED &&
- prev_4addr != new_4addr) {
- if (new_4addr)
- atomic_dec(&sta->sdata->bss->num_mcast_sta);
- else
- atomic_inc(&sta->sdata->bss->num_mcast_sta);
- }
+ if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ ieee80211_vif_inc_num_mcast(sta->sdata);
ieee80211_send_layer2_update(sta);
}
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index a5ba739..7fe468e 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -477,6 +477,7 @@ IEEE80211_IF_FILE_RW(tdls_wider_bw);
IEEE80211_IF_FILE(num_mcast_sta, u.ap.num_mcast_sta, ATOMIC);
IEEE80211_IF_FILE(num_sta_ps, u.ap.ps.num_sta_ps, ATOMIC);
IEEE80211_IF_FILE(dtim_count, u.ap.ps.dtim_count, DEC);
+IEEE80211_IF_FILE(num_mcast_sta_vlan, u.vlan.num_mcast_sta, ATOMIC);
static ssize_t ieee80211_if_fmt_num_buffered_multicast(
const struct ieee80211_sub_if_data *sdata, char *buf, int buflen)
@@ -643,6 +644,13 @@ static void add_ap_files(struct ieee80211_sub_if_data *sdata)
DEBUGFS_ADD_MODE(tkip_mic_test, 0200);
}
+static void add_vlan_files(struct ieee80211_sub_if_data *sdata)
+{
+ // add num_mcast_sta_vlan using name num_mcast_sta
+ debugfs_create_file("num_mcast_sta", 0400, sdata->vif.debugfs_dir, \
+ sdata, &num_mcast_sta_vlan_ops);
+}
+
static void add_ibss_files(struct ieee80211_sub_if_data *sdata)
{
DEBUGFS_ADD_MODE(tsf, 0600);
@@ -746,6 +754,9 @@ static void add_files(struct ieee80211_sub_if_data *sdata)
case NL80211_IFTYPE_AP:
add_ap_files(sdata);
break;
+ case NL80211_IFTYPE_AP_VLAN:
+ add_vlan_files(sdata);
+ break;
case NL80211_IFTYPE_WDS:
add_wds_files(sdata);
break;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index f56d342..933688e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -305,6 +305,7 @@ struct ieee80211_if_vlan {
/* used for all tx if the VLAN is configured to 4-addr mode */
struct sta_info __rcu *sta;
+ atomic_t num_mcast_sta; /* number of stations receiving multicast */
};
struct mesh_stats {
@@ -1496,6 +1497,47 @@ ieee80211_have_rx_timestamp(struct ieee80211_rx_status *status)
return false;
}
+static inline void
+ieee80211_vif_inc_num_mcast(struct ieee80211_sub_if_data *sdata)
+{
+ if (sdata->vif.type != NL80211_IFTYPE_AP &&
+ sdata->vif.type != NL80211_IFTYPE_AP_VLAN)
+ return;
+
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ atomic_inc(&sdata->u.ap.num_mcast_sta);
+ else if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ atomic_inc(&sdata->u.vlan.num_mcast_sta);
+}
+
+static inline void
+ieee80211_vif_dec_num_mcast(struct ieee80211_sub_if_data *sdata)
+{
+ if (sdata->vif.type != NL80211_IFTYPE_AP &&
+ sdata->vif.type != NL80211_IFTYPE_AP_VLAN)
+ return;
+
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ atomic_dec(&sdata->u.ap.num_mcast_sta);
+ else if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ atomic_dec(&sdata->u.vlan.num_mcast_sta);
+}
+
+/* This function returns the number of multicast stations connected to this
+ * interface. It returns -1 if that number is not tracked, that is for netdevs
+ * not in AP or AP_VLAN mode or when using 4addr. */
+static inline int
+ieee80211_vif_get_num_mcast_if(struct ieee80211_sub_if_data *sdata)
+{
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ return atomic_read(&sdata->u.ap.num_mcast_sta);
+ else if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
+ !sdata->u.vlan.sta)
+ return atomic_read(&sdata->u.vlan.num_mcast_sta);
+ else
+ return -1;
+}
+
u64 ieee80211_calculate_rx_timestamp(struct ieee80211_local *local,
struct ieee80211_rx_status *status,
unsigned int mpdu_len,
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index fbf99b8..9c5d222 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2161,7 +2161,8 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
sdata->vif.type == NL80211_IFTYPE_AP_VLAN) &&
!(sdata->flags & IEEE80211_SDATA_DONT_BRIDGE_PACKETS) &&
(sdata->vif.type != NL80211_IFTYPE_AP_VLAN || !sdata->u.vlan.sta)) {
- if (is_multicast_ether_addr(ehdr->h_dest)) {
+ if (is_multicast_ether_addr(ehdr->h_dest) &&
+ ieee80211_vif_get_num_mcast_if(sdata) != 0) {
/*
* send multicast frames both to higher layers in
* local net stack and back to the wireless medium
@@ -2170,7 +2171,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
if (!xmit_skb)
net_info_ratelimited("%s: failed to clone multicast frame\n",
dev->name);
- } else {
+ } else if (!is_multicast_ether_addr(ehdr->h_dest)) {
dsta = sta_info_get(sdata, skb->data);
if (dsta) {
/*
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 76b737d..216ef65 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1882,10 +1882,7 @@ int sta_info_move_state(struct sta_info *sta,
if (!sta->sta.support_p2p_ps)
ieee80211_recalc_p2p_go_ps_allowed(sta->sdata);
} else if (sta->sta_state == IEEE80211_STA_AUTHORIZED) {
- if (sta->sdata->vif.type == NL80211_IFTYPE_AP ||
- (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- !sta->sdata->u.vlan.sta))
- atomic_dec(&sta->sdata->bss->num_mcast_sta);
+ ieee80211_vif_dec_num_mcast(sta->sdata);
clear_bit(WLAN_STA_AUTHORIZED, &sta->_flags);
ieee80211_clear_fast_xmit(sta);
ieee80211_clear_fast_rx(sta);
@@ -1893,10 +1890,7 @@ int sta_info_move_state(struct sta_info *sta,
break;
case IEEE80211_STA_AUTHORIZED:
if (sta->sta_state == IEEE80211_STA_ASSOC) {
- if (sta->sdata->vif.type == NL80211_IFTYPE_AP ||
- (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- !sta->sdata->u.vlan.sta))
- atomic_inc(&sta->sdata->bss->num_mcast_sta);
+ ieee80211_vif_inc_num_mcast(sta->sdata);
set_bit(WLAN_STA_AUTHORIZED, &sta->_flags);
ieee80211_check_fast_xmit(sta);
ieee80211_check_fast_rx(sta);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5023966..aed375f 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -331,9 +331,8 @@ ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)
I802_DEBUG_INC(tx->local->tx_handlers_drop_not_assoc);
return TX_DROP;
}
- } else if (unlikely(tx->sdata->vif.type == NL80211_IFTYPE_AP &&
- ieee80211_is_data(hdr->frame_control) &&
- !atomic_read(&tx->sdata->u.ap.num_mcast_sta))) {
+ } else if (unlikely(ieee80211_vif_get_num_mcast_if(tx->sdata) == 0 &&
+ ieee80211_is_data(hdr->frame_control))) {
/*
* No associated STAs - no need to send multicast
* frames.
--
2.1.4
^ permalink raw reply related
* [PATCH 1/3] mac80211: remove unnecessary num_mcast_sta user
From: Michael Braun @ 2016-10-04 20:31 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan
Checking for num_mcast_sta in __ieee80211_request_smps_ap() is unnecessary,
as sta list will be empty in this case anyway, so list_for_each_entry(sta,
...) will exit immediately.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
---
net/mac80211/cfg.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 543b1d4..24133f5 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2313,13 +2313,6 @@ int __ieee80211_request_smps_ap(struct ieee80211_sub_if_data *sdata,
smps_mode == IEEE80211_SMPS_AUTOMATIC)
return 0;
- /* If no associated stations, there's no need to do anything */
- if (!atomic_read(&sdata->u.ap.num_mcast_sta)) {
- sdata->smps_mode = smps_mode;
- ieee80211_queue_work(&sdata->local->hw, &sdata->recalc_smps);
- return 0;
- }
-
ht_dbg(sdata,
"SMPS %d requested in AP mode, sending Action frame to %d stations\n",
smps_mode, atomic_read(&sdata->u.ap.num_mcast_sta));
--
2.1.4
^ permalink raw reply related
* Re: bcmdhd: Strange Power Save messages
From: Krishna Chaitanya @ 2016-10-04 18:54 UTC (permalink / raw)
To: Gucea Doru
Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CANfLQrZs5EyTEMupsR=1M9gqo7ar88g6RHObJ=4fj3J3dkTtvQ@mail.gmail.com>
On Tue, Oct 4, 2016 at 11:57 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>
>>>>>
>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>>> mode.
>>>>>>
>>>>>>
>>>>>> Any help would be highly appreciated :)
>>>>>
>>>>> Actually though I already sent you are reply, but alas here it is.
>>>>>
>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>>> drivers. Regardless your question is more for firmware running on the
>>>>> device. So like the same behavior would be observed when using brcmfmac
>>>>> with same firmware.
>>>>>
>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>>> exits the PS mode without waiting for a beacon.
>>>>>
>>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>>> should be in power-save at any other time. So it is difficult to say
>>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>>> is just some things I can come up with and I am sure there are more.
>>>
>>> I agree that there may be some events belonging to the regular STA
>>> interface that could trigger the Null Frame (which includes the exit
>>> from PS Mode). However, I would expect to see some management frames
>>> in the air before/after the Null Packet (e.g.: a Probe request in case
>>> of a scheduled scan). But in my case the trigger for the Null frame
>>> seems to be the ping request packet, the scenario is the same every
>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>>> confirms this behavior).
>>>
>>> I thought that you had a power save optimization algorithm that keeps
>>> the card on a few milliseconds just to see if we can have a fast reply
>>> from the peer. Does this ring a bell? :)
>>>
>>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>>> <chaitanya.mgit@gmail.com> wrote:
>>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>>
>>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>>> "When an AP is informed that a STA has changed to the Active mode,
>>> then the AP shall send buffered BUs (if any exist) to the STA without
>>> waiting for a PS Poll...."
>> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
>> so AP should set TIM/DTIM...
>
> The STA _did_ inform the AP.
>
> If you take a look at the packet traces you'll see that the STA sends
> a NULL frame saying that it will exit Power Save Mode. According to
> the specification the AP can send the buffered frames.
Yeah, sorry i thought AP is sending the ping request.
But still as STA is sending "ping request" with PM=0, the state at
AP should be updated treating STA as active, so sending NULL data +
PM=0 is redundant.
--
Thanks,
Regards,
Chaitanya T K.
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Gucea Doru @ 2016-10-04 18:27 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CABPxzY+yDnf6AOb4=yRo8jRCYD4FWJ0uBvmQnUSemwXQa2PQrg@mail.gmail.com>
On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>>
>>>>
>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>> mode.
>>>>>
>>>>>
>>>>> Any help would be highly appreciated :)
>>>>
>>>> Actually though I already sent you are reply, but alas here it is.
>>>>
>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>> drivers. Regardless your question is more for firmware running on the
>>>> device. So like the same behavior would be observed when using brcmfmac
>>>> with same firmware.
>>>>
>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>> exits the PS mode without waiting for a beacon.
>>>>
>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>> should be in power-save at any other time. So it is difficult to say
>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>> is just some things I can come up with and I am sure there are more.
>>
>> I agree that there may be some events belonging to the regular STA
>> interface that could trigger the Null Frame (which includes the exit
>> from PS Mode). However, I would expect to see some management frames
>> in the air before/after the Null Packet (e.g.: a Probe request in case
>> of a scheduled scan). But in my case the trigger for the Null frame
>> seems to be the ping request packet, the scenario is the same every
>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>> confirms this behavior).
>>
>> I thought that you had a power save optimization algorithm that keeps
>> the card on a few milliseconds just to see if we can have a fast reply
>> from the peer. Does this ring a bell? :)
>>
>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>> <chaitanya.mgit@gmail.com> wrote:
>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>
>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>> "When an AP is informed that a STA has changed to the Active mode,
>> then the AP shall send buffered BUs (if any exist) to the STA without
>> waiting for a PS Poll...."
> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
> so AP should set TIM/DTIM...
The STA _did_ inform the AP.
If you take a look at the packet traces you'll see that the STA sends
a NULL frame saying that it will exit Power Save Mode. According to
the specification the AP can send the buffered frames.
^ permalink raw reply
* Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH
From: Rafał Miłecki @ 2016-10-04 18:15 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, brcm80211 development
In-Reply-To: <CACna6rzS4nDZ+H5kU71WwTTNLp5uZStpQHv4LLmWBDSdf5jpyw@mail.gmail.com>
On 09/28/2015 11:00 AM, Rafał Miłecki wrote:
> I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
> sits in linux-firmware.git.
>
> In OpenWrt we have hostapd with a feature of banning STAs. It works in
> a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
> STA that is banned it sends NL80211_CMD_DEL_STATION.
>
> The problem is that in such case BCM43602 firmware happens to randomly
> send more than 1 BRCMF_E_DEAUTH event. It seems it can send random
> amount between 1 and 3. Looks a bit like some kind of race. It's
> nothing really critical, just makes hostapd log a bit confusing.
>
> Could someone at Broadcom look at firmware source to see if you can
> fix this, please?
Hey, I didn't get any reply on this for a year. I just saw similar problem with
BCM4366. Below you will find a nice log with my extra comments.
Could take a look at this issue this time, please?
I think it may be another problem related to the A-MPDU thing (bug?) I reported
in "AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs" e-mail thread.
# My smartphone remains in the same place (1 m from the AP) but there is some
# connection/A-MPDU problem.
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509120] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: wl0.0 scb:0035ee78 tid:0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509250] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: wl0.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509304] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: ifsstat 0xaf nav_stat 0x0 txop 110486
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509346] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509411] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: txall 4 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509477] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 4 0 0 0 0 ifs_boff 0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509527] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: again1 ifsstat 0xaf nav_stat 0x0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509576] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: again2 ifsstat 0xaf nav_stat 0x0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509665] brcmfmac: CONSOLE: 026970.308 wl0: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509726] brcmfmac: CONSOLE: 026970.308 wl0: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Tue Oct 4 17:22:41 2016 kern.debug kernel: [ 266.456860] brcmfmac: CONSOLE: 026990.068 wl0.0: wlc_send_bar: seq 0x7c tid 0
Tue Oct 4 17:22:43 2016 kern.debug kernel: [ 268.178234] brcmfmac: CONSOLE: 026991.783 pktid is NULL
# After recovering from A-MPDU thing firmware sends BRCMF_E_DEAUTH and
# BRCMF_E_DISASSOC_IND events.
# My smartphone never receives deauth/disassoc and it believes it's still
# connected to the AP.
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275305] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 4
Tue Oct 4 17:23:24 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275354] brcmfmac: brcmf_notify_connect_status_ap event 12, reason 8
Tue Oct 4 17:23:24 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275865] brcmfmac: brcmf_cfg80211_del_key key index (0)
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.276177] brcmfmac: brcmf_cfg80211_del_key key index (0)
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.276188] brcmfmac: brcmf_cfg80211_del_key Ignore clearing of (never configured) key
# My smartphone starts sending packets. It seems brcmfmac refuses them due to
# STA not being connected and for each packet it reports BRCMF_E_DEAUTH to the
# driver.
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.000406] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.001227] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.001894] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.002594] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.003741] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004096] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004490] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004936] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
As you can see in above example I got more than just 3 BRCMF_E_DEAUTH reported
originally for BCM43602 firmware. But this isn't the worst case. In one extreme
situation I got 9714 of these events!
Mon Oct 3 09:10:04 2016 kern.err kernel: [227426.890053] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
Mon Oct 3 09:10:04 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 472 identical lines were here)
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 623 identical lines were here)
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 443 identical lines were here)
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 434 identical lines were here)
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 577 identical lines were here)
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 562 identical lines were here)
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 451 identical lines were here)
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 557 identical lines were here)
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 426 identical lines were here)
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 340 identical lines were here)
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 115 identical lines were here)
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 115 identical lines were here)
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 150 identical lines were here)
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 668 identical lines were here)
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 602 identical lines were here)
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 482 identical lines were here)
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 419 identical lines were here)
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 462 identical lines were here)
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 584 identical lines were here)
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 417 identical lines were here)
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 485 identical lines were here)
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 200 identical lines were here)
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 14 identical lines were here)
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Vittorio Gambaletta (VittGam) @ 2016-10-04 18:14 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <87k2dop15n.fsf@kamboji.qca.qualcomm.com>
Hello,
On 04/10/2016 17:46:44 CEST, Kalle Valo wrote:
> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>
>> If generic entries are positioned above specific ones, then the
>> former will be matched first and used instead of the latter.
>>
>> Cc: <linux-wireless@vger.kernel.org>
>> Cc: <ath9k-devel@qca.qualcomm.com>
>> Cc: <ath9k-devel@lists.ath9k.org>
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>
> Why? What kind of bug you are fixing? You are not really describing the
> problem you are trying fix.
The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline.
When I was preparing my former patch to fix that, I initially added the
PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section
for 0x0029; but then I moved the former below the latter after seeing
how 0x002A sections were sorted in the file.
I must have somehow messed up with testing, because I tested the final
version of that patch before sending it, and it was apparently working;
but now it is not working on 4.7.6 mainline.
With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
So, after seeing that the rest of the file is sorted this way (generic
section after the specific ones), I concluded that the 0x002A sorting
was wrong in the first place, and so is 0x0029. Then I sent this patch
to fix this.
> And your email headers look weird:
>
> To: <kvalo@codeaurora.org>
> Cc: <linux-wireless@vger.kernel.org>
> Cc: <ath9k-devel@qca.qualcomm.com>
> Cc: <ath9k-devel@venema.h4ckr.net>
> Cc: <stable@vger.kernel.org>
> Date: Mon, 3 Oct 2016 12:00:56 +0200
>
> What software are you using to send this? Only one CC header is valid
> according to the spec (thanks to Luca for checking) even though mailers
> seem to handle multiple CC headers. But for example my patchwork script
> fails with this and uses only the first CC header.
Sorry about this, I used a custom mailer to send the patch since I was
having problems with git-send-email...
^ permalink raw reply
* Re: [PATCH v8] Add new mac80211 driver mwlwifi.
From: Kalle Valo @ 2016-10-04 17:36 UTC (permalink / raw)
To: David Lin
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Chor Teck Law,
Pete Hsieh
In-Reply-To: <fdef0b5d3b744af8be48680e56ae9fb1@SC-EXCH02.marvell.com>
David Lin <dlin@marvell.com> writes:
> PATCH v8 changes since PATCH v7:
>
> - Used scnprintf() to replace sprintf() for debugfs output messages to avoid
> overwriting buffer boundary.
> - Used mutex to replace spinlock for the protection of firmware command.
> - Used NL80211_BAND_XXXX instead of IEEE80211_BAND_XXXX (in order to work with
> updated mac80211).
> - Used usleep_range() instead of mdelay().
> - Modified the code to work with new mac80211 API ampdu_action() and get peer
> AMSDU information from parameters of this function instead of peeking ADDBA
> related packets.
> - Removed BA stream if traffic is not heavy.
> - Removed version information.
> - Added DFS, WPS, WDS and thermal function.
> - Changed length of mac vht_mpdu from 7991 to 3895.
I did a diff against v7 and you are not really making this easy:
drivers/net/wireless/marvell/mwlwifi/Makefile | 3 +-
drivers/net/wireless/marvell/mwlwifi/debugfs.c | 591 ++++++++++++++----
drivers/net/wireless/marvell/mwlwifi/debugfs.h | 8 +-
drivers/net/wireless/marvell/mwlwifi/dev.h | 85 ++-
drivers/net/wireless/marvell/mwlwifi/fwcmd.c | 750 ++++++++++++++++-------
drivers/net/wireless/marvell/mwlwifi/fwcmd.h | 24 +-
drivers/net/wireless/marvell/mwlwifi/fwdl.c | 43 +-
drivers/net/wireless/marvell/mwlwifi/fwdl.h | 8 +-
drivers/net/wireless/marvell/mwlwifi/hostcmd.h | 109 +++-
drivers/net/wireless/marvell/mwlwifi/isr.c | 90 ++-
drivers/net/wireless/marvell/mwlwifi/isr.h | 9 +-
drivers/net/wireless/marvell/mwlwifi/mac80211.c | 74 ++-
drivers/net/wireless/marvell/mwlwifi/main.c | 270 ++++----
drivers/net/wireless/marvell/mwlwifi/rx.c | 149 +----
drivers/net/wireless/marvell/mwlwifi/rx.h | 8 +-
drivers/net/wireless/marvell/mwlwifi/sysadpt.h | 18 +-
drivers/net/wireless/marvell/mwlwifi/thermal.c | 182 ++++++
drivers/net/wireless/marvell/mwlwifi/thermal.h | 40 ++
drivers/net/wireless/marvell/mwlwifi/tx.c | 145 +++--
drivers/net/wireless/marvell/mwlwifi/tx.h | 9 +-
20 files changed, 1799 insertions(+), 816 deletions(-)
You do understand that making so drastic changes during the driver
review is very counterproductive and demotivating for the reviewers?
Before I start looking this again I want to have an assurance that you
have frozen the driver and are not adding new features. I do not want
waste my time again just going circles.
You can continue adding new features but do that as separate patches and
submit them after the driver is applied to wireless-drivers-next.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2 2/2] mwifiex: check hw_status in suspend and resume handlers
From: Amitkumar Karwar @ 2016-10-04 17:08 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris, Xinming Hu,
Amitkumar Karwar
In-Reply-To: <1475600905-2997-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
We have observed a kernel crash when system immediately suspends
after booting. There is a race between suspend and driver
initialization paths.
This patch adds hw_status checks to fix the problem
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Return failure in suspend/resume handler in this scenario.
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index ba9e068..fa6bf85 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -122,9 +122,10 @@ static int mwifiex_pcie_suspend(struct device *dev)
if (pdev) {
card = pci_get_drvdata(pdev);
- if (!card || !card->adapter) {
+ if (!card || !card->adapter ||
+ card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
pr_err("Card or adapter structure is not valid\n");
- return 0;
+ return -EBUSY;
}
} else {
pr_err("PCIE device is not specified\n");
@@ -166,9 +167,10 @@ static int mwifiex_pcie_resume(struct device *dev)
if (pdev) {
card = pci_get_drvdata(pdev);
- if (!card || !card->adapter) {
+ if (!card || !card->adapter ||
+ card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
pr_err("Card or adapter structure is not valid\n");
- return 0;
+ return -EBUSY;
}
} else {
pr_err("PCIE device is not specified\n");
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister
From: Amitkumar Karwar @ 2016-10-04 17:08 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris, Xinming Hu,
Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
card->adapter gets initialized during device registration.
As it's not cleared, we may end up accessing invalid memory
in some corner cases. This patch fixes the problem.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Same as v1
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 1 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index f1eeb73..ba9e068 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
pci_disable_msi(pdev);
}
}
+ card->adapter = NULL;
}
/* This function initializes the PCI-E host memory space, WCB rings, etc.
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 8718950..4cad1c2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2066,6 +2066,7 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
struct sdio_mmc_card *card = adapter->card;
if (adapter->card) {
+ card->adapter = NULL;
sdio_claim_host(card->func);
sdio_disable_func(card->func);
sdio_release_host(card->func);
--
1.9.1
^ permalink raw reply related
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Kalle Valo @ 2016-10-04 16:45 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <20160905095128.80560-4-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> From: Felix Fietkau <nbd@openwrt.org>
>
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
I already asked this in v2, but what about firmware images? Will they be
available from linux-firmware.git?
--
https://patchwork.kernel.org/patch/9313311/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Kalle Valo @ 2016-10-04 16:34 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <20160905095128.80560-4-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> From: Felix Fietkau <nbd@openwrt.org>
>
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
A summary of what feature work would be nice to have. Also if there's something
notable which is not working it's good also to mention that.
I don't know why I didn't see this earlier but this fails to build for me:
ERROR: "mtd_read" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
ERROR: "put_mtd_device" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
ERROR: "get_mtd_device_nm" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
Dependency to mtd missing?
--
https://patchwork.kernel.org/patch/9313311/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Ben Greear @ 2016-10-04 16:31 UTC (permalink / raw)
To: Johannes Berg, Pedersen, Thomas; +Cc: linux-wireless
In-Reply-To: <1475573532.5324.47.camel@sipsolutions.net>
On 10/04/2016 02:32 AM, Johannes Berg wrote:
> Sorry - needed some time to think through this thread again.
>
>> I think it is a moot point as far as this change goes: Regardless of
>> whether the NIC should or not, it _does_. So, mis-reporting it up
>> the stack only hides the issue and does not even give the user a clue
>> that on-the-air encoding may be slightly off-spec.
>
> Arguably, reporting something that *seems* sane, like this patch does,
> will do more to hide it than reporting 0 which is clearly bogus, no?
>
> I realize you were replying to whether or not the *driver* should
> "misreport" it, but the same argument applies the other way here, imho.
If the firmware/NIC is putting it on air at a particular encoding, then
I think the stack should report it exactly as it is on air if possible.
Returning zero is not much of a clue to the user. Adding a WARN_ON_ONCE()
might be more useful, but no one can fix this by modifying the driver or stack, so the warning
will hit, confuse people, and then still never get fixed since it is a firmware
issue.
And, since someone added specific code to the firmware to use this rate
in certain cases, then maybe it is actually a good thing to do.
>> If the on-air encoding is an issue, then we need to hack the firmware
>> to disable this 'feature', but that is a completely separate issue.
>
> I guess it trusts rate control enough to try, and if it cannot be
> received by a spec-abiding receiver, it won't use it due to the
> failures ... not such a big deal I guess, even though it's odd.
>
> Does /anyone/ know why the spec disallowed it? Perhaps those "system"
> people you refer to?
I didn't talk to any system people, but maybe Thomas did. I can confirm
that the firmware appears to do this on purpose and not just to be buggy
on accident though.
>> Once this patch goes in, someone might consider properly reporting
>> CCK rx rates for 5Ghz band too: ath10k can do this 'feature' as
>> well, at least in some firmware. Probably can reproduce by sending
>> off-channel mgt frames on 5Ghz when associated on 2.4, or something
>> similar to this. I was using ath9k as sniffer when I found this long
>> ago, so at least ath9k needs the change....
>
> I don't see how this is related? It's not advertising those rates, so
> it probably also can't use/report them as far as mac80211 and the rest
> of the stack are concerned.
I can guarantee you that at least some ath10k firmware has a bug that will
send CCK encodings on 5Ghz. This is a bug in the firmware, but the packets
will go on air, and they can be decoded by ath9k (and ath10k)
and passed up the stack.
Stock ath9k driver will ignore them (or maybe lie and say rate is 6Mbps, I cannot
recall at this point) currently because it thinks the rate is
bad (since it sort of is). But, if you relax ath9k, then it can actually
sniff these frames and give you a clue as to what is really wrong.
It reminded me of hiding the rate by setting it to zero, since in both cases,
overly strict decisions based on what is *supposed* to happen caused me
to have to dig closely and modify code in order to understand what is
actually happening on-air.
Basically, if the NIC can decode a frame, and checksums pass and so forth,
then it seems it should pass it up the stack. Possibly with WARN_ONCE to
give use a better clue that there is an issue.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
From: Malinen, Jouni @ 2016-10-04 16:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Xu, Peng
In-Reply-To: <1475587551.5324.57.camel@sipsolutions.net>
On Tue, Oct 04, 2016 at 03:25:51PM +0200, Johannes Berg wrote:
> > ath6kl:
> > Use cfg80211_get_chandef_type(&info->chandef) !=3D NL80211_CHAN_NO_HT
> > to determine whether HT is enabled. No VHT support. HT-required case
> > not covered. No parsing of HT/VHT IEs used.
>=20
> Hmm. Wouldn't the supported rates IE still advertise the cookie for HT
> only, to make sure HT-required was done?
I'm not completely sure how the driver/firmware behaves for this. There
is a reference to info->beacon.head, but that code looks like dead code
that does nothing as far as configuring the firmware with the supported
rates elements from user space. As such, I'd expect the firmware to
build (Ext)Supp Rates element from scratch and I'd assume ath6kl does
not currently support HT-required signaling. I'm not sure whether the
current firmware would even allow such configuration.
> [snip other drivers]
By the way, I did not find any clear example that would be either using
(Extended) Supported Rates element from start_ap() as-is or parsing it
for the BSS membership selectors in any of the in-tree drivers. In other
words, the HT/VHT required configuration may not really work properly
with non-mac80211 cases.
PS.
And even if the driver were to simply copy the IEs with the BSS
membership selectors, this would only work with stations that implement
this part correctly, i.e., the AP would not necessarily have any means
for rejecting the association if a non-HT/VHT station were to try to
associate.. With mac80211-drivers, this happens in hostapd.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* [PATCH v2] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Mohammed Shafi Shajakhan @ 2016-10-04 15:49 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
'ath10k_htt_rx_h_unchain' needs to be called only if the return
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
change makes it more explicit and avoids doing a skb_peek, fetching
rx descriptor pointer, checking rx msdu decap format for the case of
ret = 0 (unchained msdus). Found this change during code walk through,
not sure if this addresses any issue.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
[v2 rebased over top of master tree]
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0b4c156..285b235 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1463,8 +1463,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu)
}
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
- struct sk_buff_head *amsdu,
- bool chained)
+ struct sk_buff_head *amsdu)
{
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -1475,9 +1474,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
decap = MS(__le32_to_cpu(rxd->msdu_start.common.info1),
RX_MSDU_START_INFO1_DECAP_FORMAT);
- if (!chained)
- return;
-
/* FIXME: Current unchaining logic can only handle simple case of raw
* msdu chaining. If decapping is other than raw the chaining may be
* more complex and this isn't handled by the current code. Don't even
@@ -1555,7 +1551,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
num_msdus = skb_queue_len(&amsdu);
ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);
- ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
+
+ /* only for ret = 1 indicates chained msdus */
+ if (ret > 0)
+ ath10k_htt_rx_h_unchain(ar, &amsdu);
+
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Kalle Valo @ 2016-10-04 15:46 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam)
Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <ath9k-patch-20161003@vittgam.net>
"Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
> If generic entries are positioned above specific ones, then the
> former will be matched first and used instead of the latter.
>
> Cc: <linux-wireless@vger.kernel.org>
> Cc: <ath9k-devel@qca.qualcomm.com>
> Cc: <ath9k-devel@lists.ath9k.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Why? What kind of bug you are fixing? You are not really describing the
problem you are trying fix.
And your email headers look weird:
To: <kvalo@codeaurora.org>
Cc: <linux-wireless@vger.kernel.org>
Cc: <ath9k-devel@qca.qualcomm.com>
Cc: <ath9k-devel@venema.h4ckr.net>
Cc: <stable@vger.kernel.org>
Date: Mon, 3 Oct 2016 12:00:56 +0200
What software are you using to send this? Only one CC header is valid
according to the spec (thanks to Luca for checking) even though mailers
seem to handle multiple CC headers. But for example my patchwork script
fails with this and uses only the first CC header.
--
Kalle Valo
^ permalink raw reply
* Re: ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Mohammed Shafi Shajakhan @ 2016-10-04 15:39 UTC (permalink / raw)
To: Kalle Valo; +Cc: Mohammed Shafi Shajakhan, ath10k, linux-wireless
In-Reply-To: <2cb38dba80294e6da1005ac0927d01eb@euamsexm01a.eu.qualcomm.com>
On Tue, Oct 04, 2016 at 05:30:17PM +0200, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > 'ath10k_htt_rx_h_unchain' is need to be called only if the return
> > value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> > change makes it more explicit and avoids doing a skb_peek, fetching
> > rx descriptor pointer, checking rx msdu decap format for the case of
> > ret = 0 (unchained msdus). Found this change during code walk through,
> > not sure if this addresses any issue.
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> Failed to apply to pending branch
>
> error: patch failed: drivers/net/wireless/ath/ath10k/htt_rx.c:1550
> error: drivers/net/wireless/ath/ath10k/htt_rx.c: patch does not apply
> stg import: Diff does not apply cleanly
[shafi] thanks, will rebase/fix this and send a v2
>
> Patch set to Changes Requested.
>
> --
> https://patchwork.kernel.org/patch/9351833/
>
> Documentation about submitting wireless patches and checking status
> from patchwork:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
^ permalink raw reply
* Re: [2/4] ath10k: implement offset_tsf ieee80211_op
From: Kalle Valo @ 2016-10-04 15:34 UTC (permalink / raw)
To: Pedersen, Thomas; +Cc: ath10k, Thomas Pedersen, linux-wireless
In-Reply-To: <20160928235631.9197-3-twp@qca.qualcomm.com>
"Pedersen, Thomas" <twp@qca.qualcomm.com> wrote:
> Current set_tsf is implemented in terms of TSF_INCREMENT
> only. Instead support new WMI command TSF_DECREMENT and
> export these through offset_tsf. Advantage is we get
> more accurate TSF adjustments, and don't calculate wrong
> offset in case absolute TSF was calculated from rx_mactime
> (actual TSF).
>
> The new WMI command is available in firmware
> 10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
> firmware or vice versa shouldn't be a problem since
> get/set tsf logic was already broken.
>
> Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
Depends on:
3a53731df7e2 mac80211: mesh: decrease max drift
354d381baf11 mac80211: add offset_tsf driver op and use it for mesh
2 patches set to Awaiting Upstream.
9355377 [2/4] ath10k: implement offset_tsf ieee80211_op
9355375 [3/4] ath10k: remove set/get_tsf ieee80211_ops
--
https://patchwork.kernel.org/patch/9355377/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Kalle Valo @ 2016-10-04 15:30 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1474981314-15987-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_htt_rx_h_unchain' is need to be called only if the return
> value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> change makes it more explicit and avoids doing a skb_peek, fetching
> rx descriptor pointer, checking rx msdu decap format for the case of
> ret = 0 (unchained msdus). Found this change during code walk through,
> not sure if this addresses any issue.
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Failed to apply to pending branch
error: patch failed: drivers/net/wireless/ath/ath10k/htt_rx.c:1550
error: drivers/net/wireless/ath/ath10k/htt_rx.c: patch does not apply
stg import: Diff does not apply cleanly
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9351833/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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