Re: Cpu stall caused by hostapd running two interfaces
On Mon, Aug 13, 2018 at 08:48:17PM +0200, Grzegorz Duszyński wrote: > Can I help you somehow with this ? Enable CONFIG_DEBUG_INFO=y in .config if not done already. Then do: make net/mac80211/util.o gdb net/mac80211/util.o l *(ieee80211_regulatory_limit_wmm_params+0x6e) and provide output of gdb l command, this should show code line number where oops occurs. Thanks Stanislaw
[RFC 2/3] mac80211: pause txq transmission on negative airtime deficit
Airtime fairness prioritizes txqs and picks high priority txq. Once a txq is selected for transmission by next_txq(), dequeue routine is not preventing over downloading packets. i.e the driver is still allowed to dequeue frames from txq even when its fairness deficit goes negative. This is also causing inefficient fq-codel of mac80211 when the driver/firmware is maintaining another set of data queues. To address this problem, pause txq transmission when given txq's was already served for the assigned quantum and resume the transmission upon prioritization. Signed-off-by: Rajkumar Manoharan --- net/mac80211/debugfs_sta.c | 7 --- net/mac80211/ieee80211_i.h | 1 + net/mac80211/sta_info.c| 9 + net/mac80211/tx.c | 9 - 4 files changed, 22 insertions(+), 4 deletions(-) diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c index bae0fa7ff95a..5c38994cd95c 100644 --- a/net/mac80211/debugfs_sta.c +++ b/net/mac80211/debugfs_sta.c @@ -178,9 +178,10 @@ static ssize_t sta_aqm_read(struct file *file, char __user *userbuf, txqi->tin.tx_bytes, txqi->tin.tx_packets, txqi->flags, - txqi->flags & (1flags & (1 << IEEE80211_TXQ_PAUSE) ? "PAUSE": "RUN", + txqi->flags & (1 << IEEE80211_TXQ_AMPDU) ? " AMPDU" : "", + txqi->flags & (1 << IEEE80211_TXQ_NO_AMSDU) ? " NO-AMSDU" : ""); } rcu_read_unlock(); diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index 5825824cfe5b..3ef287075cb1 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -818,6 +818,7 @@ enum txq_info_flags { IEEE80211_TXQ_STOP, IEEE80211_TXQ_AMPDU, IEEE80211_TXQ_NO_AMSDU, + IEEE80211_TXQ_PAUSE, }; /** diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c index 8af9e5c05ce4..215ae3a690aa 100644 --- a/net/mac80211/sta_info.c +++ b/net/mac80211/sta_info.c @@ -1830,6 +1830,8 @@ void ieee80211_sta_register_airtime(struct ieee80211_sta *pubsta, u8 tid, { struct sta_info *sta = container_of(pubsta, struct sta_info, sta); struct ieee80211_local *local = sta->sdata->local; + struct fq *fq = >fq; + struct txq_info *txqi; u8 ac = ieee80211_ac_from_tid(tid); u32 airtime = 0; @@ -1844,6 +1846,13 @@ void ieee80211_sta_register_airtime(struct ieee80211_sta *pubsta, u8 tid, sta->airtime.deficit[ac] -= airtime; if (airtime) sta->local->airtime_flags |= AIRTIME_ACTIVE; + + if (sta->airtime.deficit[ac] < 0) { + txqi = to_txq_info(pubsta->txq[tid]); + spin_lock_bh(>lock); + set_bit(IEEE80211_TXQ_PAUSE, >flags); + spin_unlock_bh(>lock); + } spin_unlock_bh(>active_txq_lock); } EXPORT_SYMBOL(ieee80211_sta_register_airtime); diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 6a76852ba1f3..0af35c08e0d9 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -3475,7 +3475,8 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, spin_lock_bh(>lock); - if (test_bit(IEEE80211_TXQ_STOP, >flags)) + if (test_bit(IEEE80211_TXQ_STOP, >flags) || + test_bit(IEEE80211_TXQ_PAUSE, >flags)) goto out; /* Make sure fragments stay together. */ @@ -3636,6 +3637,7 @@ static inline struct txq_info *find_txqi(struct ieee80211_local *local, s8 ac) struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, s8 ac) { struct ieee80211_local *local = hw_to_local(hw); + struct fq *fq = >fq; struct txq_info *txqi = NULL; spin_lock_bh(>active_txq_lock); @@ -3653,6 +3655,11 @@ struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, s8 ac) sta->airtime.deficit[txqi->txq.ac] += IEEE80211_AIRTIME_QUANTUM * sta->airtime.weight; list_move_tail(>schedule_order, >active_txqs[txqi->txq.ac]); + if (sta->airtime.deficit[txqi->txq.ac] > 0) { + spin_lock_bh(>lock); + clear_bit(IEEE80211_TXQ_PAUSE, >flags); + spin_unlock_bh(>lock); + } goto begin; } } -- 1.9.1
[RFC 1/3] mac80211: make airtime txq list per ac
txqs of all access categories are maintained in single list
and in uneven order. To fetch a specific AC's txq from the list,
lookup might have to traverse the entire list in worst case.
To speedup txq lookup, txq list are maintained per each AC.
Signed-off-by: Rajkumar Manoharan
---
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/main.c| 3 ++-
net/mac80211/tx.c | 33 +++--
3 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index bd7f074ccf16..5825824cfe5b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1129,7 +1129,7 @@ struct ieee80211_local {
/* protects active_txqs and txqi->schedule_order */
spinlock_t active_txq_lock;
- struct list_head active_txqs;
+ struct list_head active_txqs[IEEE80211_NUM_ACS];
u16 airtime_flags;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index fbb0bd6183d2..771366464f18 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -634,7 +634,8 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t
priv_data_len,
spin_lock_init(>rx_path_lock);
spin_lock_init(>queue_stop_reason_lock);
- INIT_LIST_HEAD(>active_txqs);
+ for (i = 0; i < IEEE80211_NUM_ACS; i++)
+ INIT_LIST_HEAD(>active_txqs[i]);
spin_lock_init(>active_txq_lock);
local->airtime_flags = AIRTIME_USE_TX | AIRTIME_USE_RX;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 8acab75a0700..6a76852ba1f3 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3597,9 +3597,11 @@ bool ieee80211_schedule_txq(struct ieee80211_hw *hw,
* call to ieee80211_next_txq().
*/
if ((local->airtime_flags & AIRTIME_ACTIVE) && txqi->txq.sta)
- list_add(>schedule_order, >active_txqs);
+ list_add(>schedule_order,
+>active_txqs[txq->ac]);
else
- list_add_tail(>schedule_order,
>active_txqs);
+ list_add_tail(>schedule_order,
+ >active_txqs[txq->ac]);
ret = true;
}
@@ -3609,15 +3611,26 @@ bool ieee80211_schedule_txq(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_schedule_txq);
-static inline struct txq_info *find_txqi(struct list_head *head, s8 ac)
+static inline struct txq_info *find_txqi(struct ieee80211_local *local, s8 ac)
{
- struct txq_info *txqi;
+ struct txq_info *txqi = NULL;
+ int i;
- list_for_each_entry(txqi, head, schedule_order) {
- if (ac < 0 || txqi->txq.ac == ac)
- return txqi;
+ if (ac >= 0 && ac < IEEE80211_NUM_ACS) {
+ txqi = list_first_entry_or_null(>active_txqs[ac],
+ struct txq_info,
+ schedule_order);
+ } else {
+ for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+ if (list_empty(>active_txqs[i]))
+ continue;
+ txqi = list_first_entry(>active_txqs[i],
+ struct txq_info,
+ schedule_order);
+ }
}
- return NULL;
+
+ return txqi;
}
struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, s8 ac)
@@ -3628,7 +3641,7 @@ struct ieee80211_txq *ieee80211_next_txq(struct
ieee80211_hw *hw, s8 ac)
spin_lock_bh(>active_txq_lock);
begin:
- txqi = find_txqi(>active_txqs, ac);
+ txqi = find_txqi(local, ac);
if (!txqi)
goto out;
@@ -3639,7 +3652,7 @@ struct ieee80211_txq *ieee80211_next_txq(struct
ieee80211_hw *hw, s8 ac)
if (sta->airtime.deficit[txqi->txq.ac] < 0) {
sta->airtime.deficit[txqi->txq.ac] +=
IEEE80211_AIRTIME_QUANTUM * sta->airtime.weight;
list_move_tail(>schedule_order,
- >active_txqs);
+ >active_txqs[txqi->txq.ac]);
goto begin;
}
}
--
1.9.1
[RFC 3/3] mac80211: add ieee80211_reorder_txq
This allows the driver to refill airtime fairness deficit
where the driver will not access txqs by ieee80211_next_txq.
In tx push mode data path, high priority txqs will be scheduled
for data transmission by ieee80211_next_txq and driver will not
prioritize txqs whereas in push-pull mode, the drivers can
prioritize txqs and access them directly. In such mode, airtime
deficit can not filled by ieee80211_next_txq.
Signed-off-by: Rajkumar Manoharan
---
include/net/mac80211.h | 15 +
net/mac80211/tx.c | 59 +++---
2 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cc16847bd52d..a2f0b6800100 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -6033,6 +6033,21 @@ bool ieee80211_schedule_txq(struct ieee80211_hw *hw,
struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, s8 ac);
/**
+ * ieee80211_reorder_txq - change txq position in scheduling loop
+ *
+ * This function is used to reorder txq's position in scheduling loop.
+ * The txq fairness deficit will be refilled. The drivers calling this
+ * function should ensure the txq won't be accessed by ieee80211_next_txq
+ * in the same path.
+ *
+ * @hw: pointer as obtained from ieee80211_alloc_hw()
+ * @txq: pointer obtained from station or virtual interface
+ *
+ */
+void ieee80211_reorder_txq(struct ieee80211_hw *hw,
+ struct ieee80211_txq *txq);
+
+/**
* ieee80211_txq_get_depth - get pending frame/byte count of given txq
*
* The values are not guaranteed to be coherent with regard to each other, i.e.
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 0af35c08e0d9..b7b2f93152f8 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3634,10 +3634,38 @@ static inline struct txq_info *find_txqi(struct
ieee80211_local *local, s8 ac)
return txqi;
}
+static bool ieee80211_txq_refill_deficit(struct ieee80211_local *local,
+struct txq_info *txqi)
+{
+ struct fq *fq = >fq;
+ struct sta_info *sta;
+
+ lockdep_assert_held(>active_txq_lock);
+
+ if (!txqi->txq.sta)
+ return false;
+
+ sta = container_of(txqi->txq.sta, struct sta_info, sta);
+
+ if (sta->airtime.deficit[txqi->txq.ac] > 0)
+ return false;
+
+ sta->airtime.deficit[txqi->txq.ac] +=
+ IEEE80211_AIRTIME_QUANTUM * sta->airtime.weight;
+ list_move_tail(>schedule_order,
+ >active_txqs[txqi->txq.ac]);
+
+ if (sta->airtime.deficit[txqi->txq.ac] > 0) {
+ spin_lock_bh(>lock);
+ clear_bit(IEEE80211_TXQ_PAUSE, >flags);
+ spin_unlock_bh(>lock);
+ }
+ return true;
+}
+
struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, s8 ac)
{
struct ieee80211_local *local = hw_to_local(hw);
- struct fq *fq = >fq;
struct txq_info *txqi = NULL;
spin_lock_bh(>active_txq_lock);
@@ -3647,22 +3675,8 @@ struct ieee80211_txq *ieee80211_next_txq(struct
ieee80211_hw *hw, s8 ac)
if (!txqi)
goto out;
- if (txqi->txq.sta) {
- struct sta_info *sta = container_of(txqi->txq.sta,
- struct sta_info, sta);
-
- if (sta->airtime.deficit[txqi->txq.ac] < 0) {
- sta->airtime.deficit[txqi->txq.ac] +=
IEEE80211_AIRTIME_QUANTUM * sta->airtime.weight;
- list_move_tail(>schedule_order,
- >active_txqs[txqi->txq.ac]);
- if (sta->airtime.deficit[txqi->txq.ac] > 0) {
- spin_lock_bh(>lock);
- clear_bit(IEEE80211_TXQ_PAUSE, >flags);
- spin_unlock_bh(>lock);
- }
- goto begin;
- }
- }
+ if (ieee80211_txq_refill_deficit(local, txqi))
+ goto begin;
list_del_init(>schedule_order);
@@ -3676,6 +3690,17 @@ struct ieee80211_txq *ieee80211_next_txq(struct
ieee80211_hw *hw, s8 ac)
}
EXPORT_SYMBOL(ieee80211_next_txq);
+void ieee80211_reorder_txq(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
+{
+ struct ieee80211_local *local = hw_to_local(hw);
+ struct txq_info *txqi = to_txq_info(txq);
+
+ spin_lock_bh(>active_txq_lock);
+ ieee80211_txq_refill_deficit(local, txqi);
+ spin_unlock_bh(>active_txq_lock);
+}
+EXPORT_SYMBOL(ieee80211_reorder_txq);
+
void __ieee80211_subif_start_xmit(struct sk_buff *skb,
struct net_device *dev,
u32 info_flags)
--
1.9.1
[RFC 0/3] mac80211: handle push-pull path in ATF
Toke, Here are my pending changes on top of your 1st version of ATF. I am posting these RFCs for more feedback. I havn't posted ath10k changes and planned to do it later. Kindly review. -Rajkumar Rajkumar Manoharan (3): mac80211: make airtime txq list per ac mac80211: pause txq transmission on negative airtime deficit mac80211: add ieee80211_reorder_txq include/net/mac80211.h | 15 net/mac80211/debugfs_sta.c | 7 ++-- net/mac80211/ieee80211_i.h | 3 +- net/mac80211/main.c| 3 +- net/mac80211/sta_info.c| 9 + net/mac80211/tx.c | 87 +++--- 6 files changed, 98 insertions(+), 26 deletions(-) -- 1.9.1
Re: Promiscuous (not monitor) Mode support for ath10k
On Mon, Aug 06, 2018 at 06:08:46PM -0400, Tomasz Kalbarczyk wrote: > Hello, Hi! > I have a QCA6174 and I'm running tcpdump on the wireless interface to > listen for packets. I can receive packets addressed directly to the > device, but not any other packets on the network. > > Does anyone know the status of promiscuous mode support on ath10k? > Note that this is different from monitor mode / supported on a larger > subset of hardware. Dmesg merely indicates that the device has > "entered promiscuous mode" when tcpdump is initiated. > > Here is a link to similar discussion regarding the ath9k a few years > back: https://marc.info/?l=linux-wireless=135936563626791=2 This might be relevant: commit df1404650ccbfeb76a84f301f22316be0d00a864 Author: Johannes Berg Date: Wed Apr 22 14:40:58 2015 +0200 mac80211: remove support for IFF_PROMISC This support is essentially useless as typically networks are encrypted, frames will be filtered by hardware, and rate scaling will be done with the intended recipient in mind. For real monitoring of the network, the monitor mode support should be used instead. Removing it removes a lot of corner cases. Regards, Brian
Re: Cpu stall caused by hostapd running two interfaces
Can I help you somehow with this ? Is this the reason for cpu stall ? Should the issue exist while using single nic? 2018-08-13 14:03 GMT+02:00 Kalle Valo : > Stanislaw Gruszka writes: > >> (cc Haim and Johannes) >> >> On Sun, Aug 12, 2018 at 09:54:00PM +0200, Grzegorz Duszyński wrote: >>> Hello, >>> >>> I'm running into problems while trying to start AP's on 2 interfaces. >>> Devices are: >>> - Compex WLE900VX (QCA9880) >>> - Killer 1535 (QCA6174) >>> >>> The 1535 is a new addition to the system. >>> Compex by itself runs fine, Killer also can run alone. >>> >>> But when running them together all hell breaks lose. >>> System is unusable, cannot even reboot. >>> >>> I'm running Arch Linux. >>> My system was updated before testing & posting. >>> >>> Attachments: >>> dmesg - https://pastebin.com/wf3Fq8gh >>> >>> Please let me know if additional info is required. >> >> This is oops in ieee80211_regulatory_limit_wmm_params(). >> Looks like new regulatory code do not like ath10k. >> I have another bug report with reg.c WARNING also on ath10k: >> https://bugzilla.redhat.com/show_bug.cgi?id=1612537 > > I think bug #1612537 is with ath9k, not ath10k. But anyway, both use > ath.ko which has some custom regulatory code. > > -- > Kalle Valo
Re: [PATCH] mac80211: Run TXQ teardown code before de-registering interfaces
Arend van Spriel writes: > On 8/13/2018 2:16 PM, Toke Høiland-Jørgensen wrote: >> The TXQ teardown code can reference the vif data structures that are >> stored in the netdev private memory area if there are still packets on >> the queue when it is being freed. Since the TXQ teardown code is run >> after the netdevs are freed, this can lead to a use-after-free. Fix this >> by moving the TXQ teardown code to earlier in ieee80211_unregister_hw(). > > Just off the bat, but from reading the above I am wondering whether > the use-after-free could also happen upon removing an interface? Hmm, there doesn't appear to be *any* teardown of TXQs when an interface is removed...? So I guess that if an interface is removed while it still has frames on the multicast TXQ, that those packets would be left hanging there? I don't think there would be an explicit use-after-free, because they will never get dequeued, so they would just constitute a memory leak? Am I missing some automatic mechanism that always empties out queues before an interface is brought down? -Toke
Re: [PATCH] mac80211: Run TXQ teardown code before de-registering interfaces
On 08/13/2018 11:25 AM, Arend van Spriel wrote: On 8/13/2018 2:16 PM, Toke Høiland-Jørgensen wrote: The TXQ teardown code can reference the vif data structures that are stored in the netdev private memory area if there are still packets on the queue when it is being freed. Since the TXQ teardown code is run after the netdevs are freed, this can lead to a use-after-free. Fix this by moving the TXQ teardown code to earlier in ieee80211_unregister_hw(). Just off the bat, but from reading the above I am wondering whether the use-after-free could also happen upon removing an interface? At least in practice, it does not seem to happen. Some of our test cases bring up and down netdevs very often, and those doe not seem to trigger this bug. But, could be luck, of course. Crashing ath10k firmware under tx load, and unloading modules under tx load seems to be the main trigger. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH] mac80211: Run TXQ teardown code before de-registering interfaces
On 8/13/2018 2:16 PM, Toke Høiland-Jørgensen wrote: The TXQ teardown code can reference the vif data structures that are stored in the netdev private memory area if there are still packets on the queue when it is being freed. Since the TXQ teardown code is run after the netdevs are freed, this can lead to a use-after-free. Fix this by moving the TXQ teardown code to earlier in ieee80211_unregister_hw(). Just off the bat, but from reading the above I am wondering whether the use-after-free could also happen upon removing an interface? Regards, Arend Reported-by: Ben Greear Tested-by: Ben Greear Signed-off-by: Toke Høiland-Jørgensen --- net/mac80211/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH v2] wireless-regdb: update rules for Hungary (HU) on 2.4/5/60G, 5725-5875MHz
On Mon, Aug 13, 2018 at 07:40:19AM -0500, Seth Forshee wrote: > On Sat, Jun 30, 2018 at 10:40:34PM +0200, bkil wrote: > > * 2400-2483.5M: extend bounds > > * 5150-5250M: extend bounds, add NO-OUTDOOR, no TPC so +3dB > > * 5250-5350M: extend bounds, add NO-OUTDOOR > > * 5470-5725M: extend bounds > > * 5725-5875M: introduce, as EU SRD provisions have been implemented > > * 57-66G: add NO-OUTDOOR > > > > Freely available online references have been added hosted by the regulatory > > body in Hungary, the National Media and Infocommunications Authority. > > > > To refer to a specific section, you can grep for the frequency in question. > > > > Translation key: > > "Csak beltéri" / "Épületen belüli használatra korlátozott" = indoor only; > > "Kültéri és beltéri" = both indoor and outdoor; > > "Nem működő TPC esetén a maximális teljesítményjellemzők 3 dB-lel > > csökkennek." = reduce max power specs by 3dB in case of no TPC; > > "Rögzített kültéri telepítés nem megengedett" = no fixed outdoor install > > > > Signed-off-by: bkil > > Applied, thanks! Replied to the wrong message in the thread, to be clear what I applied was the v3 patch.
[PATCH 2/3] nl80211: Add support for EDMG channels
802.11ay specification defines Enhanced Directional Multi-Gigabit
(EDMG) STA and SAP which allow channel bonding of 2 channels and more.
Introduce NL80211_BAND_ATTR_EDMG, NL80211_BAND_ATTR_EDMG_SUPPORTED_CHAN,
NL80211_ATTR_WIPHY_EDMG, NL80211_ATTR_WIPHY_EDMG_CHANNEL and
RATE_INFO_FLAGS_EDMG that needed for enabling and configuring
EDMG support.
Driver is expected to report its EDMG capabilities: whether EDMG
is supported and the supported EDMG channels.
Bitrate calculation is enhanced to take into account EDMG support
according to the 802.11ay specification.
The kernel uses NL80211_BAND_ATTR_EDMG and
NL80211_BAND_ATTR_EDMG_SUPPORTED_CHAN attributes in order to publish
the EDMG capabilities to the userspace, NL80211_BAND_ATTR_EDMG is set
if EDMG is supported and NL80211_BAND_ATTR_EDMG_SUPPORTED_CHAN
contains list of supported EDMG channels.
NL80211_ATTR_WIPHY_EDMG and NL80211_ATTR_WIPHY_EDMG_CHANNEL will be
used by the userspace for AP configuration and connect command.
Signed-off-by: Alexei Avshalom Lazar
---
drivers/net/wireless/ath/wil6210/cfg80211.c | 2 +-
include/net/cfg80211.h | 48 +++-
include/uapi/linux/nl80211.h| 12
net/wireless/chan.c | 88 +
net/wireless/nl80211.c | 33 +++
net/wireless/util.c | 42 +-
6 files changed, 219 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index e63b078..4740b53 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -311,7 +311,7 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
BIT_ULL(NL80211_STA_INFO_RX_DROP_MISC) |
BIT_ULL(NL80211_STA_INFO_TX_FAILED);
- sinfo->txrate.flags = RATE_INFO_FLAGS_60G;
+ sinfo->txrate.flags = RATE_INFO_FLAGS_DMG;
sinfo->txrate.mcs = le16_to_cpu(reply.evt.bf_mcs);
sinfo->rxrate.mcs = stats->last_mcs_rx;
sinfo->rx_bytes = stats->rx_bytes;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 73ca446..10f9d76 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -321,6 +321,24 @@ struct ieee80211_sband_iftype_data {
};
/**
+ * struct ieee80211_sta_edmg_cap - EDMG capabilities
+ *
+ * This structure describes most essential parameters needed
+ * to describe 802.11ay EDMG capabilities
+ *
+ * @supported: is EDMG supported, Device may support EDMG
+ * without supporting channel bonding. In this case
+ * supported would be TRUE with n_channels = 0
+ * @channels: supported ieee EDMG channel numbers
+ * @n_channels: Number of channels in @channels
+ */
+struct ieee80211_sta_edmg_cap {
+ bool supported;
+ u8 *channels;
+ int n_channels;
+};
+
+/**
* struct ieee80211_supported_band - frequency band definition
*
* This structure describes a frequency band a wiphy
@@ -336,6 +354,7 @@ struct ieee80211_sband_iftype_data {
* @n_bitrates: Number of bitrates in @bitrates
* @ht_cap: HT capabilities in this band
* @vht_cap: VHT capabilities in this band
+ * @edmg_cap: EDMG capabilities in this band
* @n_iftype_data: number of iftype data entries
* @iftype_data: interface type data entries. Note that the bits in
* @types_mask inside this structure cannot overlap (i.e. only
@@ -350,6 +369,7 @@ struct ieee80211_supported_band {
int n_bitrates;
struct ieee80211_sta_ht_cap ht_cap;
struct ieee80211_sta_vht_cap vht_cap;
+ struct ieee80211_sta_edmg_cap edmg_cap;
u16 n_iftype_data;
const struct ieee80211_sband_iftype_data *iftype_data;
};
@@ -501,12 +521,16 @@ struct key_params {
* @center_freq1: center frequency of first segment
* @center_freq2: center frequency of second segment
* (only with 80+80 MHz)
+ * @edmg_mode: if defined, edmg supported and primary channel is EDMG
+ * @edmg_channel: the EDMG channel
*/
struct cfg80211_chan_def {
struct ieee80211_channel *chan;
enum nl80211_chan_width width;
u32 center_freq1;
u32 center_freq2;
+ bool edmg_mode;
+ u8 edmg_channel;
};
/**
@@ -658,6 +682,18 @@ int cfg80211_chandef_dfs_required(struct wiphy *wiphy,
}
/**
+ * cfg80211_edmg_usable - check if the EDMG channel can be used
+ * @wiphy: the wiphy
+ * @edmg_cap: EDMG capabilities in this band
+ * @edmg_channel: the EDMG channel that need to be verified
+ * @primary_channel: The primary channel for the EDMG channel
+ * Return: %true the EDMG channel is usable. %false otherwise.
+ */
+bool cfg80211_edmg_usable(struct wiphy *wiphy,
+ struct ieee80211_sta_edmg_cap *edmg_cap,
+ u8 edmg_channel, int primary_channel);
+
+/**
* enum survey_info_flags - survey information flags
*
* @SURVEY_INFO_NOISE_DBM: noise (in dBm) was
[PATCH 0/3] Add support for new channels on 60GHz band
The following set of patches add support for new channels on 60GHz band and EDMG channels: -Support new channels 5 and 6 -Support EDMG channels Alexei Avshalom Lazar (3): cfg80211: Add support for 60GHz band channels 5 and 6 nl80211: Add support for EDMG channels wil6210: Add EDMG channel support drivers/net/wireless/ath/wil6210/cfg80211.c | 194 +-- drivers/net/wireless/ath/wil6210/debugfs.c | 2 +- drivers/net/wireless/ath/wil6210/main.c | 3 + drivers/net/wireless/ath/wil6210/txrx_edma.c | 2 + drivers/net/wireless/ath/wil6210/txrx_edma.h | 6 + drivers/net/wireless/ath/wil6210/wil6210.h | 6 +- drivers/net/wireless/ath/wil6210/wmi.c | 5 +- drivers/net/wireless/ath/wil6210/wmi.h | 43 +- include/net/cfg80211.h | 50 ++- include/uapi/linux/nl80211.h | 14 +- net/wireless/chan.c | 88 net/wireless/nl80211.c | 33 + net/wireless/reg.c | 2 +- net/wireless/trace.h | 2 +- net/wireless/util.c | 48 ++- 15 files changed, 468 insertions(+), 30 deletions(-) -- 1.9.1
[PATCH 1/3] cfg80211: Add support for 60GHz band channels 5 and 6
The current support in the 60GHz band is for channels 1-4.
Add support for channels 5 and 6.
This requires enlarging ieee80211_channel.center_freq from u16 to u32.
Signed-off-by: Alexei Avshalom Lazar
---
drivers/net/wireless/ath/wil6210/debugfs.c | 2 +-
include/net/cfg80211.h | 2 +-
include/uapi/linux/nl80211.h | 2 +-
net/wireless/reg.c | 2 +-
net/wireless/trace.h | 2 +-
net/wireless/util.c| 6 +++---
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 58ce044..4b329d1 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1435,7 +1435,7 @@ static int wil_freq_debugfs_show(struct seq_file *s, void
*data)
{
struct wil6210_priv *wil = s->private;
struct wireless_dev *wdev = wil->main_ndev->ieee80211_ptr;
- u16 freq = wdev->chandef.chan ? wdev->chandef.chan->center_freq : 0;
+ u32 freq = wdev->chandef.chan ? wdev->chandef.chan->center_freq : 0;
seq_printf(s, "Freq = %d\n", freq);
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9a85097..73ca446 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -149,7 +149,7 @@ enum ieee80211_channel_flags {
*/
struct ieee80211_channel {
enum nl80211_band band;
- u16 center_freq;
+ u32 center_freq;
u16 hw_value;
u32 flags;
int max_antenna_gain;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 7acc16f..0239896 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4338,7 +4338,7 @@ enum nl80211_txrate_gi {
* enum nl80211_band - Frequency band
* @NL80211_BAND_2GHZ: 2.4 GHz ISM band
* @NL80211_BAND_5GHZ: around 5 GHz band (4.9 - 5.7 GHz)
- * @NL80211_BAND_60GHZ: around 60 GHz band (58.32 - 64.80 GHz)
+ * @NL80211_BAND_60GHZ: around 60 GHz band (58.32 - 69.12 GHz)
* @NUM_NL80211_BANDS: number of bands, avoid using this in userspace
* since newer kernel versions may support more bands
*/
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 4fc66a1..2f8e01a 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3255,7 +3255,7 @@ void regulatory_hint_disconnect(void)
restore_regulatory_settings(false);
}
-static bool freq_is_chan_12_13_14(u16 freq)
+static bool freq_is_chan_12_13_14(u32 freq)
{
if (freq == ieee80211_channel_to_frequency(12, NL80211_BAND_2GHZ) ||
freq == ieee80211_channel_to_frequency(13, NL80211_BAND_2GHZ) ||
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 7c73510..5e7eec8 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -112,7 +112,7 @@
} while (0)
#define CHAN_ENTRY __field(enum nl80211_band, band) \
- __field(u16, center_freq)
+ __field(u32, center_freq)
#define CHAN_ASSIGN(chan)\
do { \
if (chan) { \
diff --git a/net/wireless/util.c b/net/wireless/util.c
index e0825a0..a450736 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -88,7 +88,7 @@ int ieee80211_channel_to_frequency(int chan, enum
nl80211_band band)
return 5000 + chan * 5;
break;
case NL80211_BAND_60GHZ:
- if (chan < 5)
+ if (chan < 7)
return 56160 + chan * 2160;
break;
default:
@@ -109,7 +109,7 @@ int ieee80211_frequency_to_channel(int freq)
return (freq - 4000) / 5;
else if (freq <= 45000) /* DMG band lower limit */
return (freq - 5000) / 5;
- else if (freq >= 58320 && freq <= 64800)
+ else if (freq >= 58320 && freq <= 70200)
return (freq - 56160) / 2160;
else
return 0;
@@ -1568,7 +1568,7 @@ bool ieee80211_chandef_to_operating_class(struct
cfg80211_chan_def *chandef,
}
/* 56.16 GHz, channel 1..4 */
- if (freq >= 56160 + 2160 * 1 && freq <= 56160 + 2160 * 4) {
+ if (freq >= 56160 + 2160 * 1 && freq <= 56160 + 2160 * 6) {
if (chandef->width >= NL80211_CHAN_WIDTH_40)
return false;
--
1.9.1
[PATCH 3/3] wil6210: Add EDMG channel support
Add support for Enhanced Directional Multi-Gigabit (EDMG) channels 9-11.
wil6210 reports it's EDMG capabilities (that are also based on FW
capability) to cfg80211 by filling
wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.
wil6210 handles edmg_channel requested in connect and start_ap
operations.
Signed-off-by: Alexei Avshalom Lazar
---
drivers/net/wireless/ath/wil6210/cfg80211.c | 194 +--
drivers/net/wireless/ath/wil6210/main.c | 3 +
drivers/net/wireless/ath/wil6210/txrx_edma.c | 2 +
drivers/net/wireless/ath/wil6210/txrx_edma.h | 6 +
drivers/net/wireless/ath/wil6210/wil6210.h | 6 +-
drivers/net/wireless/ath/wil6210/wmi.c | 5 +-
drivers/net/wireless/ath/wil6210/wmi.h | 43 +-
7 files changed, 242 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c
b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 4740b53..63c8f44 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -51,6 +51,52 @@
/* channel 4 not supported yet */
};
+/* supported EDMG channels */
+static u8 wil_edmg_channels[] = {9, 10};
+
+/* Rx channel bonding mode */
+enum wil_rx_cb_mode {
+ WIL_RX_CB_MODE_DMG,
+ WIL_RX_CB_MODE_EDMG,
+ WIL_RX_CB_MODE_WIDE,
+};
+
+static int wil_rx_cb_mode_to_n_bonded(u8 cb_mode)
+{
+ switch (cb_mode) {
+ case WIL_RX_CB_MODE_DMG:
+ case WIL_RX_CB_MODE_EDMG:
+ return 1;
+ case WIL_RX_CB_MODE_WIDE:
+ return 2;
+ default:
+ return 1;
+ }
+}
+
+static int wil_tx_cb_mode_to_n_bonded(u8 cb_mode)
+{
+ switch (cb_mode) {
+ case WMI_TX_MODE_DMG:
+ case WMI_TX_MODE_EDMG_CB1:
+ return 1;
+ case WMI_TX_MODE_EDMG_CB2:
+ return 2;
+ default:
+ return 1;
+ }
+}
+
+void wil_update_supported_bands(struct wil6210_priv *wil)
+{
+ struct wiphy *wiphy = wil_to_wiphy(wil);
+
+ wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.channels = wil_edmg_channels;
+ wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.n_channels =
+ ARRAY_SIZE(wil_edmg_channels);
+ wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.supported = true;
+}
+
/* Vendor id to be used in vendor specific command and events
* to user space.
* NOTE: The authoritative place for definition of QCA_NL80211_VENDOR_ID,
@@ -261,6 +307,86 @@ int wil_iftype_nl2wmi(enum nl80211_iftype type)
return -EOPNOTSUPP;
}
+int wil_spec2wmi_ch(u8 spec_ch, u8 *wmi_ch)
+{
+ switch (spec_ch) {
+ case 1:
+ *wmi_ch = WMI_CHANNEL_1;
+ break;
+ case 2:
+ *wmi_ch = WMI_CHANNEL_2;
+ break;
+ case 3:
+ *wmi_ch = WMI_CHANNEL_3;
+ break;
+ case 4:
+ *wmi_ch = WMI_CHANNEL_4;
+ break;
+ case 5:
+ *wmi_ch = WMI_CHANNEL_5;
+ break;
+ case 6:
+ *wmi_ch = WMI_CHANNEL_6;
+ break;
+ case 9:
+ *wmi_ch = WMI_CHANNEL_9;
+ break;
+ case 10:
+ *wmi_ch = WMI_CHANNEL_10;
+ break;
+ case 11:
+ *wmi_ch = WMI_CHANNEL_11;
+ break;
+ case 12:
+ *wmi_ch = WMI_CHANNEL_12;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int wil_wmi2spec_ch(u8 wmi_ch, u8 *spec_ch)
+{
+ switch (wmi_ch) {
+ case WMI_CHANNEL_1:
+ *spec_ch = 1;
+ break;
+ case WMI_CHANNEL_2:
+ *spec_ch = 2;
+ break;
+ case WMI_CHANNEL_3:
+ *spec_ch = 3;
+ break;
+ case WMI_CHANNEL_4:
+ *spec_ch = 4;
+ break;
+ case WMI_CHANNEL_5:
+ *spec_ch = 5;
+ break;
+ case WMI_CHANNEL_6:
+ *spec_ch = 6;
+ break;
+ case WMI_CHANNEL_9:
+ *spec_ch = 9;
+ break;
+ case WMI_CHANNEL_10:
+ *spec_ch = 10;
+ break;
+ case WMI_CHANNEL_11:
+ *spec_ch = 11;
+ break;
+ case WMI_CHANNEL_12:
+ *spec_ch = 12;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
struct station_info *sinfo)
{
@@ -275,6 +401,7 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
} __packed reply;
struct wil_net_stats *stats = >sta[cid].stats;
int rc;
+ u8 txflag = RATE_INFO_FLAGS_DMG;
memset(, 0, sizeof(reply));
@@ -287,7 +414,8 @@ int wil_cid_fill_sinfo(struct wil6210_vif *vif, int cid,
" MCS %d TSF 0x%016llx\n"
Re: [PATCH v2] wireless-regdb: update rules for Hungary (HU) on 2.4/5/60G, 5725-5875MHz
On Sat, Jun 30, 2018 at 10:40:34PM +0200, bkil wrote: > * 2400-2483.5M: extend bounds > * 5150-5250M: extend bounds, add NO-OUTDOOR, no TPC so +3dB > * 5250-5350M: extend bounds, add NO-OUTDOOR > * 5470-5725M: extend bounds > * 5725-5875M: introduce, as EU SRD provisions have been implemented > * 57-66G: add NO-OUTDOOR > > Freely available online references have been added hosted by the regulatory > body in Hungary, the National Media and Infocommunications Authority. > > To refer to a specific section, you can grep for the frequency in question. > > Translation key: > "Csak beltéri" / "Épületen belüli használatra korlátozott" = indoor only; > "Kültéri és beltéri" = both indoor and outdoor; > "Nem működő TPC esetén a maximális teljesítményjellemzők 3 dB-lel > csökkennek." = reduce max power specs by 3dB in case of no TPC; > "Rögzített kültéri telepítés nem megengedett" = no fixed outdoor install > > Signed-off-by: bkil Applied, thanks!
Re: [PATCH] cfg80211: allow to build without CFG80211_REQUIRE_SIGNED_REGDB
On Mon, Aug 13, 2018 at 01:47:53PM +0200, Johannes Berg wrote: > Disagree, if anything should be changed, it should be changed to > > default y if !CERTIFICATION_ONUS > > but I prefer the way it works now, since it means setting certification > onus won't immediately change this setting. Ok, this works as supposed. Not sure why it did not work for me before, maybe I just confused config options. Regards Stanislaw
[PATCH] mac80211: Run TXQ teardown code before de-registering interfaces
The TXQ teardown code can reference the vif data structures that are stored in the netdev private memory area if there are still packets on the queue when it is being freed. Since the TXQ teardown code is run after the netdevs are freed, this can lead to a use-after-free. Fix this by moving the TXQ teardown code to earlier in ieee80211_unregister_hw(). Reported-by: Ben Greear Tested-by: Ben Greear Signed-off-by: Toke Høiland-Jørgensen --- net/mac80211/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/main.c b/net/mac80211/main.c index e054a2fd8d38..98a5c15e8db1 100644 --- a/net/mac80211/main.c +++ b/net/mac80211/main.c @@ -1170,6 +1170,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw) #if IS_ENABLED(CONFIG_IPV6) unregister_inet6addr_notifier(>ifa6_notifier); #endif + ieee80211_txq_teardown_flows(local); rtnl_lock(); @@ -1198,7 +1199,6 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw) skb_queue_purge(>skb_queue); skb_queue_purge(>skb_queue_unreliable); skb_queue_purge(>skb_queue_tdls_chsw); - ieee80211_txq_teardown_flows(local); destroy_workqueue(local->workqueue); wiphy_unregister(local->hw.wiphy); -- 2.18.0
Re: use-after free bug in hacked 4.16 kernel, related to fq_flow_dequeue
Ben Greear writes: > On 08/02/2018 01:20 PM, Toke Høiland-Jørgensen wrote: >> Ben Greear writes: >> >>> On 08/02/2018 12:45 PM, Toke Høiland-Jørgensen wrote: Ben Greear writes: > This is from my hacked kernel, could be my fault. I thought the fq > guys might want to know however... Hmm, nothing obvious comes to mind; fq_flow_dequeue() just dequeues a packet from the queue; it only has two memory derefs, to fq->lock and flow->queue. Don't see why either of those should be freed at this point. Unless fq_adjust_removal() is being inlined, perhaps? Then I suppose the flow->tin reference could be the problem, if the txq_info struct was already freed; did you change anything around the handling of TXQs? >>> >>> I have worked on some stuff to fix other leaks and corruptions in ath10k >>> related >>> to txqs, maybe that is part of this problem. My full tree is here: >>> >>> https://github.com/greearb/linux-ct-4.16 >>> >>> This bug in question is fairly repeatable on my current setup, which >>> is high speed tx + rx on a 9984 NIC, with buggy firmware that crashes >>> often in the tx path. I think the crash only happens when I rmmod the >>> driver under load, but possibly some of the fw crash cleanup logic >>> that ran previously is also involved. >> >> Yeah, if it happens under load that is consistent with packets being >> queued. >> >> It seems that mac80211 frees the netdevs of an interface before flushing >> the TXQs, which may be the cause of the bug you are seeing. Could you >> try the patch below and see if that fixes the issue? > > I've run with this for a few days, and it seems to at least not cause > any extra problems. I mostly fixed the firmware crashing I was seeing > before, so not certain it fixes the root cause of the crashes I > saw before. I'm going to roll this into my 4.16 ct kernel for wider > testing. Right, thanks for testing. I'll send a proper patch :) -Toke
Re: Cpu stall caused by hostapd running two interfaces
Stanislaw Gruszka writes: > (cc Haim and Johannes) > > On Sun, Aug 12, 2018 at 09:54:00PM +0200, Grzegorz Duszyński wrote: >> Hello, >> >> I'm running into problems while trying to start AP's on 2 interfaces. >> Devices are: >> - Compex WLE900VX (QCA9880) >> - Killer 1535 (QCA6174) >> >> The 1535 is a new addition to the system. >> Compex by itself runs fine, Killer also can run alone. >> >> But when running them together all hell breaks lose. >> System is unusable, cannot even reboot. >> >> I'm running Arch Linux. >> My system was updated before testing & posting. >> >> Attachments: >> dmesg - https://pastebin.com/wf3Fq8gh >> >> Please let me know if additional info is required. > > This is oops in ieee80211_regulatory_limit_wmm_params(). > Looks like new regulatory code do not like ath10k. > I have another bug report with reg.c WARNING also on ath10k: > https://bugzilla.redhat.com/show_bug.cgi?id=1612537 I think bug #1612537 is with ath9k, not ath10k. But anyway, both use ath.ko which has some custom regulatory code. -- Kalle Valo
Re: [PATCH] cfg80211: allow to build without CFG80211_REQUIRE_SIGNED_REGDB
On Mon, 2018-08-13 at 13:44 +0200, Stanislaw Gruszka wrote: > On Mon, Aug 13, 2018 at 12:09:13PM +0200, Johannes Berg wrote: > > On Fri, 2018-08-10 at 12:55 +0200, Stanislaw Gruszka wrote: > > > According to kconfig-language.txt conditional dependency should be > > > expressed 2 times: > > > > > > bool "foo" if BAR > > > default y if BAR > > > > > > Indeed, without additional if expression we always build with > > > CFG80211_REQUIRE_SIGNED_REGDB even when CFG80211_CERTIFICATION_ONUS > > > is not set. > > Err, I meant "is set" Ok, but still? > > That's the intent. If you do set CERTIFICATION_ONUS, then you can > > disable this (presumably because you have external OS image verification > > mechanisms, or similar). > > > > If you don't set CERTIFICATION_ONUS, this should always be set. > > Patch allow to build without CFG80211_REQUIRE_SIGNED_REGDB. This option > is not configurable (allways y) no matter of CERTIFICATION_ONUS setting. How so? The default is y, but if CERTIFICATION_ONUS is set, you should be able to change it. > With the patch and with CERTIFICATION_ONUS, > CFG80211_REQUIRE_SIGNED_REGDB is still default y, but can be set to n > during "make oldconfig". I don't think your patch changes anything there since it just changes when the default is applied. > > Perhaps it should be renamed to CFG80211_REQUIRE_REGDB_SIGNATURE or so, > > which might be clearer? And a case has been made before for adding > > CFG80211_FIRMWARE_REGDB_SUPPORT that controls the whole feature, but > > this patch is clearly wrong. > > Patch is fine, there is just typo in the changelog :-) Disagree, if anything should be changed, it should be changed to default y if !CERTIFICATION_ONUS but I prefer the way it works now, since it means setting certification onus won't immediately change this setting. johannes
Re: [PATCH] cfg80211: allow to build without CFG80211_REQUIRE_SIGNED_REGDB
On Mon, Aug 13, 2018 at 12:09:13PM +0200, Johannes Berg wrote: > On Fri, 2018-08-10 at 12:55 +0200, Stanislaw Gruszka wrote: > > According to kconfig-language.txt conditional dependency should be > > expressed 2 times: > > > > bool "foo" if BAR > > default y if BAR > > > > Indeed, without additional if expression we always build with > > CFG80211_REQUIRE_SIGNED_REGDB even when CFG80211_CERTIFICATION_ONUS > > is not set. Err, I meant "is set" > That's the intent. If you do set CERTIFICATION_ONUS, then you can > disable this (presumably because you have external OS image verification > mechanisms, or similar). > > If you don't set CERTIFICATION_ONUS, this should always be set. Patch allow to build without CFG80211_REQUIRE_SIGNED_REGDB. This option is not configurable (allways y) no matter of CERTIFICATION_ONUS setting. With the patch and with CERTIFICATION_ONUS, CFG80211_REQUIRE_SIGNED_REGDB is still default y, but can be set to n during "make oldconfig". > Perhaps it should be renamed to CFG80211_REQUIRE_REGDB_SIGNATURE or so, > which might be clearer? And a case has been made before for adding > CFG80211_FIRMWARE_REGDB_SUPPORT that controls the whole feature, but > this patch is clearly wrong. Patch is fine, there is just typo in the changelog :-) Cheers Stanislaw
Re: help understanding HT capabilities bits
On Thu, 2018-07-26 at 16:43 -0700, Danek Duvall wrote: > I'm writing a library using the nl80211 family to, well, do basically what > iw does (I want a reusable Golang-native implementation, which saves me > from parsing iw's output). I have most of the bits that I need, but I'd > like to fill out more of the library and make it useful to others. Yes please, don't parse iw output :-) > I'm a bit stuck on properly naming and describing the pieces of the HT > capabilities represented by NL80211_BAND_ATTR_HT_CAPA. While being > generally impressed with the amount of documentation in nl80211.h and other > places, I've been unable to find any documentation on this particular > field, other than what iw prints for each bit or bit combination. This comes straight from the 802.11 spec, and we usually have less info on fields like that. > My first thought was that it was the set of per-band capabilities for the > device (as defined by either the hardware or the driver, but either way > below me enough that I don't think I care), and for the most part I still > think that's right. Yes. > But when it came to trying to represent the SMPS bits, > it occurred to me that perhaps that wasn't right, since one of the > supported values gets printed as "disabled", which seems more like a state > than a capability. Yes, also true to some extent. > Also, "static" and "dynamic" are not representable > separately, and set together, you get "disabled". But perhaps "disabled" > is really "unsupported", and "static" and "dynamic" can't both be supported > on the same band? No, you really have "disabled", "static" and "dynamic" as three states represented in the 2 bits. > Otherwise, how should I interpret this? I could simply leave it as a 0-3 > value and let consumers handle the interpretation, but I'd like to be a bit > friendlier than that, if I can. They're just the (default) state - disabled, static, dynamic (and reserved). However, it really is just the default - the (non-AP) device may change it on the fly using action frames. It's not going to be very useful to userspace consumers, I think, since it doesn't reflect the *current* state. johannes
Re: [PATCH] cfg80211: allow to build without CFG80211_REQUIRE_SIGNED_REGDB
On Fri, 2018-08-10 at 12:55 +0200, Stanislaw Gruszka wrote: > According to kconfig-language.txt conditional dependency should be > expressed 2 times: > > bool "foo" if BAR > default y if BAR > > Indeed, without additional if expression we always build with > CFG80211_REQUIRE_SIGNED_REGDB even when CFG80211_CERTIFICATION_ONUS > is not set. That's the intent. If you do set CERTIFICATION_ONUS, then you can disable this (presumably because you have external OS image verification mechanisms, or similar). If you don't set CERTIFICATION_ONUS, this should always be set. Perhaps it should be renamed to CFG80211_REQUIRE_REGDB_SIGNATURE or so, which might be clearer? And a case has been made before for adding CFG80211_FIRMWARE_REGDB_SUPPORT that controls the whole feature, but this patch is clearly wrong. johannes
Re: Cpu stall caused by hostapd running two interfaces
(cc Haim and Johannes) On Sun, Aug 12, 2018 at 09:54:00PM +0200, Grzegorz Duszyński wrote: > Hello, > > I'm running into problems while trying to start AP's on 2 interfaces. > Devices are: > - Compex WLE900VX (QCA9880) > - Killer 1535 (QCA6174) > > The 1535 is a new addition to the system. > Compex by itself runs fine, Killer also can run alone. > > But when running them together all hell breaks lose. > System is unusable, cannot even reboot. > > I'm running Arch Linux. > My system was updated before testing & posting. > > Attachments: > dmesg - https://pastebin.com/wf3Fq8gh > > Please let me know if additional info is required. This is oops in ieee80211_regulatory_limit_wmm_params(). Looks like new regulatory code do not like ath10k. I have another bug report with reg.c WARNING also on ath10k: https://bugzilla.redhat.com/show_bug.cgi?id=1612537 Regards Stanislaw [ 631.040507] BUG: unable to handle kernel NULL pointer dereference at 0266 [ 631.046313] PGD 0 P4D 0 [ 631.052020] Oops: [#1] PREEMPT SMP NOPTI [ 631.057782] Modules linked in: veth tun xt_nat xfrm_user xfrm_algo br_netfilter bridge stp llc overlay xt_recent ipt_REJECT nf_reject_ipv4 xt_multiport xt_conntrack xt_hashlimit xt_addrtype xt_mark iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_tcpudp xt_CT iptable_raw xt_NFLOG nfnetlink_log nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_sane nf_conntrack_netlink nfnetlink nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp ts_kmp nf_conntrack_amanda iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c [ 631.096648] iptable_filter ccm arc4 nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi snd_hda_codec_realtek intel_rapl snd_hda_codec_generic intel_telemetry_pltdrv intel_punit_ipc intel_telemetry_core intel_pmc_ipc ofpart cmdlinepart x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel intel_spi_platform intel_spi spi_nor snd_soc_skl mtd ath10k_pci kvm snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp irqbypass ath10k_core crct10dif_pclmul crc32_pclmul snd_soc_sst_ipc ghash_clmulni_intel ath snd_soc_acpi i915 pcbc btusb snd_soc_core btrtl btbcm btintel mac80211 bluetooth snd_compress ac97_bus aesni_intel snd_pcm_dmaengine aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf snd_hda_intel wdat_wdt pcspkr i2c_algo_bit snd_hda_codec drm_kms_helper cfg80211 joydev snd_hda_core [ 631.140625] huawei_cdc_ncm drm ecdh_generic cdc_wdm snd_hwdep input_leds cdc_ncm option snd_pcm usbnet led_class usb_wwan usbserial r8169 i2c_i801 intel_gtt lpc_ich snd_timer agpgart mei_me mii syscopyarea rfkill snd sysfillrect sysimgblt mei tpm_crb fb_sys_fops soundcore shpchp evdev tpm_tis rtc_cmos mac_hid tpm_tis_core tpm rng_core pcc_cpufreq ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto raid1 md_mod hid_generic sd_mod usbhid hid ahci xhci_pci libahci crc32c_intel xhci_hcd libata usbcore usb_common scsi_mod [ 631.173368] CPU: 2 PID: 1659 Comm: hostapd Not tainted 4.17.14-arch1-1-ARCH #1 [ 631.181686] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.40 07/14/2017 [ 631.190151] RIP: 0010:ieee80211_regulatory_limit_wmm_params.part.8+0x6e/0xd0 [mac80211] [ 631.198537] RSP: 0018:a670c06b7a10 EFLAGS: 00010246 [ 631.206951] RAX: 0246 RBX: a670c06b7a36 RCX: 00256a20 [ 631.215397] RDX: 0266 RSI: 00259130 RDI: 93f2ea999420 [ 631.223789] RBP: R08: c0872d40 R09: a670c06b7aa0 [ 631.232170] R10: 93f2e20c9940 R11: 002c R12: 93f2e735a8c0 [ 631.240515] R13: 93f2e735a8c0 R14: 93f2e6940760 R15: 93f2e735a8d0 [ 631.248931] FS: 7f91c0890ec0() GS:93f2e2b0() knlGS: [ 631.257350] CS: 0010 DS: ES: CR0: 80050033 [ 631.265741] CR2: 0266 CR3: 6669c000 CR4: 003406e0 [ 631.274206] Call Trace: [ 631.282665] ieee80211_set_txq_params+0x93/0x140 [mac80211] [ 631.291141] nl80211_set_wiphy+0x271/0x9c0 [cfg80211] [ 631.299551] genl_family_rcv_msg+0x1c4/0x3a0 [ 631.307888] genl_rcv_msg+0x47/0x90 [ 631.316201] ? __kmalloc_node_track_caller+0x210/0x2b0 [ 631.324462] ? genl_family_rcv_msg+0x3a0/0x3a0 [ 631.332669] netlink_rcv_skb+0x4c/0x120 [ 631.340889] genl_rcv+0x24/0x40 [ 631.349135] netlink_unicast+0x196/0x240 [ 631.357389] netlink_sendmsg+0x1fd/0x3c0 [ 631.365640] sock_sendmsg+0x33/0x40 [ 631.373796] ___sys_sendmsg+0x295/0x2f0 [ 631.381881] ? netlink_sendmsg+0x20a/0x3c0 [ 631.389811] ? sock_sendmsg+0x33/0x40 [ 631.397587] ? __sys_sendto+0xee/0x160 [ 631.405264] __sys_sendmsg+0x57/0xa0 [
