* [PATCH 1/5] qtnfmac: modify full Tx queue error reporting
From: Sergey Matyukevich @ 2017-10-15 20:53 UTC (permalink / raw)
To: linux-wireless
Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov, Sergey Matyukevich
In-Reply-To: <20171015205327.9966-1-sergey.matyukevich.os@quantenna.com>
Under heavy load it is normal that h/w Tx queue is almost full all the time
and reclaim should be done before transmitting next packet. Warning still
should be reported as well as s/w Tx queues should be stopped in the
case when reclaim failed.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 502e72b7cdcc..a8f2c46f3a25 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -643,11 +643,11 @@ static int qtnf_tx_queue_ready(struct qtnf_pcie_bus_priv *priv)
{
if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
priv->tx_bd_num)) {
- pr_err_ratelimited("reclaim full Tx queue\n");
qtnf_pcie_data_tx_reclaim(priv);
if (!CIRC_SPACE(priv->tx_bd_w_index, priv->tx_bd_r_index,
priv->tx_bd_num)) {
+ pr_warn_ratelimited("reclaim full Tx queue\n");
priv->tx_full_count++;
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 2/5] qtnfmac: enable registration of more mgmt frames
From: Sergey Matyukevich @ 2017-10-15 20:53 UTC (permalink / raw)
To: linux-wireless
Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov, Sergey Matyukevich
In-Reply-To: <20171015205327.9966-1-sergey.matyukevich.os@quantenna.com>
Support registration for more mgmt frame types
for debug and monitoring purposes.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 028bed1acd82..b4c2fa7934fd 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -73,7 +73,10 @@ qtnf_mgmt_stypes[NUM_NL80211_IFTYPES] = {
[NL80211_IFTYPE_AP] = {
.tx = BIT(IEEE80211_STYPE_ACTION >> 4),
.rx = BIT(IEEE80211_STYPE_ACTION >> 4) |
- BIT(IEEE80211_STYPE_PROBE_REQ >> 4),
+ BIT(IEEE80211_STYPE_PROBE_REQ >> 4) |
+ BIT(IEEE80211_STYPE_ASSOC_REQ >> 4) |
+ BIT(IEEE80211_STYPE_REASSOC_REQ >> 4) |
+ BIT(IEEE80211_STYPE_AUTH >> 4),
},
};
@@ -349,6 +352,13 @@ qtnf_mgmt_frame_register(struct wiphy *wiphy, struct wireless_dev *wdev,
return;
switch (frame_type & IEEE80211_FCTL_STYPE) {
+ case IEEE80211_STYPE_REASSOC_REQ:
+ case IEEE80211_STYPE_ASSOC_REQ:
+ qlink_frame_type = QLINK_MGMT_FRAME_ASSOC_REQ;
+ break;
+ case IEEE80211_STYPE_AUTH:
+ qlink_frame_type = QLINK_MGMT_FRAME_AUTH;
+ break;
case IEEE80211_STYPE_PROBE_REQ:
qlink_frame_type = QLINK_MGMT_FRAME_PROBE_REQ;
break;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/5] qtnfmac: drop nonexistent function declaration
From: Sergey Matyukevich @ 2017-10-15 20:53 UTC (permalink / raw)
To: linux-wireless
Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov, Sergey Matyukevich
In-Reply-To: <20171015205327.9966-1-sergey.matyukevich.os@quantenna.com>
Function qtnf_classify_skb_no_mbss has been used for debug
during early stage of development. Drop its declaration.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/core.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 44a2cbb19310..49ae700f66f0 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -153,9 +153,6 @@ int qtnf_cmd_send_get_phy_params(struct qtnf_wmac *mac);
struct qtnf_wmac *qtnf_core_get_mac(const struct qtnf_bus *bus, u8 macid);
struct net_device *qtnf_classify_skb(struct qtnf_bus *bus, struct sk_buff *skb);
-struct net_device *qtnf_classify_skb_no_mbss(struct qtnf_bus *bus,
- struct sk_buff *skb);
-
void qtnf_virtual_intf_cleanup(struct net_device *ndev);
void qtnf_netdev_updown(struct net_device *ndev, bool up);
--
2.11.0
^ permalink raw reply related
* [PATCH 4/5] qtnfmac: modify full Tx queue recovery
From: Sergey Matyukevich @ 2017-10-15 20:53 UTC (permalink / raw)
To: linux-wireless
Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov, Sergey Matyukevich
In-Reply-To: <20171015205327.9966-1-sergey.matyukevich.os@quantenna.com>
Current recovery approach is to wake s/w Tx queues for skb->dev netdevice.
However this approach doesn't cover the case when h/w queue is full of
packets from a single wireless interface. Suppose xmit attempt from the
second wireless interface fails due to failed reclaim. Then the second
interface will not have a chance to recover even if subsequent reclaims
succeed. Possible solution is to attempt to wake all the s/w queues
belonging to driver interfaces.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/core.c | 27 ++++++++++++++++++++++
drivers/net/wireless/quantenna/qtnfmac/core.h | 1 +
.../net/wireless/quantenna/qtnfmac/pearl/pcie.c | 13 +++++++----
.../quantenna/qtnfmac/pearl/pcie_bus_priv.h | 1 +
4 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c b/drivers/net/wireless/quantenna/qtnfmac/core.c
index 5e60180482d1..5fd1a9c8b733 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
@@ -618,6 +618,33 @@ struct net_device *qtnf_classify_skb(struct qtnf_bus *bus, struct sk_buff *skb)
}
EXPORT_SYMBOL_GPL(qtnf_classify_skb);
+void qtnf_wake_all_queues(struct net_device *ndev)
+{
+ struct qtnf_vif *vif = qtnf_netdev_get_priv(ndev);
+ struct qtnf_wmac *mac;
+ struct qtnf_bus *bus;
+ int macid;
+ int i;
+
+ if (unlikely(!vif || !vif->mac || !vif->mac->bus))
+ return;
+
+ bus = vif->mac->bus;
+
+ for (macid = 0; macid < QTNF_MAX_MAC; macid++) {
+ if (!(bus->hw_info.mac_bitmap & BIT(macid)))
+ continue;
+
+ mac = bus->mac[macid];
+ for (i = 0; i < QTNF_MAX_INTF; i++) {
+ vif = &mac->iflist[i];
+ if (vif->netdev && netif_queue_stopped(vif->netdev))
+ netif_tx_wake_all_queues(vif->netdev);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(qtnf_wake_all_queues);
+
MODULE_AUTHOR("Quantenna Communications");
MODULE_DESCRIPTION("Quantenna 802.11 wireless LAN FullMAC driver.");
MODULE_LICENSE("GPL");
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 49ae700f66f0..da2c24e2271d 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -153,6 +153,7 @@ int qtnf_cmd_send_get_phy_params(struct qtnf_wmac *mac);
struct qtnf_wmac *qtnf_core_get_mac(const struct qtnf_bus *bus, u8 macid);
struct net_device *qtnf_classify_skb(struct qtnf_bus *bus, struct sk_buff *skb);
+void qtnf_wake_all_queues(struct net_device *ndev);
void qtnf_virtual_intf_cleanup(struct net_device *ndev);
void qtnf_netdev_updown(struct net_device *ndev, bool up);
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index a8f2c46f3a25..3d88a0b2b5f5 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -617,9 +617,10 @@ static void qtnf_pcie_data_tx_reclaim(struct qtnf_pcie_bus_priv *priv)
if (skb->dev) {
skb->dev->stats.tx_packets++;
skb->dev->stats.tx_bytes += skb->len;
-
- if (netif_queue_stopped(skb->dev))
- netif_wake_queue(skb->dev);
+ if (unlikely(priv->tx_stopped)) {
+ qtnf_wake_all_queues(skb->dev);
+ priv->tx_stopped = 0;
+ }
}
dev_kfree_skb_any(skb);
@@ -666,8 +667,10 @@ static int qtnf_pcie_data_tx(struct qtnf_bus *bus, struct sk_buff *skb)
int ret = 0;
if (!qtnf_tx_queue_ready(priv)) {
- if (skb->dev)
- netif_stop_queue(skb->dev);
+ if (skb->dev) {
+ netif_tx_stop_all_queues(skb->dev);
+ priv->tx_stopped = 1;
+ }
return NETDEV_TX_BUSY;
}
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
index e76a23716ee0..e477abec5f3b 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_bus_priv.h
@@ -35,6 +35,7 @@ struct qtnf_pcie_bus_priv {
/* lock for tx reclaim operations */
spinlock_t tx_reclaim_lock;
u8 msi_enabled;
+ u8 tx_stopped;
int mps;
struct workqueue_struct *workqueue;
--
2.11.0
^ permalink raw reply related
* [PATCH 5/5] qtnfmac: advertise support of inactivity timeout
From: Sergey Matyukevich @ 2017-10-15 20:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Igor Mitsyanko, Avinash Patil, Vasily Ulyanov
In-Reply-To: <20171015205327.9966-1-sergey.matyukevich.os@quantenna.com>
From: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Wireless device may implement a logic to kick-out STA due to inactivity
for a certain period of time. This feature needs to be advertised to
higher layers if supported. Timeout value is still taken from
parameters to START_AP command, nothing changes here.
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 5 ++++-
drivers/net/wireless/quantenna/qtnfmac/commands.c | 5 +++--
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 11 ++++++++++-
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index b4c2fa7934fd..b9841c0d952f 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -955,7 +955,10 @@ int qtnf_wiphy_register(struct qtnf_hw_info *hw_info, struct qtnf_wmac *mac)
ether_addr_copy(wiphy->perm_addr, mac->macaddr);
- if (hw_info->hw_capab & QLINK_HW_SUPPORTS_REG_UPDATE) {
+ if (hw_info->hw_capab & QLINK_HW_CAPAB_STA_INACT_TIMEOUT)
+ wiphy->features |= NL80211_FEATURE_INACTIVITY_TIMER;
+
+ if (hw_info->hw_capab & QLINK_HW_CAPAB_REG_UPDATE) {
wiphy->regulatory_flags |= REGULATORY_STRICT_REG |
REGULATORY_CUSTOM_REG;
wiphy->reg_notifier = qtnf_cfg80211_reg_notifier;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index babdc600c193..b81f81bd1411 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -975,10 +975,11 @@ qtnf_cmd_resp_proc_hw_info(struct qtnf_bus *bus,
return -EINVAL;
}
- pr_info("fw_version=%d, MACs map %#x, alpha2=\"%c%c\", chains Tx=%u Rx=%u\n",
+ pr_info("fw_version=%d, MACs map %#x, alpha2=\"%c%c\", chains Tx=%u Rx=%u, capab=0x%x\n",
hwinfo->fw_ver, hwinfo->mac_bitmap,
hwinfo->rd->alpha2[0], hwinfo->rd->alpha2[1],
- hwinfo->total_tx_chain, hwinfo->total_rx_chain);
+ hwinfo->total_tx_chain, hwinfo->total_rx_chain,
+ hwinfo->hw_capab);
return 0;
}
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index 7b313d38c30b..0f582782682f 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -61,8 +61,17 @@ struct qlink_msg_header {
/* Generic definitions of data and information carried in QLINK messages
*/
+/**
+ * enum qlink_hw_capab - device capabilities.
+ *
+ * @QLINK_HW_CAPAB_REG_UPDATE: device can update it's regulatory region.
+ * @QLINK_HW_CAPAB_STA_INACT_TIMEOUT: device implements a logic to kick-out
+ * associated STAs due to inactivity. Inactivity timeout period is taken
+ * from QLINK_CMD_START_AP parameters.
+ */
enum qlink_hw_capab {
- QLINK_HW_SUPPORTS_REG_UPDATE = BIT(0),
+ QLINK_HW_CAPAB_REG_UPDATE = BIT(0),
+ QLINK_HW_CAPAB_STA_INACT_TIMEOUT = BIT(1),
};
enum qlink_phy_mode {
--
2.11.0
^ permalink raw reply related
* RE: Two rtlwifi drivers?
From: Pkshih @ 2017-10-16 2:41 UTC (permalink / raw)
To: Larry Finger, Kalle Valo, Greg Kroah-Hartman
Cc: Dan Carpenter, 莊彥宣, Johannes Berg,
Souptick Joarder, devel@driverdev.osuosl.org,
linux-wireless@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20171012103450.GA24647@kroah.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogR3JlZyBLcm9haC1IYXJ0
bWFuIFttYWlsdG86Z3JlZ2toQGxpbnV4Zm91bmRhdGlvbi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5
LCBPY3RvYmVyIDEyLCAyMDE3IDY6MzUgUE0NCj4gVG86IEthbGxlIFZhbG8NCj4gQ2M6IExhcnJ5
IEZpbmdlcjsgRGFuIENhcnBlbnRlcjsgUGtzaGloOyCy+Kvbq8U7IEpvaGFubmVzIEJlcmc7IFNv
dXB0aWNrIEpvYXJkZXI7DQo+IGRldmVsQGRyaXZlcmRldi5vc3Vvc2wub3JnOyBsaW51eC13aXJl
bGVzc0B2Z2VyLmtlcm5lbC5vcmc7IGtlcm5lbC1qYW5pdG9yc0B2Z2VyLmtlcm5lbC5vcmcNCj4g
U3ViamVjdDogUmU6IFR3byBydGx3aWZpIGRyaXZlcnM/DQo+IA0KPiBPbiBUaHUsIE9jdCAxMiwg
MjAxNyBhdCAxMTozODowNkFNICswMzAwLCBLYWxsZSBWYWxvIHdyb3RlOg0KPiA+ID4gU28gd2hh
dCB0byBkbz8gIEFueSBpZGVhcz8gIFdoYXQgbWFrZXMgeW91ciBsaWZlIGVhc2llcj8gIFlvdSBj
YW4ganVzdA0KPiA+ID4gaWdub3JlIHRoZSBzdGFnaW5nIHRyZWUsIGFzIGl0IHNob3VsZCBub3Qg
YWZmZWN0IHlvdXIgcG9ydGlvbiBvZiB0aGUNCj4gPiA+IGtlcm5lbCBhdCBhbGwsIHJpZ2h0Pw0K
PiA+DQo+ID4gWWVzLCBJIGF1dG9tYXRpY2FsbHkgaWdub3JlIGFueXRoaW5nIHN0YWdpbmcgcmVs
YXRlZC4gQnV0IHRoZSBwcm9ibGVtIGlzDQo+ID4gdGhhdCB3ZSBub3cgaGF2ZSB0d28gZHJpdmVy
cyB3aXRoIHRoZSBzYW1lIG5hbWUgYW5kIHBlb3BsZSBkb24ndCBhbHdheXMNCj4gPiByZW1lbWJl
ciB0byBwcmVmaXggdGhlIHBhdGNoIHdpdGggInN0YWdpbmc6ICIuIFNvIG9uIGEgYmFkIGRheSBJ
IG1pZ2h0DQo+ID4gYWNjaWRlbnRhbGx5IGFwcGx5IGEgcGF0Y2ggd2hpY2ggd2FzIG1lYW50IGZv
ciB5b3VyIHRyZWUuIE9mIGNvdXJzZSBJDQo+ID4gaW1tZWRpYXRlbHkgcmV2ZXJ0IGl0IGFzIHNv
b24gYXMgSSwgb3Igc29tZW9uZSBlbHNlLCBjYXRjaGVzIHRoYXQgYnV0DQo+ID4gYW5ub3lpbmcg
c3RpbGwuDQo+IA0KPiBJdCBkb2Vzbid0IGJvdGhlciBtZSBpZiB5b3UgYXBwbHkgc3RhZ2luZyBw
YXRjaGVzLCBJIGNhbiBoYW5kbGUgdGhlDQo+IG1lcmdlIGlzc3VlcyA6KQ0KPiANCj4gPiBJIHRo
aW5rIHdlIGhhdmUgdHdvIG9wdGlvbnMgaGVyZToNCj4gPg0KPiA+IDEpIFdlIHNldCBhIGRlYWRs
aW5lIChsaWtlIDEyIG1vbnRocyBvciBzb21ldGhpbmcpIGZvciB0aGUNCj4gPiAgICBkcml2ZXJz
L3N0YWdpbmcvcnRsd2lmaSBhbmQgYWZ0ZXIgdGhhdCB5b3UgcmVmdXNlIHRvIHRha2UgYW55IHBh
dGNoZXMNCj4gPiAgICBmb3IgaXQuIEhvcGVmdWxseSB0aGlzIG1ha2VzIGl0IGNsZWFyIGZvciBl
dmVyeW9uZSB0aGF0IHRoaXMgZm9yayBpcw0KPiA+ICAgIGp1c3QgdGVtcG9yYXJ5LiBJIHRoaW5r
IExhcnJ5IGlzIHRyeWluZyB0byBkbyB0aGlzLCB3aGljaCBpcyBncmVhdC4NCj4gDQo+IEZpbmUg
d2l0aCBtZSwgaWYgTGFycnkgaXMgb2sgd2l0aCBpdC4NCj4gDQo+ID4gMikgV2UgbW92ZSB0aGUg
d2hvbGUgcnRsd2lmaSBkcml2ZXIgdG8gc3RhZ2luZy4gQSB2ZXJ5IGJhZCBvcHRpb24gYnV0DQo+
ID4gICAgc3RpbGwgYmV0dGVyIHRoYW4gZm9ya2luZyB0aGUgZHJpdmVycy4NCj4gDQo+IEljaywg
SSBkb24ndCB3YW50IHRoYXQgdG8gaGF2ZSB0byBoYXBwZW4sIHRoYXQgd291bGQgbm90IGJlIGdv
b2QgZm9yIHRoZQ0KPiB1c2VycyBvZiBvdGhlciBkZXZpY2VzIHRoYXQgdGhlICJyZWFsIiBydGx3
aWZpIGRyaXZlciBzdXBwb3J0cy4NCj4gDQoNCkhpIExhcnJ5LCBLYWxsZSBhbmQgR2VyZywNCg0K
VGhpcyBpcyBSZWFsdGVrIGVuZ2luZWVyLCBQSy4gSSBhcHByZWNpYXRlIHlvdXIgc3VwcG9ydCB0
byBzdWJtaXQsIHJldmlldyANCmFuZCBtZXJnZSBwYXRjaC4gU2luY2UgSSdtIGEgTGludXggbmV3
YmllLCBJJ2xsIGRlc2NyaWJlIHRoZSBzaXR1YXRpb24gb2YgDQpydGx3aWZpIGFuZCBuZWVkIHlv
dXIgc3VnZ2VzdGlvbnMuDQoNCg0KMSkgTmV3IG1vZHVsZXMgaW4gcnRsd2lmaQ0KICAgV2UgYWRk
IHR3byBtb2R1bGVzIG5hbWVkIHBoeWRtIGFuZCBoYWxtYWMsIHdoZW4gYWRkaW5nIHJ0bDg4MjJi
ZSBpbiANCiAgIHN0YWdpbmcuIFRoZSBwaHlkbSBpcyBCQi9SRiByZWxhdGVkIG1vZHVsZSBjb250
YWluaW5nIHRoZSBwYXJhbWV0ZXJzDQogICBhbmQgQVBJcyBvZiBCQi9SRiwgYW5kIGEgZHluYW1p
YyBtZWNoYW5pc20gdG8gYWRhcHQgdG8gZGlmZmVyZW50DQogICBmaWVsZCBlbnZpcm9ubWVudC4g
VGhlIGhhbG1hYyBjb25zaXN0cyBvZiBNQUMgQVBJcy4NCiAgIFRoZSB0d28gbW9kdWxlcyBhcmUg
dXNlZCBieSBtYW55IE9Tcywgc28gJyNpZmRlZicsIENhbWVsQ2FzZSBhbmQNCiAgIHNvIG9uIGFy
ZSBleGlzdGluZyBpbiBvcmlnaW5hbCBmaWxlcy4gSGVuY2UsIHdlIGNvbnZlcnQgdGhlbSB0byBM
aW51eCANCiAgIGZvcm0gYnkgc2NyaXB0LCBidXQgaXQncyBub3QgcGVyZmVjdC4gRG8geW91IGhh
dmUgc3VnZ2VzdGlvbiB0byBkZWFsDQogICB3aXRoIHRoaXMgcHJvYmxlbT8NCg0KDQoyKSBUaGUg
cnRsd2lmaSBpbiBzdGFnaW5nDQogICBJbiBzdGFnaW5nLCB0aGUgbW9kdWxlIHBoeWRtIHYxMyBj
b250YWlucyBidWdzLCBzbyBJIHdhbnQgdG8gdXBncmFkZQ0KICAgdG8gdjIxIChSZWFsdGVrIGlu
dGVybmFsIHZlcnNpb24gbnVtYmVyKS4gVGhpcyB1cGdyYWRlIGNvbnRhaW5zIGENCiAgIGJpZyBw
YXRjaCB0aGF0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdjEzIGFuZCB2MjEsIGFuZCB0aGVyZSBh
cmUgDQogICA0MCsgcGF0Y2hlcyB0byBzdXBwb3J0IHRoaXMgdXBncmFkZS4gSSBoYXZlIHRocmVl
IG9wdGlvbnMsIGFuZA0KICAgSSB3YW50IHRvIGtub3cgd2hpY2ggb25lIGlzIHByZWZlci4NCg0K
Mi4xKSBhcHBseSA0MCsgcGF0Y2hlcyB0byBib3RoIHN0YWdpbmcgYW5kIHdpcmVsZXNzIHRyZWUs
IGFuZCBhcHBseQ0KICAgICB0aGUgYmlnIHBhdGNoIHRvIHN0YWdpbmcgb25seS4gQWZ0ZXIgcmV2
aWV3aW5nLCB3ZSBtb3ZlIHRoZSBtb2R1bGUNCiAgICAgdG8gd2lyZWxlc3MgdHJlZS4NCg0KMi4y
KSBhcHBseSA0MCsgcGF0Y2hlcyB0byB3aXJlbGVzcyB0cmVlLCBhbmQgYXBwbHkgYSBzaW5nbGUg
YmlnZ2VyIA0KICAgICBwYXRjaCBjb250YWluaW5nIDQwKyBwYXRjaGVzIGFuZCB0aGUgYmlnIHBh
dGNoIHRvIHN0YWdpbmcuIEkgdGhpbmsNCiAgICAgdGhpcyBjYW4gYmUgc2VlbiBhcyBhIG5ldyBk
cml2ZXIgaW4gc3RhZ2luZy4gQWZ0ZXIgcmV2aWV3aW5nLCANCiAgICAgd2UgbW92ZSB0aGUgbW9k
dWxlIHRvIHdpcmVsZXNzIHRyZWUuDQoNCjIuMykgZG9uJ3QgYXBwbHkgYW55dGhpbmcgdG8gc3Rh
Z2luZy4gSnVzdCBhcHBseSA0MCsgcGF0Y2hlcyBhbmQgYWRkDQogICAgIHBoeWRtIHYyMSB0byB3
aXJlbGVzcy4NCg0KDQozKSBDb21pbmcgZHJpdmVycyAtLSBydGw4NzIzZGUgYW5kIHJ0bDg4MjFj
ZQ0KICAgV2UncmUgZGV2ZWxvcGluZyB0aGUgdHdvIGRyaXZlcnMsIGFuZCBydGw4NzIzZGUgYW5k
IHJ0bDg4MjFjZSB3aWxsDQogICBiZSByZWFkeSBvbiAyMDE3UTQgYW5kIDIwMThRMSByZXNwZWN0
aXZlbHkuIFRoZSBkcml2ZXJzIGFyZSBiYXNlZCBvbg0KICAgcnRsODgyMmJlIHRoYXQgaW4gc3Rh
Z2luZyBub3csIHNvIHRoZSBsaW5lIG9mIGNvZGUgd2lsbCBiZSBmZXdlci4NCiAgIFRoZSBuZXcg
ZmlsZXMgd2lsbCBiZSBhIG5ldyBJQyBmb2xkZXIgYW5kIElDIHN1cHBvcnRlZCBmaWxlcyBvZiAN
CiAgIHRocmVlIG1vZHVsZXMgdGhhdCBidGNvZXhpc3QsIHBoeWRtIGFuZCBoYWxtYWMuIENvdWxk
IEkgc3VibWl0DQogICB0aGVtIHRvIHdpcmxlc3MgdHJlZSB3aGVuIHRoZXkncmUgcmVhZHk/DQoN
Cg0KNCkgQXMgS2FsbGUgbWVudGlvbmVkLCBydGx3aWZpIGNvbnRhaW5zIG1hbnkgbWFnaWMgbnVt
YmVycywgYW5kIEkgDQogICBwbGFuIHRvIGZpeCB0aGVtIGFmdGVyIHJ0bDg3MjNkZSBhbmQgcnRs
ODgyMWNlLiBCZWNhdXNlIHRoZSBkcml2ZXJzDQogICBhcmUgZGV2ZWxvcGluZywgdGhlIGNoYW5n
ZXMgd2lsbCBtYWtlIHVzIGhhcmQgdG8gaW50ZWdyYXRlLiBIb3dldmVyLA0KICAgSSBkb24ndCBo
YXZlIHBsYW4gdG8gcHJvY2VzcyB0aGUgbWFnaWMgbnVtYmVycyBpbiB0aGUgbW9kdWxlIHBoeWRt
LA0KICAgYmVjYXVzZSB0aGUgbW9zdCBvZiBCQi9SRiByZWdpc3RlcnMgY29udGFpbiBtYW55IGZ1
bmN0aW9ucy4gQW5kDQogICBpdCBkb2Vzbid0IGhhdmUgYSByZWdpc3RlciBuYW1lIGJ1dCBhIGJp
dCBmaWVsZCBuYW1lIGluc3RlYWQuDQogICBPdXIgQkIgdGVhbSBndXlzIHNheSB0aGUgdXNlIG9m
IGVudW1lcmF0aW9uIG9yIGRlZmluZWQgbmFtZSB3aWxsDQogICBiZSB1bnJlYWRhYmxlLCBhbmQg
dGhlIG5hbWUgaXMgbWVhbmluZ2xlc3MgZm9yIG1vc3QgcGVvcGxlLg0KDQoNCk1hbnkgTGludXgg
dXNlcnMgYXNrIExhcnJ5IGFib3V0IHRoZSBuZXcgZHJpdmVycywgYW5kIFJlYWx0ZWsgd2lsbA0K
cHJvdmlkZSBkcml2ZXJzIGFuZCB0cnkgdG8gc3VibWl0IHRoZW0gYnkgbXlzZWxmLiBJIGhvcGUg
dGhlIExpbnV4DQp1c2VycyBjYW4geWllbGQgdGhlIGRyaXZlcnMgYXMgc29vbiBhcyBJIGNhbi4g
T24gdGhlIHdheSwgSSdsbCANCmF0dGVuZCBuZXRkZXYgd29ya3Nob3AgaW4gS29yZWEsIHNvIHdl
IGNhbiBtZWV0IHRoZXJlIGlmIHlvdSBhdHRlbmQgdG9vLg0KDQoNClBLDQoNCg==
^ permalink raw reply
* Re: iwlwifi crash with hostapd
From: James Cameron @ 2017-10-16 3:37 UTC (permalink / raw)
To: Mario Theodoridis; +Cc: linux-wireless
In-Reply-To: <b985bbb0-ec49-0506-871e-b65837b05be2@schmut.com>
On Sun, Oct 15, 2017 at 06:21:36PM +0200, Mario Theodoridis wrote:
> Thanks for the pointers, James.
>
> On 12.10.2017 23:24, James Cameron wrote:
> >There's a good chance this problem has been fixed already. You
> >are using a v4.4 kernel with many patches applied by Ubuntu. Here, we
> >are more concerned with the latest kernels, and v4.4 is quite old.
> >
> >Please test some of the later kernels, see
> >https://wiki.ubuntu.com/Kernel/MainlineBuilds
> >
> >In particular, test v4.13 or v4.14-rc4.
>
> I'm having a hard time with that, because the virtualbox-dkms build fails
> with the 4.13 kernel, and virtualbox unfortunately is essential.
Is virtualbox essential for reproducing the problem, or essential for
your general use?
If the former, then that's interesting.
If the latter, then you might instead test the v4.13 or v14-rc4
kernels for only the problem, and then revert to an older kernel after
testing.
Either way, to use virtualbox-dkms with a later kernel you may be able
to upgrade just the virtualbox packages from a later Ubuntu release.
See https://packages.ubuntu.com/virtualbox-dkms and
https://packages.ubuntu.com/virtualbox for the later versions available.
Purpose of the test can be to help isolate the cause, not only to
solve your problem.
> >If the problem still happens, capture the same information and send it
> >again as a reply.
> >
> >If the problem doesn't happen, then you can either continue to use the
> >new kernel, or find when the problem was fixed; a long but rewarding
> >process.
> >
> >Should the problem have been fixed for v4.10, you might also switch to
> >using the Ubuntu package linux-generic-hwe-16.04.
> >https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack#hwe-16.04
>
> The 4.10 kernel readily produced this one
>
> ------------[ cut here ]------------
> WARNING: CPU: 4 PID: 1617 at /build/linux-hwe-IJy1zi/linux-hwe-4.10.0/drivers/net/wireless/intel/iwlwifi/mvm/tx.c:510
> iwl_mvm_tx_skb_non_sta+0x39a/0x440 [iwlmvm]
> Modules linked in: bnep ccm pci_stub vboxpci(OE) vboxnetadp(OE)
> vboxnetflt(OE) vboxdrv(OE) nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter
> ip_tables x_tables snd_hda_codec_hdmi arc4 iwlmvm mac80211
> snd_hda_codec_realtek snd_hda_codec_generic intel_rapl x86_pkg_temp_thermal
> intel_powerclamp iwlwifi coretemp snd_hda_intel snd_hda_codec kvm_intel
> snd_hda_core snd_hwdep kvm input_leds irqbypass crct10dif_pclmul snd_pcm
> bridge crc32_pclmul joydev stp llc ghash_clmulni_intel snd_seq_midi pcbc
> snd_seq_midi_event snd_rawmidi aesni_intel snd_seq aes_x86_64 crypto_simd
> snd_seq_device glue_helper cfg80211 cryptd snd_timer intel_cstate snd
> intel_rapl_perf soundcore shpchp mei_me hci_uart mei btbcm btqca btintel
> bluetooth intel_lpss_acpi
> acpi_als mac_hid intel_lpss kfifo_buf tpm_infineon industrialio acpi_pad
> parport_pc ppdev lp parport autofs4 i915 e1000e i2c_algo_bit drm_kms_helper
> syscopyarea sysfillrect sysimgblt fb_sys_fops e100 hid_generic ptp i2c_hid
> ahci mii drm pps_core pinctrl_sunrisepoint libahci usbhid e1000 hid wmi
> video pinctrl_intel fjes
> CPU: 4 PID: 1617 Comm: hostapd Tainted: G OE 4.10.0-37-generic
> #41~16.04.1-Ubuntu
> Hardware name: Gigabyte Technology Co., Ltd. Z170M-D3H/Z170M-D3H-CF, BIOS
> F20 11/17/2016
> Call Trace:
> dump_stack+0x63/0x90
> __warn+0xcb/0xf0
> warn_slowpath_null+0x1d/0x20
> iwl_mvm_tx_skb_non_sta+0x39a/0x440 [iwlmvm]
> iwl_mvm_mac_tx+0x11e/0x1d0 [iwlmvm]
> ieee80211_tx_frags+0x14b/0x220 [mac80211]
> __ieee80211_tx+0x81/0x180 [mac80211]
> ieee80211_tx+0x10f/0x150 [mac80211]
> ieee80211_xmit+0x9b/0xf0 [mac80211]
> __ieee80211_tx_skb_tid_band+0x5c/0x70 [mac80211]
> ieee80211_mgmt_tx+0x42c/0x4a0 [mac80211]
> cfg80211_mlme_mgmt_tx+0xdc/0x310 [cfg80211]
> nl80211_tx_mgmt+0x212/0x360 [cfg80211]
> genl_family_rcv_msg+0x1db/0x3b0
> ? skb_queue_tail+0x43/0x50
> genl_rcv_msg+0x59/0xa0
> ? genl_notify+0x80/0x80
> netlink_rcv_skb+0xa4/0xc0
> genl_rcv+0x28/0x40
> netlink_unicast+0x18c/0x240
> netlink_sendmsg+0x2fb/0x3a0
> ? aa_sock_msg_perm+0x61/0x150
> sock_sendmsg+0x38/0x50
> ___sys_sendmsg+0x2c2/0x2d0
> ? sock_sendmsg+0x38/0x50
> ? SYSC_sendto+0x101/0x190
> ? __check_object_size+0x108/0x1e3
> ? _copy_to_user+0x55/0x60
> __sys_sendmsg+0x54/0x90
> SyS_sendmsg+0x12/0x20
> entry_SYSCALL_64_fastpath+0x1e/0xad
> RIP: 0033:0x7fcc38cfe450
> RSP: 002b:00007fffdefc9b18 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 0000563e91285590 RCX: 00007fcc38cfe450
> RDX: 0000000000000000 RSI: 00007fffdefc9ba0 RDI: 0000000000000005
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000563e91283a70
> R10: 0000000000001000 R11: 0000000000000246 R12: 0000000000000000
> R13: 0000000000000009 R14: 0000000000000000 R15: 0000000000000000
>
> ---[ end trace 4d9a544d3976536e ]---
You might also try with later firmware package.
See https://packages.ubuntu.com/linux-firmware
You might also test with booting installation media in live-mode,
ignoring the internal disk.
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* [PATCH V6 0/5] Add TDLS feature for ath10k
From: yintang @ 2017-10-16 6:00 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <TDLS for ath10k patches V6>
From: Yingying Tang <yintang@qti.qualcomm.com>
This patchset is for Rome PCIE chip, it will not affect other hardware
Yingying Tang (5):
mac80211: Enable TDLS peer buffer STA feature
ath10k: Enable TDLS peer buffer STA feature
ath10k: Enable TDLS peer inactivity detection
ath10k: Avoid to set WEP key for TDLS peer
ath10k: Fix TDLS peer TX data failure issue on encryped AP
drivers/net/wireless/ath/ath10k/mac.c | 9 ++++-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 55 +++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 9 +++++
drivers/net/wireless/ath/ath10k/wmi.h | 1 +
include/net/mac80211.h | 4 +++
net/mac80211/tdls.c | 5 ++-
6 files changed, 81 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH V6 1/5] mac80211: Enable TDLS peer buffer STA feature
From: yintang @ 2017-10-16 6:00 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1508133633-23214-1-git-send-email-yintang@qti.qualcomm.com>
From: Yingying Tang <yintang@qti.qualcomm.com>
Enable TDLS peer buffer STA feature.
Set extended capability bit to enable buffer STA when driver
support it.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
---
include/net/mac80211.h | 4 ++++
net/mac80211/tdls.c | 5 ++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index f8149ca..5928123 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2067,6 +2067,9 @@ struct ieee80211_txq {
* The stack will not do fragmentation.
* The callback for @set_frag_threshold should be set as well.
*
+ * @IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA: Hardware support buffer STA when
+ * TDLS is established.
+ *
* @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
*/
enum ieee80211_hw_flags {
@@ -2109,6 +2112,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_TX_FRAG_LIST,
IEEE80211_HW_REPORTS_LOW_ACK,
IEEE80211_HW_SUPPORTS_TX_FRAG,
+ IEEE80211_HW_SUPPORTS_TDLS_BUFFER_STA,
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/tdls.c b/net/mac80211/tdls.c
index 91093d4..8231466 100644
--- a/net/mac80211/tdls.c
+++ b/net/mac80211/tdls.c
@@ -47,6 +47,8 @@ static void ieee80211_tdls_add_ext_capab(struct ieee80211_sub_if_data *sdata,
NL80211_FEATURE_TDLS_CHANNEL_SWITCH;
bool wider_band = ieee80211_hw_check(&local->hw, TDLS_WIDER_BW) &&
!ifmgd->tdls_wider_bw_prohibited;
+ bool buffer_sta = ieee80211_hw_check(&local->hw,
+ SUPPORTS_TDLS_BUFFER_STA);
struct ieee80211_supported_band *sband = ieee80211_get_sband(sdata);
bool vht = sband && sband->vht_cap.vht_supported;
u8 *pos = skb_put(skb, 10);
@@ -56,7 +58,8 @@ static void ieee80211_tdls_add_ext_capab(struct ieee80211_sub_if_data *sdata,
*pos++ = 0x0;
*pos++ = 0x0;
*pos++ = 0x0;
- *pos++ = chan_switch ? WLAN_EXT_CAPA4_TDLS_CHAN_SWITCH : 0;
+ *pos++ = (chan_switch ? WLAN_EXT_CAPA4_TDLS_CHAN_SWITCH : 0) |
+ (buffer_sta ? WLAN_EXT_CAPA4_TDLS_BUFFER_STA : 0);
*pos++ = WLAN_EXT_CAPA5_TDLS_ENABLED;
*pos++ = 0;
*pos++ = 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V6 2/5] ath10k: Enable TDLS peer buffer STA feature
From: yintang @ 2017-10-16 6:00 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1508133633-23214-1-git-send-email-yintang@qti.qualcomm.com>
From: Yingying Tang <yintang@qti.qualcomm.com>
Enable TDLS peer buffer STA feature.
QCA6174 firmware(version: WLAN.RM.4.4) support TDLS peer buffer STA,
it reports this capability through wmi service map in wmi service ready
event. Set related parameter in TDLS WMI command to enable this feature.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 3 +++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5683f1a..1672043 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -8204,6 +8204,9 @@ int ath10k_mac_register(struct ath10k *ar)
ieee80211_hw_set(ar->hw, TDLS_WIDER_BW);
}
+ if (test_bit(WMI_SERVICE_TDLS_UAPSD_BUFFER_STA, ar->wmi.svc_map))
+ ieee80211_hw_set(ar->hw, SUPPORTS_TDLS_BUFFER_STA);
+
ar->hw->wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
ar->hw->wiphy->flags |= WIPHY_FLAG_HAS_CHANNEL_SWITCH;
ar->hw->wiphy->max_remain_on_channel_duration = 5000;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 7616c1c..f60b46e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -2747,6 +2747,9 @@ static void *ath10k_wmi_tlv_put_wmm(void *ptr,
*/
u32 options = 0;
+ if (test_bit(WMI_SERVICE_TDLS_UAPSD_BUFFER_STA, ar->wmi.svc_map))
+ options |= WMI_TLV_TDLS_BUFFER_STA_EN;
+
len = sizeof(*tlv) + sizeof(*cmd);
skb = ath10k_wmi_alloc_skb(ar, len);
if (!skb)
--
1.7.9.5
^ permalink raw reply related
* [PATCH V6 3/5] ath10k: Enable TDLS peer inactivity detection
From: yintang @ 2017-10-16 6:00 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1508133633-23214-1-git-send-email-yintang@qti.qualcomm.com>
From: Yingying Tang <yintang@qti.qualcomm.com>
Enable TDLS peer inactivity detetion feature.
QCA6174 firmware(version: WLAN.RM.4.4) support TDLS link inactivity detecting.
Set related parameters in TDLS WMI command to enable this feature.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 52 +++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 9 +++++
drivers/net/wireless/ath/ath10k/wmi.h | 1 +
3 files changed, 62 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index f60b46e..63bb2c4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -412,6 +412,49 @@ static int ath10k_wmi_tlv_event_tx_pause(struct ath10k *ar,
return 0;
}
+void ath10k_wmi_event_tdls_peer(struct ath10k *ar, struct sk_buff *skb)
+{
+ struct ieee80211_sta *station;
+ const struct wmi_tlv_tdls_peer_event *ev;
+ const void **tb;
+ struct ath10k_vif *arvif;
+
+ tb = ath10k_wmi_tlv_parse_alloc(ar, skb->data, skb->len, GFP_ATOMIC);
+ if (IS_ERR(tb)) {
+ ath10k_warn(ar, "tdls peer failed to parse tlv");
+ return;
+ }
+ ev = tb[WMI_TLV_TAG_STRUCT_TDLS_PEER_EVENT];
+ if (!ev) {
+ kfree(tb);
+ ath10k_warn(ar, "tdls peer NULL event");
+ return;
+ }
+
+ switch (ev->peer_reason) {
+ case WMI_TDLS_TEARDOWN_REASON_TX:
+ case WMI_TDLS_TEARDOWN_REASON_RSSI:
+ case WMI_TDLS_TEARDOWN_REASON_PTR_TIMEOUT:
+ station = ieee80211_find_sta_by_ifaddr(ar->hw,
+ ev->peer_macaddr.addr,
+ NULL);
+ if (!station) {
+ ath10k_warn(ar, "did not find station from tdls peer event");
+ kfree(tb);
+ return;
+ }
+ arvif = ath10k_get_arvif(ar, ev->vdev_id);
+ ieee80211_tdls_oper_request(
+ arvif->vif, station->addr,
+ NL80211_TDLS_TEARDOWN,
+ WLAN_REASON_TDLS_TEARDOWN_UNREACHABLE,
+ GFP_ATOMIC
+ );
+ break;
+ }
+ kfree(tb);
+}
+
/***********/
/* TLV ops */
/***********/
@@ -552,6 +595,9 @@ static void ath10k_wmi_tlv_op_rx(struct ath10k *ar, struct sk_buff *skb)
case WMI_TLV_TX_PAUSE_EVENTID:
ath10k_wmi_tlv_event_tx_pause(ar, skb);
break;
+ case WMI_TLV_TDLS_PEER_EVENTID:
+ ath10k_wmi_event_tdls_peer(ar, skb);
+ break;
default:
ath10k_warn(ar, "Unknown eventid: %d\n", id);
break;
@@ -2750,6 +2796,12 @@ static void *ath10k_wmi_tlv_put_wmm(void *ptr,
if (test_bit(WMI_SERVICE_TDLS_UAPSD_BUFFER_STA, ar->wmi.svc_map))
options |= WMI_TLV_TDLS_BUFFER_STA_EN;
+ /* WMI_TDLS_ENABLE_ACTIVE_EXTERNAL_CONTROL means firm will handle TDLS
+ * link inactivity detecting logic.
+ */
+ if (state == WMI_TDLS_ENABLE_ACTIVE)
+ state = WMI_TDLS_ENABLE_ACTIVE_EXTERNAL_CONTROL;
+
len = sizeof(*tlv) + sizeof(*cmd);
skb = ath10k_wmi_alloc_skb(ar, len);
if (!skb)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index 22cf011..8fdb381 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1641,6 +1641,15 @@ struct wmi_tlv_tx_pause_ev {
__le32 tid_map;
} __packed;
+struct wmi_tlv_tdls_peer_event {
+ struct wmi_mac_addr peer_macaddr;
+ __le32 peer_status;
+ __le32 peer_reason;
+ __le32 vdev_id;
+} __packed;
+
+
+
void ath10k_wmi_tlv_attach(struct ath10k *ar);
#endif
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 7a3606d..74a6c78 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6720,6 +6720,7 @@ enum wmi_tdls_state {
WMI_TDLS_DISABLE,
WMI_TDLS_ENABLE_PASSIVE,
WMI_TDLS_ENABLE_ACTIVE,
+ WMI_TDLS_ENABLE_ACTIVE_EXTERNAL_CONTROL,
};
enum wmi_tdls_peer_state {
--
1.7.9.5
^ permalink raw reply related
* [PATCH V6 4/5] ath10k: Avoid to set WEP key for TDLS peer
From: yintang @ 2017-10-16 6:00 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <1508133633-23214-1-git-send-email-yintang@qti.qualcomm.com>
From: Yingying Tang <yintang@qti.qualcomm.com>
TDLS peer do not need WEP key. Setting WEP key will lead
to TDLS setup failure. Add fix to avoid setting WEP key
for TDLS peer.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 1672043..a984a72 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2966,7 +2966,7 @@ static int ath10k_station_assoc(struct ath10k *ar,
}
/* Plumb cached keys only for static WEP */
- if (arvif->def_wep_key_idx != -1) {
+ if ((arvif->def_wep_key_idx != -1) && (!sta->tdls)) {
ret = ath10k_install_peer_wep_keys(arvif, sta->addr);
if (ret) {
ath10k_warn(ar, "failed to install peer wep keys for vdev %i: %d\n",
--
1.7.9.5
^ permalink raw reply related
* [PATCH V6 5/5] ath10k: Fix TDLS peer TX data failure issue on encryped AP
From: yintang @ 2017-10-16 6:01 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <TDLS for ath10k patches V6>
From: Yingying Tang <yintang@qti.qualcomm.com>
For WPA encryption, QCA6174 firmware(version: WLAN.RM.4.4) will unblock
data when M4 was sent successfully. For other encryption which didn't need
4-way handshake firmware will unblock the data when peer authorized. Since
TDLS is 3-way handshake host need send authorize cmd to firmware to unblock
data.
Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index a984a72..fe14d3c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5841,6 +5841,10 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
ath10k_warn(ar, "Peer %pM disappeared!\n", peer_addr);
spin_unlock_bh(&ar->data_lock);
+ if (sta && sta->tdls)
+ ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+ WMI_PEER_AUTHORIZE, 1);
+
exit:
mutex_unlock(&ar->conf_mutex);
return ret;
--
1.7.9.5
^ permalink raw reply related
* Re: Two rtlwifi drivers?
From: Oleksij Rempel @ 2017-10-16 6:46 UTC (permalink / raw)
To: Pkshih, Larry Finger, Kalle Valo, Greg Kroah-Hartman
Cc: Dan Carpenter, 莊彥宣, Johannes Berg,
Souptick Joarder, devel@driverdev.osuosl.org,
linux-wireless@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <5B2DA6FDDF928F4E855344EE0A5C39D10581FF70@RTITMBSV07.realtek.com.tw>
[-- Attachment #1.1: Type: text/plain, Size: 5689 bytes --]
Hi
Just my two cents, :)
Am 16.10.2017 um 04:41 schrieb Pkshih:
>
>
>> -----Original Message-----
>> From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
>> Sent: Thursday, October 12, 2017 6:35 PM
>> To: Kalle Valo
>> Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick Joarder;
>> devel@driverdev.osuosl.org; linux-wireless@vger.kernel.org; kernel-janitors@vger.kernel.org
>> Subject: Re: Two rtlwifi drivers?
>>
>> On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote:
>>>> So what to do? Any ideas? What makes your life easier? You can just
>>>> ignore the staging tree, as it should not affect your portion of the
>>>> kernel at all, right?
>>>
>>> Yes, I automatically ignore anything staging related. But the problem is
>>> that we now have two drivers with the same name and people don't always
>>> remember to prefix the patch with "staging: ". So on a bad day I might
>>> accidentally apply a patch which was meant for your tree. Of course I
>>> immediately revert it as soon as I, or someone else, catches that but
>>> annoying still.
>>
>> It doesn't bother me if you apply staging patches, I can handle the
>> merge issues :)
>>
>>> I think we have two options here:
>>>
>>> 1) We set a deadline (like 12 months or something) for the
>>> drivers/staging/rtlwifi and after that you refuse to take any patches
>>> for it. Hopefully this makes it clear for everyone that this fork is
>>> just temporary. I think Larry is trying to do this, which is great.
>>
>> Fine with me, if Larry is ok with it.
>>
>>> 2) We move the whole rtlwifi driver to staging. A very bad option but
>>> still better than forking the drivers.
>>
>> Ick, I don't want that to have to happen, that would not be good for the
>> users of other devices that the "real" rtlwifi driver supports.
>>
>
> Hi Larry, Kalle and Gerg,
>
> This is Realtek engineer, PK. I appreciate your support to submit, review
> and merge patch. Since I'm a Linux newbie, I'll describe the situation of
> rtlwifi and need your suggestions.
>
>
> 1) New modules in rtlwifi
> We add two modules named phydm and halmac, when adding rtl8822be in
> staging. The phydm is BB/RF related module containing the parameters
> and APIs of BB/RF, and a dynamic mechanism to adapt to different
> field environment. The halmac consists of MAC APIs.
> The two modules are used by many OSs, so '#ifdef', CamelCase and
> so on are existing in original files. Hence, we convert them to Linux
> form by script, but it's not perfect. Do you have suggestion to deal
> with this problem?
>
>
> 2) The rtlwifi in staging
> In staging, the module phydm v13 contains bugs, so I want to upgrade
> to v21 (Realtek internal version number). This upgrade contains a
> big patch that the difference between v13 and v21, and there are
> 40+ patches to support this upgrade. I have three options, and
> I want to know which one is prefer.
>
> 2.1) apply 40+ patches to both staging and wireless tree, and apply
> the big patch to staging only. After reviewing, we move the module
> to wireless tree.
>
> 2.2) apply 40+ patches to wireless tree, and apply a single bigger
> patch containing 40+ patches and the big patch to staging. I think
> this can be seen as a new driver in staging. After reviewing,
> we move the module to wireless tree.
>
> 2.3) don't apply anything to staging. Just apply 40+ patches and add
> phydm v21 to wireless.
>
>
> 3) Coming drivers -- rtl8723de and rtl8821ce
> We're developing the two drivers, and rtl8723de and rtl8821ce will
> be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
> rtl8822be that in staging now, so the line of code will be fewer.
> The new files will be a new IC folder and IC supported files of
> three modules that btcoexist, phydm and halmac. Could I submit
> them to wirless tree when they're ready?
>
>
> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I
> plan to fix them after rtl8723de and rtl8821ce. Because the drivers
> are developing, the changes will make us hard to integrate. However,
> I don't have plan to process the magic numbers in the module phydm,
> because the most of BB/RF registers contain many functions. And
> it doesn't have a register name but a bit field name instead.
> Our BB team guys say the use of enumeration or defined name will
> be unreadable, and the name is meaningless for most people.
Experience with ath9k driver showed, that development was kind of
balanced between two groups, QCA and Community (Other companies,
researches, education and so on.). Saying: "you will not understand it
any way" is nor really helpful :)
Please don't repeat bad experience of Broadcom.
> Many Linux users ask Larry about the new drivers, and Realtek will
> provide drivers and try to submit them by myself. I hope the Linux
> users can yield the drivers as soon as I can. On the way, I'll
> attend netdev workshop in Korea, so we can meet there if you attend too.
I hope to see Realtek providing patches and supporting Larry. Currently
RTL WiFi is taken by many user only if there is no other choice. So far
I would say:
1. provide testfarm and upstream patches - this will make reliable
driver and make most user happy.
2. provide documentation - this will make industrial and education
customers happy, so we will pay back with more patches.
3. make it interesting for WiFi hacker and your product will win!
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH] iw: add command to register and capture mgmt frames
From: Johannes Berg @ 2017-10-16 7:26 UTC (permalink / raw)
To: Sergey Matyukevich, Steve deRosier
Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Julian Calaby
In-Reply-To: <20171015095133.prxuuukv6osx52td@bars>
Hi,
Looks like this played out while I wasn't paying attention :-)
So first, I'll say that I have no objection in principle to the patch,
as a debugging aid.
However, the story is more complicated.
> IIUC tshark and other specific capture tools need wireless netdevice
> to be in monitor mode.
This is correct, but shouldn't be a problem.
> This particular iw command is based on
> NL80211_CMD_REGISTER_FRAME
> and related cfg80211 ops. In fact, this command can be used to
> subscribe
> to mgmt frames when wireless device is up and running in AP or STA
> mode.
> That can be convenient for monitor and debug purposes. There is a
> limitation though: currently cfg80211 core allows only one subscriber
> for each particular frame/pattern.
If you're looking for a tool to actually do something like sniffer,
this API isn't the right thing to do.
That's why I also don't think it should be added to tshark.
Remember that with the use of this API also come certain obligations.
For example, if you subscribe to (certain) action frames and then don't
actually process them as described by the spec, then the subscriber
MUST generate responses with the 0x80 bit ORed into the action code,
returning the frame as not understood. Clearly, this isn't something
that iw does and can implement.
Additionally, as you noted, and it's for this exact reason because
otherwise responsibilities wouldn't be clearly defined, there can only
be a single subscriber to a certain set of frames, as specified by the
subtype and match prefix, so using it as a type of sniffer or debug
tool may affect other functional operation.
In mac80211, it's _always_ possible to add a monitor interface, and
given no special flags (which may or may not be supported by a given
driver anyway) this monitor interface is a pure software construct and
will in no way affect device operation - apart from sending all
received frames to the monitor interface at the beginning of mac80211's
operation.
I see no reason, other than needing a little bit of coding, that this
couldn't similarly be supported in qtnfmac.
Now, there *is* one problem with this - namely that this can
significantly affect performance. The reason is that all frames need to
be sent to the monitor interface, even if they're immediately discarded
using a BPF socket filter. Sending them there means allocating a new
SKB (not necessarily copying the data, but still), as well as
generating radiotap header information for the frames. In many cases
data frames are immediately discarded so all this work is for naught.
What I had worked on a while ago to solve this problem is an eBPF
filter attached just before the "branch point" to the monitor
interface, this filter gets access to the frame (without radiotap data)
and some limited RX status data.
You can find the code for this here (may need rebasing, but I have
merged all the RX path logic changes already):
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
/log/?h=bpf
Now, there are two problems with this still (afaict):
1. It doesn't cover the TX status path, which it should, since that
also goes to the monitor interfaces. This is easily solved, I think
I just forgot about it :) (This may need an additional field in the
metadata, but that's not a problem)
2. It doesn't deal with already decapsulated RX, i.e. devices where the
802.11->ethernet decapsulation is done in the device already. This
was the reason I didn't merge this, and the problem I see with this
is that even if we do add additional metadata, it's hard to ensure
that eBPF programs won't ignore it.
johannes
^ permalink raw reply
* using verifier to ensure a BPF program uses certain metadata?
From: Johannes Berg @ 2017-10-16 7:38 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, alexei.starovoitov, linux-wireless
Hi,
As we discussed in April already (it's really been that long...), I'd
wanted to allow using BPF to filter wireless monitor frames, to enable
new use cases and higher performance in monitoring. I have some code,
at
https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git/log/?h=bpf
which implements parts of this. It's still missing the TX status path
and perhaps associated metadata, but that part is easy.
The bigger "problem" is that we're going to be adding support for
devices that have 802.11->Ethernet conversion already in hardware, and
in that case the notion that the filter program will get an 802.11
header to look at is no longer right.
Now, most likely for the actual in-service monitoring we'll actually
have to reconstitute the 802.11 header on the fly (in pure monitoring
where nothing else is active, we can just disable the conversion), but
the filtering shouldn't really be reliant on that, since that's not the
cheapest thing to do.
The obvious idea around this is to add a metadata field (just a bit
really), something like "is_data_ethernet", saying that it was both a
data frame and is already converted to have an Ethernet header.
However, since these devices don't really exist yet for the vast
majority of people, I'm a bit afraid that we'll find later a lot of
code simply ignoring this field and looking at the "802.11" header,
which is then broken if it encounters an Ethernet header instead.
Are there lies my question: If we added a new callback to
bpf_verifier_ops (e.g. "post_verifier_check"), to be called after the
normal verification, and also added a context argument to
"is_valid_access" (*), we could easily track that this new metadata
field is accessed, and reject programs that don't access it at all.
Now, I realize that people could trivially just work around this in
their program if they wanted, but I think most will take the reminder
and just implement
if (ctx->is_data_ethernet)
return DROP_FRAME;
instead, since mostly data frames will not be very relevant to them.
What do you think?
johannes
(*) the context argument could just be a void **, and is_valid_access
can allocate memory if needed - in this case I'd probably just do
something like "return *is_valid_access ?: NULL;" and return something
like "(void *)1" for when the field in question was accessed, and then
just check that in "post_verifier_check".
^ permalink raw reply
* Re: Two rtlwifi drivers?
From: Dan Carpenter @ 2017-10-16 7:45 UTC (permalink / raw)
To: Pkshih
Cc: Larry Finger, Kalle Valo, Greg Kroah-Hartman,
莊彥宣, Johannes Berg, Souptick Joarder,
devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <5B2DA6FDDF928F4E855344EE0A5C39D10581FF70@RTITMBSV07.realtek.com.tw>
On Mon, Oct 16, 2017 at 02:41:38AM +0000, Pkshih wrote:
> 2) The rtlwifi in staging
> In staging, the module phydm v13 contains bugs, so I want to upgrade
> to v21 (Realtek internal version number). This upgrade contains a
> big patch that the difference between v13 and v21, and there are
> 40+ patches to support this upgrade. I have three options, and
> I want to know which one is prefer.
We can't discuss patches we haven't seend. Please just send them right
away without any delay to both lists, and we can decide from there.
40 patches is a medium size set, patch that we are used to dealing with
every day.
regards,
dan carpenter
^ permalink raw reply
* Re: Two rtlwifi drivers?
From: Greg Kroah-Hartman @ 2017-10-16 7:50 UTC (permalink / raw)
To: Pkshih
Cc: Larry Finger, Kalle Valo, Dan Carpenter, 莊彥宣,
Johannes Berg, Souptick Joarder, devel@driverdev.osuosl.org,
linux-wireless@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <5B2DA6FDDF928F4E855344EE0A5C39D10581FF70@RTITMBSV07.realtek.com.tw>
On Mon, Oct 16, 2017 at 02:41:38AM +0000, Pkshih wrote:
>
>
> > -----Original Message-----
> > From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
> > Sent: Thursday, October 12, 2017 6:35 PM
> > To: Kalle Valo
> > Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick Joarder;
> > devel@driverdev.osuosl.org; linux-wireless@vger.kernel.org; kernel-janitors@vger.kernel.org
> > Subject: Re: Two rtlwifi drivers?
> >
> > On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote:
> > > > So what to do? Any ideas? What makes your life easier? You can just
> > > > ignore the staging tree, as it should not affect your portion of the
> > > > kernel at all, right?
> > >
> > > Yes, I automatically ignore anything staging related. But the problem is
> > > that we now have two drivers with the same name and people don't always
> > > remember to prefix the patch with "staging: ". So on a bad day I might
> > > accidentally apply a patch which was meant for your tree. Of course I
> > > immediately revert it as soon as I, or someone else, catches that but
> > > annoying still.
> >
> > It doesn't bother me if you apply staging patches, I can handle the
> > merge issues :)
> >
> > > I think we have two options here:
> > >
> > > 1) We set a deadline (like 12 months or something) for the
> > > drivers/staging/rtlwifi and after that you refuse to take any patches
> > > for it. Hopefully this makes it clear for everyone that this fork is
> > > just temporary. I think Larry is trying to do this, which is great.
> >
> > Fine with me, if Larry is ok with it.
> >
> > > 2) We move the whole rtlwifi driver to staging. A very bad option but
> > > still better than forking the drivers.
> >
> > Ick, I don't want that to have to happen, that would not be good for the
> > users of other devices that the "real" rtlwifi driver supports.
> >
>
> Hi Larry, Kalle and Gerg,
>
> This is Realtek engineer, PK. I appreciate your support to submit, review
> and merge patch. Since I'm a Linux newbie, I'll describe the situation of
> rtlwifi and need your suggestions.
>
>
> 1) New modules in rtlwifi
> We add two modules named phydm and halmac, when adding rtl8822be in
> staging. The phydm is BB/RF related module containing the parameters
> and APIs of BB/RF, and a dynamic mechanism to adapt to different
> field environment. The halmac consists of MAC APIs.
> The two modules are used by many OSs, so '#ifdef', CamelCase and
> so on are existing in original files. Hence, we convert them to Linux
> form by script, but it's not perfect. Do you have suggestion to deal
> with this problem?
Yes, use a script like you are doing, and then just work from the Linux
versions from then on. Trying to do an OS independant layer almost
never works well over time, the only people that I have seen doing it
successfully is the ACPI core code, and for that, those developers do
have lots of scripts to turn their internal version into Linux-friendly
patches.
It takes a lot more work and time to try to do this, just working
directly on Linux is easier and cheaper over time :)
> 2) The rtlwifi in staging
> In staging, the module phydm v13 contains bugs, so I want to upgrade
> to v21 (Realtek internal version number). This upgrade contains a
> big patch that the difference between v13 and v21, and there are
> 40+ patches to support this upgrade. I have three options, and
> I want to know which one is prefer.
>
> 2.1) apply 40+ patches to both staging and wireless tree, and apply
> the big patch to staging only. After reviewing, we move the module
> to wireless tree.
I don't want a "big patch" for staging.
> 2.2) apply 40+ patches to wireless tree, and apply a single bigger
> patch containing 40+ patches and the big patch to staging. I think
> this can be seen as a new driver in staging. After reviewing,
> we move the module to wireless tree.
>
> 2.3) don't apply anything to staging. Just apply 40+ patches and add
> phydm v21 to wireless.
This last option seems good to me, then move the driver that is in
staging to use the wireless core version instead?
> 3) Coming drivers -- rtl8723de and rtl8821ce
> We're developing the two drivers, and rtl8723de and rtl8821ce will
> be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on
> rtl8822be that in staging now, so the line of code will be fewer.
> The new files will be a new IC folder and IC supported files of
> three modules that btcoexist, phydm and halmac. Could I submit
> them to wirless tree when they're ready?
Sure, please submit them when they are ready, as long as they follow the
correct Linux style rules.
> 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I
> plan to fix them after rtl8723de and rtl8821ce. Because the drivers
> are developing, the changes will make us hard to integrate. However,
> I don't have plan to process the magic numbers in the module phydm,
> because the most of BB/RF registers contain many functions. And
> it doesn't have a register name but a bit field name instead.
> Our BB team guys say the use of enumeration or defined name will
> be unreadable, and the name is meaningless for most people.
Don't be so sure that names are "meaningless", there are people here
that have been doing network drivers and development for longer than
anyone else in the world. It's best to at least name values, even if
they do not seem to make sense, as that way the value can be tracked
correctly, and possibly be understood later by someone else, or even
you!
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] iw: add command to register and capture mgmt frames
From: Sergey Matyukevich @ 2017-10-16 8:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Steve deRosier, linux-wireless, Igor Mitsyanko, Avinash Patil,
Julian Calaby
In-Reply-To: <1508138777.10607.14.camel@sipsolutions.net>
Hello Johannes and all,
> So first, I'll say that I have no objection in principle to the patch,
> as a debugging aid.
>
> However, the story is more complicated.
>
> > IIUC tshark and other specific capture tools need wireless netdevice
> > to be in monitor mode.
>
> This is correct, but shouldn't be a problem.
>
> > This particular iw command is based on
> > NL80211_CMD_REGISTER_FRAME
> > and related cfg80211 ops. In fact, this command can be used to
> > subscribe
> > to mgmt frames when wireless device is up and running in AP or STA
> > mode.
> > That can be convenient for monitor and debug purposes. There is a
> > limitation though: currently cfg80211 core allows only one subscriber
> > for each particular frame/pattern.
>
> If you're looking for a tool to actually do something like sniffer,
> this API isn't the right thing to do.
>
> That's why I also don't think it should be added to tshark.
>
> Remember that with the use of this API also come certain obligations.
> For example, if you subscribe to (certain) action frames and then don't
> actually process them as described by the spec, then the subscriber
> MUST generate responses with the 0x80 bit ORed into the action code,
> returning the frame as not understood. Clearly, this isn't something
> that iw does and can implement.
>
> Additionally, as you noted, and it's for this exact reason because
> otherwise responsibilities wouldn't be clearly defined, there can only
> be a single subscriber to a certain set of frames, as specified by the
> subtype and match prefix, so using it as a type of sniffer or debug
> tool may affect other functional operation.
>
>
> In mac80211, it's _always_ possible to add a monitor interface, and
> given no special flags (which may or may not be supported by a given
> driver anyway) this monitor interface is a pure software construct and
> will in no way affect device operation - apart from sending all
> received frames to the monitor interface at the beginning of mac80211's
> operation.
>
> I see no reason, other than needing a little bit of coding, that this
> couldn't similarly be supported in qtnfmac.
Well, monitor mode support in qtnfmac is in our todo list for sure. Meanwhile
the purpose of the patch was not to implement a full-fledged mgmt packet
capture. We have monitor mode and mature capture tools for that.
Nevertheless in certain cases it is handy to dump selected types of mgmt frames
while system is up and running without adding the whole monitor overhead. The
idea was that NL80211_CMD_REGISTER_FRAME and iw are the right tools for that
task. Anyway, iw is something like a 'swiss-army-knife' tool for various tasks
related to mac80211/cfg80211 reporting and troubleshooting.
Speaking of the patch, you mentioned that you have no objection in principle.
Let me know if you have any objections to implementation details :)
Then I will resubmit it addressing all the comments. Besides I am going
to change command name from 'capture' to 'dump' to avoid confusion.
Finally, I will update commit message adding information about unicast
nature of those registrations.
Regards,
Sergey
^ permalink raw reply
* [PATCH] mac80211: accept key reinstall without changing anything
From: Johannes Berg @ 2017-10-16 9:17 UTC (permalink / raw)
To: linux-wireless; +Cc: j, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".
In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.
In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN counter intact.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/key.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index a98fc2b5e0dc..ae995c8480db 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -4,7 +4,7 @@
* Copyright 2006-2007 Jiri Benc <jbenc@suse.cz>
* Copyright 2007-2008 Johannes Berg <johannes@sipsolutions.net>
* Copyright 2013-2014 Intel Mobile Communications GmbH
- * Copyright 2015 Intel Deutschland GmbH
+ * Copyright 2015-2017 Intel Deutschland GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -620,9 +620,6 @@ int ieee80211_key_link(struct ieee80211_key *key,
pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
idx = key->conf.keyidx;
- key->local = sdata->local;
- key->sdata = sdata;
- key->sta = sta;
mutex_lock(&sdata->local->key_mtx);
@@ -633,6 +630,21 @@ int ieee80211_key_link(struct ieee80211_key *key,
else
old_key = key_mtx_dereference(sdata->local, sdata->keys[idx]);
+ /*
+ * Silently accept key re-installation without really installing the
+ * new version of the key to avoid nonce reuse or replay issues.
+ */
+ if (old_key && key->conf.keylen == old_key->conf.keylen &&
+ !memcmp(key->conf.key, old_key->conf.key, key->conf.keylen)) {
+ ieee80211_key_free_unused(key);
+ ret = 0;
+ goto out;
+ }
+
+ key->local = sdata->local;
+ key->sdata = sdata;
+ key->sta = sta;
+
increment_tailroom_need_count(sdata);
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
@@ -648,6 +660,7 @@ int ieee80211_key_link(struct ieee80211_key *key,
ret = 0;
}
+ out:
mutex_unlock(&sdata->local->key_mtx);
return ret;
--
2.14.2
^ permalink raw reply related
* rc2-next-20170929: wireless down, won't come up
From: Pavel Machek @ 2017-10-16 9:18 UTC (permalink / raw)
To: sgruszka, linux-wireless, kernel list, johannes.berg,
emmanuel.grumbach, luciano.coelho, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Hi!
In -next... after few days of usage with suspend and resume cycles,
wifi failed on thinkpad x60. I have not seen this in years...
[28140.944044] CE: hpet increased min_delta_ns to 20115 nsec
[28174.048418] iwl3945 0000:03:00.0: Error sending C_RATE_SCALE: time
out after 500ms.
[28174.048430] iwl3945 0000:03:00.0: Error setting HW rate table:
FFFFFF92
[28174.186576] iwl3945 0000:03:00.0: Error: Response NULL in
'C_ADD_STA'
[28174.186593] iwl3945 0000:03:00.0: Adding station 00:00:00:00:00:01
failed.
[28174.206312] iwl3945 0000:03:00.0: Error: Response NULL in
'C_ADD_STA'
[28174.206326] iwl3945 0000:03:00.0: Adding station ff:ff:ff:ff:ff:ff
failed.
[30306.599241] wlan0: deauthenticating from 00:00:00:00:00:01 by local
choice (Reason: 3=DEAUTH_LEAVING)
[30306.624302] iwl3945 0000:03:00.0: Error removing station
00:00:00:00:00:01
[30309.055257] wlan0: authenticate with 00:00:00:00:00:01
[30309.055631] wlan0: send auth to 00:00:00:00:00:01 (try 1/3)
[30309.256142] wlan0: send auth to 00:00:00:00:00:01 (try 2/3)
[30309.460114] wlan0: send auth to 00:00:00:00:00:01 (try 3/3)
[30309.664117] wlan0: authentication with 00:00:00:00:00:01 timed out
(Yes, my AP has funny hw address; but its other hw address fails, too).
Any ideas?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] iw: add command to register and capture mgmt frames
From: Johannes Berg @ 2017-10-16 9:24 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: Steve deRosier, linux-wireless, Igor Mitsyanko, Avinash Patil,
Julian Calaby
In-Reply-To: <20171016084810.plzog2dtzakra4ae@bars>
On Mon, 2017-10-16 at 11:48 +0300, Sergey Matyukevich wrote:
>
> Well, monitor mode support in qtnfmac is in our todo list for sure.
Sure. I'm saying you don't really need full monitor support at all,
just a pure software construct for this.
> Meanwhile the purpose of the patch was not to implement a full-
> fledged mgmt packet capture. We have monitor mode and mature capture
> tools for that.
Right, and I didn't originally see the patch as such, just that the
discussion (and in particular Julian's suggestion) veered off in that
direction.
> Nevertheless in certain cases it is handy to dump selected types of
> mgmt frames while system is up and running without adding the whole
> monitor overhead. The idea was that NL80211_CMD_REGISTER_FRAME and iw
> are the right tools for that task. Anyway, iw is something like a
> 'swiss-army-knife' tool for various tasks related to
> mac80211/cfg80211 reporting and troubleshooting.
I'd see this particular feature in iw more as a way to debug the
registrations, but whatever you ultimately want to use it for I neither
can nor want to control :-)
> Let me know if you have any objections to implementation details :)
Yeah, I'll need to review it, just need a bit more time for that.
> Then I will resubmit it addressing all the comments. Besides I am
> going to change command name from 'capture' to 'dump' to avoid
> confusion. Finally, I will update commit message adding information
> about unicast nature of those registrations.
Sounds good :)
Do you want to resend before I review it?
johannes
^ permalink raw reply
* Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index
From: Stanislaw Gruszka @ 2017-10-16 9:40 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Andrey Konovalov, Helmut Schaa, Kalle Valo, linux-wireless,
netdev, LKML, Kostya Serebryany, syzkaller
In-Reply-To: <CACT4Y+YLM-u7bMfRB=eu_pz1M9iDrY-Qmnho7Hw_Lh3M=LSeMQ@mail.gmail.com>
Hi Dmitry
On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > Hi
> >
> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
> >> I've got the following report while fuzzing the kernel with syzkaller.
> >>
> >> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
> >>
> >> I'm not sure whether this is a bug in the driver, or just a way to
> >> report misbehaving device. In the latter case this shouldn't be a
> >> WARN() call, since WARN() means bug in the kernel.
> >
> > This is about wrong EEPROM, which reported 3 tx streams on
> > non 3 antenna device. I think WARN() is justified and thanks
> > to the call trace I was actually able to to understand what
> > happened.
> >
> > In general I do not think WARN() only means a kernel bug, it
> > can be F/W or H/W bug too.
>
> Hi Stanislaw,
>
> Printing messages is fine. Printing stacks is fine. Just please make
> them distinguishable from kernel bugs and don't kill the whole
> possibility of automated Linux kernel testing. That's an important
> capability.
We do not distinguish between bugs and other problems when WARN() is
used in (wireless) drivers, what I think is correct, taking comment from
include/asm-generic/bug.h :
/*
* WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
* significant issues that need prompt attention if they should ever
* appear at runtime. Use the versions with printk format strings
* to provide better diagnostics.
*/
Historically we have BUG() to mark the bugs, but usage if it is not
recommended as it can kill the system, so for anything that can
be recovered in runtime - WARN() is recommended.
Perhaps we can introduce another helper like PROBLEM() for marking
situations when something is wrong, but it is not a bug. However I'm
not even sure at what extent it can be used, since for many cases
if not the most, driver author can not tell apriori if the problem
is a bug in the driver or HW/FW misbehaviour (or maybe particular
issue can happen because of both).
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH] iw: add command to register and capture mgmt frames
From: Sergey Matyukevich @ 2017-10-16 9:43 UTC (permalink / raw)
To: Johannes Berg
Cc: Steve deRosier, linux-wireless, Igor Mitsyanko, Avinash Patil,
Julian Calaby
In-Reply-To: <1508145899.10607.30.camel@sipsolutions.net>
> > Let me know if you have any objections to implementation details :)
>
> Yeah, I'll need to review it, just need a bit more time for that.
>
> > Then I will resubmit it addressing all the comments. Besides I am
> > going to change command name from 'capture' to 'dump' to avoid
> > confusion. Finally, I will update commit message adding information
> > about unicast nature of those registrations.
>
> Sounds good :)
>
> Do you want to resend before I review it?
No, I will wait for code reviews, then I will resend the updated
patch including changes for all the upcoming comments.
Regards,
Sergey
^ permalink raw reply
* Re: rc2-next-20170929: wireless down, won't come up
From: Pavel Machek @ 2017-10-16 10:27 UTC (permalink / raw)
To: sgruszka, linux-wireless, kernel list, johannes.berg,
emmanuel.grumbach, luciano.coelho, linuxwifi
In-Reply-To: <20171016091830.GA21812@amd>
[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]
Hi!
> In -next... after few days of usage with suspend and resume cycles,
> wifi failed on thinkpad x60. I have not seen this in years...
>
> [28140.944044] CE: hpet increased min_delta_ns to 20115 nsec
> [28174.048418] iwl3945 0000:03:00.0: Error sending C_RATE_SCALE: time
> out after 500ms.
> [28174.048430] iwl3945 0000:03:00.0: Error setting HW rate table:
> FFFFFF92
> [28174.186576] iwl3945 0000:03:00.0: Error: Response NULL in
> 'C_ADD_STA'
> [28174.186593] iwl3945 0000:03:00.0: Adding station 00:00:00:00:00:01
> failed.
> [28174.206312] iwl3945 0000:03:00.0: Error: Response NULL in
> 'C_ADD_STA'
> [28174.206326] iwl3945 0000:03:00.0: Adding station ff:ff:ff:ff:ff:ff
> failed.
> [30306.599241] wlan0: deauthenticating from 00:00:00:00:00:01 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [30306.624302] iwl3945 0000:03:00.0: Error removing station
> 00:00:00:00:00:01
> [30309.055257] wlan0: authenticate with 00:00:00:00:00:01
> [30309.055631] wlan0: send auth to 00:00:00:00:00:01 (try 1/3)
> [30309.256142] wlan0: send auth to 00:00:00:00:00:01 (try 2/3)
> [30309.460114] wlan0: send auth to 00:00:00:00:00:01 (try 3/3)
> [30309.664117] wlan0: authentication with 00:00:00:00:00:01 timed out
>
> (Yes, my AP has funny hw address; but its other hw address fails, too).
>
> Any ideas?
Suspend+resume fixed the problem.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ 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