Re: [PATCH 5/5] ath9k: fix reporting calculated new FFT upper max

[Simon Wunderlich]

On Monday, October 1, 2018 5:31:42 PM CEST Kalle Valo wrote:
> Simon Wunderlich  writes:
> > On Monday, October 1, 2018 2:07:55 PM CEST Kalle Valo wrote:
> >> Simon Wunderlich  wrote:
> >> > Cc: Nick Kossifidis 
> >> > Signed-off-by: Simon Wunderlich 
> >> > Signed-off-by: Kalle Valo 
> >> 
> >> No empty commit logs, please. But I can add that, just tell me what to
> >> add.
> > 
> > How about:
> > 
> > Since the debug print code is outside of the loop, it shouldn't use the
> > loop iterator anymore but instead print the found maximum index.
> 
> Perfect, thanks.
> 
> > Let me know if you need me to resend or anything else.
> 
> No need, I added this to the patch in the (not yet pushed) pending
> branch.

Awesome, thank you!

Cheers,
 Simon

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 5/5] ath9k: fix reporting calculated new FFT upper max

[Simon Wunderlich]

On Monday, October 1, 2018 2:07:55 PM CEST Kalle Valo wrote:
> Simon Wunderlich  wrote:
> > Cc: Nick Kossifidis 
> > Signed-off-by: Simon Wunderlich 
> > Signed-off-by: Kalle Valo 
> 
> No empty commit logs, please. But I can add that, just tell me what to add.

How about:

Since the debug print code is outside of the loop, it shouldn't use the loop 
iterator anymore but instead print the found maximum index.





Let me know if you need me to resend or anything else.

Thank you,
  Simon


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] mac80211: allow scans on radar channels, unless there is CAC or CSA

[Simon Wunderlich]

Hi Dan,

whoops, right ... thank you!

Will do in a v2, at least if this patch is wanted. :)

Thank you!
 Simon

On Thursday, September 20, 2018 12:20:14 PM CEST Dan Carpenter wrote:
> Hi Simon,
> 
> I love your patch! Perhaps something to improve:
> 
> url:   
> https://github.com/0day-ci/linux/commits/Simon-Wunderlich/mac80211-allow-sc
> ans-on-radar-channels-unless-there-is-CAC-or-CSA/20180919-071924 base:  
> https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git master
> 
> New smatch warnings:
> net/mac80211/scan.c:508 ieee80211_can_scan() warn: signedness bug returning
> '(-16)'
> 
> Old smatch warnings:
> net/mac80211/scan.c:511 ieee80211_can_scan() warn: signedness bug returning
> '(-16)'
> 
> #
> https://github.com/0day-ci/linux/commit/ad9617f275c425ddf25eb83678062ab87d4
> c0870 git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout ad9617f275c425ddf25eb83678062ab87d4c0870
> vim +508 net/mac80211/scan.c
> 
> f3b85252 Johannes Berg 2009-04-23  503
> 133d40f9 Stanislaw Gruszka 2012-03-28  504  static bool
> ieee80211_can_scan(struct ieee80211_local *local, 
> 133d40f9 Stanislaw Gruszka 2012-03-28  505   struct
> ieee80211_sub_if_data *sdata) 133d40f9 Stanislaw Gruszka 2012-03-28  506  {
> ad9617f2 Simon Wunderlich  2018-09-18  507if (sdata->wdev.cac_started)
> ad9617f2 Simon Wunderlich  2018-09-18 @508return -EBUSY;
>     ^
> ad9617f2 Simon Wunderlich  2018-09-18  509
> ad9617f2 Simon Wunderlich  2018-09-18  510if (sdata->vif.csa_active)
> ad9617f2 Simon Wunderlich  2018-09-18  511    return -EBUSY;
> ^^
> 164eb02d Simon Wunderlich  2013-02-08  512
> 2eb278e0 Johannes Berg 2012-06-05  513if
> (!list_empty(>roc_list)) 133d40f9 Stanislaw Gruszka 2012-03-28  514 
>   return false;
> 133d40f9 Stanislaw Gruszka 2012-03-28  515
> 133d40f9 Stanislaw Gruszka 2012-03-28  516if (sdata->vif.type ==
> NL80211_IFTYPE_STATION && 392b9ffb Stanislaw Gruszka 2013-08-27  517  
>
> sdata->u.mgd.flags & IEEE80211_STA_CONNECTION_POLL) 133d40f9 Stanislaw
> Gruszka 2012-03-28  518   return false;
> 133d40f9 Stanislaw Gruszka 2012-03-28  519
> 133d40f9 Stanislaw Gruszka 2012-03-28  520return true;
> 133d40f9 Stanislaw Gruszka 2012-03-28  521  }
> 133d40f9 Stanislaw Gruszka 2012-03-28  522
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology
> Center https://lists.01.org/pipermail/kbuild-all   Intel
> Corporation



signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] mac80211: allow scans on radar channels, unless there is CAC or CSA

[Simon Wunderlich]

On Thursday, September 20, 2018 11:21:16 AM CEST Johannes Berg wrote:
> On Tue, 2018-09-18 at 16:16 +0200, Simon Wunderlich wrote:
> > Operating on a DFS channel doesn't mean we can't leave it for a short
> > time - actually, some features like off-channel CAC work by leaving the
> > operation channel to check other channels for availability (although
> > off-channel CAC isn't implemented in mac80211). In our case, we want to
> > use mesh while doing background surveys on other channels from time to
> > time.
> 
> Actually ... as far as I can tell it *does* mean that, at least
> currently for FCC.


Mhm. I remember you said that before. But I can't find references for it. I 
checked the FCC 15.407 document [1] but couldn't find anything in favor or 
against that. Same for the measurement procedures [2]. I also couldn't find 
off-channel CAC in FCC, which I used for my argument in ETSI:

In ETSI 301 893 [3] they talk about non-continuous checks for off-channel CAC 
(in 4.2.6.2.3, second paragraph) and continuous period for CAC (4.2.6.2.2.2, 
first paragraph). Continuity is not mentioned for in-service monitoring 
(4.2.6.2.4), but off-channel CAC could only work when continuity is not 
required.

I'd appreciate if you (or someone else) can point me to where it's stated that 
we can't leave the channel for the a short time. I'm assuming that we are back 
fast enough to ensure the required detection probability.

Cheers,
 Simon

[1] https://www.law.cornell.edu/definitions/index.php?
width=840=800=true_id=41106ee4d951847389e55571a5e5e8aa_occur=1_src=Title:
47:Chapter:I:Subchapter:A:Part:15:Subpart:E:15.407
[2] https://apps.fcc.gov/kdb/GetAttachment.html?id=V2DzGgztnfxjTcht59nQ7Q%3D
%3D=905462%20D02%20UNII%20DFS%20Compliance%20Procedures%20New%20Rules
%20v02_number=27155
[3] https://www.etsi.org/deliver/etsi_en/301800_301899/301893/02.01.01_60/
en_301893v020101p.pdf
> 
> johannes



signature.asc
Description: This is a digitally signed message part.

[PATCH 4/5] ath9k: FFT magnitude check: don't consider lower 3 data bits

[Simon Wunderlich]

There were a lot of Magnitude Mismatch while getting FFT samples on my
hardware (Atheros AR9462. I've compared the reported magnitude with
the data in the FFT bin, and the FFT bin was less accurate:

[ 5395.193030] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28,
,magnitude 0x89 max_exp 0, data[28] = 0x88
[ 5395.194525] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28,
,magnitude 0x89 max_exp 0, data[28] = 0x88
[ 5395.196012] ath: phy0: FFT HT20 frame: max mag 0x88,max_mag_idx 28,
,magnitude 0x88 max_exp 0, data[28] = 0x88
[ 5395.197509] ath: phy0: FFT HT20 frame: max mag 0x6C,max_mag_idx 28,
,magnitude 0x6C max_exp 0, data[28] = 0x68
[ 5395.199015] ath: phy0: FFT HT20 frame: max mag 0x78,max_mag_idx 28,
,magnitude 0x78 max_exp 0, data[28] = 0x78
[ 5395.200497] ath: phy0: FFT HT20 frame: max mag 0xA1,max_mag_idx 28,
,magnitude 0xA1 max_exp 0, data[28] = 0xA0
[ 5395.202011] ath: phy0: FFT HT20 frame: max mag 0x91,max_mag_idx 28,
,magnitude 0x91 max_exp 0, data[28] = 0x90
[ 5395.203482] ath: phy0: FFT HT20 frame: max mag 0x89,max_mag_idx 28,
,magnitude 0x89 max_exp 0, data[28] = 0x88
[ 5395.204999] ath: phy0: FFT HT20 frame: max mag 0x27,max_mag_idx 4,
,magnitude 0x27 max_exp 0, data[4] = 0x20
[ 5395.206461] ath: phy0: FFT HT20 frame: max mag 0x41,max_mag_idx 28,
,magnitude 0x41 max_exp 0, data[28] = 0x40
[ 5395.207977] ath: phy0: FFT HT20 frame: max mag 0x51,max_mag_idx 28,
,magnitude 0x51 max_exp 0, data[28] = 0x50
[ 5395.209454] ath: phy0: FFT HT20 frame: max mag 0x53,max_mag_idx 28,
,magnitude 0x53 max_exp 0, data[28] = 0x50
[ 5395.210940] ath: phy0: FFT HT20 frame: max mag 0x40,max_mag_idx 28,
,magnitude 0x40 max_exp 0, data[28] = 0x40
[ 5395.212441] ath: phy0: FFT HT20 frame: max mag 0x59,max_mag_idx 28,
,magnitude 0x59 max_exp 0, data[28] = 0x58
[ 5395.213932] ath: phy0: FFT HT20 frame: max mag 0x53,max_mag_idx 28,
,magnitude 0x53 max_exp 0, data[28] = 0x50
[ 5395.215428] ath: phy0: FFT HT20 frame: max mag 0x7D,max_mag_idx 28,
,magnitude 0x7D max_exp 0, data[28] = 0x78
[ 5395.216910] ath: phy0: FFT HT20 frame: max mag 0x8C,max_mag_idx 28,
,magnitude 0x8C max_exp 0, data[28] = 0x88
[ 5395.218413] ath: phy0: FFT HT20 frame: max mag 0x7B,max_mag_idx 28,
,magnitude 0x7B max_exp 0, data[28] = 0x78
[ 5395.219900] ath: phy0: FFT HT20 frame: max mag 0x43,max_mag_idx 28,
,magnitude 0x43 max_exp 0, data[28] = 0x40

It seems like the lower 3 bits on my hardware are always zeroed, but the
magnitude matches otherwise. Therefore, let's not make the magnitude
check so strict so we can get those samples released to userspace.

Cc: Nick Kossifidis 
Signed-off-by: Simon Wunderlich 
---
 drivers/net/wireless/ath/ath9k/common-spectral.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c 
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index d10e3f29c356..70ddaf6199a0 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -71,7 +71,7 @@ ath_cmn_max_idx_verify_ht20_fft(u8 *sample_end, int 
bytes_read)
if (bytes_read < SPECTRAL_HT20_SAMPLE_LEN && max_index < 1)
return -1;
 
-   if (sample[max_index] != (max_magnitude >> max_exp))
+   if ((sample[max_index] & 0xf8) != ((max_magnitude >> max_exp) & 0xf8))
return -1;
else
return 0;
@@ -114,8 +114,10 @@ ath_cmn_max_idx_verify_ht20_40_fft(u8 *sample_end, int 
bytes_read)
   ((upper_max_index < 1) || (lower_max_index < 1)))
return -1;
 
-   if ((sample[upper_max_index + dc_pos] != (upper_mag >> max_exp)) ||
-  (sample[lower_max_index] != (lower_mag >> max_exp)))
+   if (((sample[upper_max_index + dc_pos] & 0xf8) !=
+((upper_mag >> max_exp) & 0xf8)) ||
+   ((sample[lower_max_index] & 0xf8) !=
+((lower_mag >> max_exp) & 0xf8)))
return -1;
else
return 0;
@@ -173,7 +175,8 @@ ath_cmn_process_ht20_fft(struct ath_rx_status *rs,
magnitude >> max_exp,
max_index);
 
-   if (fft_sample_20.data[max_index] != (magnitude >> max_exp)) {
+   if ((fft_sample_20.data[max_index] & 0xf8) !=
+   ((magnitude >> max_exp) & 0xf8)) {
ath_dbg(common, SPECTRAL_SCAN, "Magnitude mismatch !\n");
ret = -1;
}
@@ -317,10 +320,10 @@ ath_cmn_process_ht20_40_fft(struct ath_rx_status *rs,
/* Check if we got the expected magnitude values at
 * the expected bins
 */
-   if ((fft_sample_40.data[upper_max_index + dc_pos]
-   != (upper_mag >> max_exp)) ||
-  (fft_sample_40.data[lower_max_index]
-   != (lower_mag >> max_exp))) {
+   if (((fft_sample_40.data[uppe

[PATCH 5/5] ath9k: fix reporting calculated new FFT upper max

[Simon Wunderlich]

Cc: Nick Kossifidis 
Signed-off-by: Simon Wunderlich 
---
 drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c 
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 70ddaf6199a0..6a43d26276e5 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -381,7 +381,7 @@ ath_cmn_process_ht20_40_fft(struct ath_rx_status *rs,
 
ath_dbg(common, SPECTRAL_SCAN,
"Calculated new upper max 0x%X at %i\n",
-   tmp_mag, i);
+   tmp_mag, fft_sample_40.upper_max_index);
} else
for (i = dc_pos; i < SPECTRAL_HT20_40_NUM_BINS; i++) {
if (fft_sample_40.data[i] == (upper_mag >> max_exp))
-- 
2.11.0

[PATCH 1/5] ath9k: add counters for good and errorneous FFT/spectral frames

[Simon Wunderlich]

This is helpful to see whether spectral samples get discarded.

Signed-off-by: Simon Wunderlich 
---
 drivers/net/wireless/ath/ath9k/common-debug.c|  2 ++
 drivers/net/wireless/ath/ath9k/common-debug.h|  4 
 drivers/net/wireless/ath/ath9k/common-spectral.c | 15 +--
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/common-debug.c 
b/drivers/net/wireless/ath/ath9k/common-debug.c
index 239429f10378..53ca4b063eb9 100644
--- a/drivers/net/wireless/ath/ath9k/common-debug.c
+++ b/drivers/net/wireless/ath/ath9k/common-debug.c
@@ -144,6 +144,8 @@ static ssize_t read_file_recv(struct file *file, char 
__user *user_buf,
RXS_ERR("BEACONS", rx_beacons);
RXS_ERR("FRAGS", rx_frags);
RXS_ERR("SPECTRAL", rx_spectral);
+   RXS_ERR("SPECTRAL SMPL GOOD", rx_spectral_sample_good);
+   RXS_ERR("SPECTRAL SMPL ERR", rx_spectral_sample_err);
 
RXS_ERR("CRC ERR", crc_err);
RXS_ERR("DECRYPT CRC ERR", decrypt_crc_err);
diff --git a/drivers/net/wireless/ath/ath9k/common-debug.h 
b/drivers/net/wireless/ath/ath9k/common-debug.h
index 3376990d3a24..2938b5b96b07 100644
--- a/drivers/net/wireless/ath/ath9k/common-debug.h
+++ b/drivers/net/wireless/ath/ath9k/common-debug.h
@@ -39,6 +39,8 @@
  * @rx_beacons:  No. of beacons received.
  * @rx_frags:  No. of rx-fragements received.
  * @rx_spectral: No of spectral packets received.
+ * @rx_spectral_sample_good: No. of good spectral samples
+ * @rx_spectral_sample_err: No. of good spectral samples
  */
 struct ath_rx_stats {
u32 rx_pkts_all;
@@ -58,6 +60,8 @@ struct ath_rx_stats {
u32 rx_beacons;
u32 rx_frags;
u32 rx_spectral;
+   u32 rx_spectral_sample_good;
+   u32 rx_spectral_sample_err;
 };
 
 #ifdef CONFIG_ATH9K_COMMON_DEBUG
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c 
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 440e16e641e4..0c5559009a28 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -501,6 +501,7 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv 
*spec_priv, struct ieee80211_h
u8 sample_buf[SPECTRAL_SAMPLE_MAX_LEN] = {0};
struct ath_hw *ah = spec_priv->ah;
struct ath_common *common = ath9k_hw_common(spec_priv->ah);
+   struct ath_softc *sc = (struct ath_softc *)common->priv;
u8 num_bins, *vdata = (u8 *)hdr;
struct ath_radar_info *radar_info;
int len = rs->rs_datalen;
@@ -649,8 +650,13 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv 
*spec_priv, struct ieee80211_h
   sample_buf, sample_len,
   sample_bytes);
 
-   fft_handler(rs, spec_priv, sample_buf,
-   tsf, freq, chan_type);
+   ret = fft_handler(rs, spec_priv, sample_buf,
+ tsf, freq, chan_type);
+
+   if (ret == 0)
+   RX_STAT_INC(rx_spectral_sample_good);
+   else
+   RX_STAT_INC(rx_spectral_sample_err);
 
memset(sample_buf, 0, SPECTRAL_SAMPLE_MAX_LEN);
 
@@ -665,6 +671,11 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv 
*spec_priv, struct ieee80211_h
ret = fft_handler(rs, spec_priv, sample_start,
  tsf, freq, chan_type);
 
+   if (ret == 0)
+   RX_STAT_INC(rx_spectral_sample_good);
+   else
+   RX_STAT_INC(rx_spectral_sample_err);
+
/* Mix the received bins to the /dev/random
 * pool
 */
-- 
2.11.0

[PATCH 3/5] ath9k: fix and simplify FFT max index retrieval

[Simon Wunderlich]

FFT max index retrieval was not retrieved correctly for HT20/HT40 FFT
frames. Fixing the retrieval allows us to remove the fixup function as
well. While at it, split the spectral_max_index function into versions
for ht20 and ht40 to simplify the code.

Cc: Nick Kossifidis 
Signed-off-by: Simon Wunderlich 
---
 drivers/net/wireless/ath/ath9k/common-spectral.c | 45 
 drivers/net/wireless/ath/ath9k/common-spectral.h | 17 +
 2 files changed, 23 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c 
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index f6dd0ecfbbf3..d10e3f29c356 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -59,8 +59,7 @@ ath_cmn_max_idx_verify_ht20_fft(u8 *sample_end, int 
bytes_read)
 
sample = sample_end - SPECTRAL_HT20_SAMPLE_LEN + 1;
 
-   max_index = spectral_max_index(mag_info->all_bins,
-  SPECTRAL_HT20_NUM_BINS);
+   max_index = spectral_max_index_ht20(mag_info->all_bins);
max_magnitude = spectral_max_magnitude(mag_info->all_bins);
 
max_exp = mag_info->max_exp & 0xf;
@@ -100,12 +99,10 @@ ath_cmn_max_idx_verify_ht20_40_fft(u8 *sample_end, int 
bytes_read)
sample = sample_end - SPECTRAL_HT20_40_SAMPLE_LEN + 1;
 
lower_mag = spectral_max_magnitude(mag_info->lower_bins);
-   lower_max_index = spectral_max_index(mag_info->lower_bins,
-SPECTRAL_HT20_40_NUM_BINS);
+   lower_max_index = spectral_max_index_ht40(mag_info->lower_bins);
 
upper_mag = spectral_max_magnitude(mag_info->upper_bins);
-   upper_max_index = spectral_max_index(mag_info->upper_bins,
-SPECTRAL_HT20_40_NUM_BINS);
+   upper_max_index = spectral_max_index_ht40(mag_info->upper_bins);
 
max_exp = mag_info->max_exp & 0xf;
 
@@ -117,17 +114,6 @@ ath_cmn_max_idx_verify_ht20_40_fft(u8 *sample_end, int 
bytes_read)
   ((upper_max_index < 1) || (lower_max_index < 1)))
return -1;
 
-   /* Some time hardware messes up the index and adds
-* the index of the middle point (dc_pos). Try to fix it.
-*/
-   if ((upper_max_index - dc_pos > 0) &&
-  (sample[upper_max_index] == (upper_mag >> max_exp)))
-   upper_max_index -= dc_pos;
-
-   if ((lower_max_index - dc_pos > 0) &&
-  (sample[lower_max_index - dc_pos] == (lower_mag >> max_exp)))
-   lower_max_index -= dc_pos;
-
if ((sample[upper_max_index + dc_pos] != (upper_mag >> max_exp)) ||
   (sample[lower_max_index] != (lower_mag >> max_exp)))
return -1;
@@ -169,8 +155,7 @@ ath_cmn_process_ht20_fft(struct ath_rx_status *rs,
magnitude = spectral_max_magnitude(mag_info->all_bins);
fft_sample_20.max_magnitude = __cpu_to_be16(magnitude);
 
-   max_index = spectral_max_index(mag_info->all_bins,
-   SPECTRAL_HT20_NUM_BINS);
+   max_index = spectral_max_index_ht20(mag_info->all_bins);
fft_sample_20.max_index = max_index;
 
bitmap_w = spectral_bitmap_weight(mag_info->all_bins);
@@ -302,12 +287,10 @@ ath_cmn_process_ht20_40_fft(struct ath_rx_status *rs,
upper_mag = spectral_max_magnitude(mag_info->upper_bins);
fft_sample_40.upper_max_magnitude = __cpu_to_be16(upper_mag);
 
-   lower_max_index = spectral_max_index(mag_info->lower_bins,
-   SPECTRAL_HT20_40_NUM_BINS);
+   lower_max_index = spectral_max_index_ht40(mag_info->lower_bins);
fft_sample_40.lower_max_index = lower_max_index;
 
-   upper_max_index = spectral_max_index(mag_info->upper_bins,
-   SPECTRAL_HT20_40_NUM_BINS);
+   upper_max_index = spectral_max_index_ht40(mag_info->upper_bins);
fft_sample_40.upper_max_index = upper_max_index;
 
lower_bitmap_w = spectral_bitmap_weight(mag_info->lower_bins);
@@ -331,22 +314,6 @@ ath_cmn_process_ht20_40_fft(struct ath_rx_status *rs,
upper_mag >> max_exp,
upper_max_index);
 
-   /* Some time hardware messes up the index and adds
-* the index of the middle point (dc_pos). Try to fix it.
-*/
-   if ((upper_max_index - dc_pos > 0) &&
-  (fft_sample_40.data[upper_max_index] == (upper_mag >> max_exp))) {
-   upper_max_index -= dc_pos;
-   fft_sample_40.upper_max_index = upper_max_index;
-   }
-
-   if ((lower_max_index - dc_pos > 0) &&
-  (fft_sample_40.data[lower_max_index - dc_pos] ==
-  (lower_mag >> max_exp))) {
- 

[PATCH 0/5] ath9k: FFT fixes and improvements

[Simon Wunderlich]

During FFT evaluation on an AR9462 adapter, we noticed that there were
way less FFT samples received than we would expect. This patchset adds
some counters to be able to check for received (and discarded) FFT
samples, and fixes a variety of issues I found while debugging.

Cheers,
 Simon

Simon Wunderlich (5):
  ath9k: add counters for good and errorneous FFT/spectral frames
  ath9k: return when short FFT frame was handled
  ath9k: fix and simplify FFT max index retrieval
  ath9k: FFT magnitude check: don't consider lower 3 data bits
  ath9k: fix reporting calculated new FFT upper max

 drivers/net/wireless/ath/ath9k/common-debug.c|  2 +
 drivers/net/wireless/ath/ath9k/common-debug.h|  4 ++
 drivers/net/wireless/ath/ath9k/common-spectral.c | 83 +---
 drivers/net/wireless/ath/ath9k/common-spectral.h | 17 +
 4 files changed, 55 insertions(+), 51 deletions(-)

-- 
2.11.0

[PATCH 2/5] ath9k: return when short FFT frame was handled

[Simon Wunderlich]

With the loop break like this, there are false "FFT report truncated"
messages because the iterator is not advanced as the check expects.

Instead, just return, for a single frame there is nothing left to be
done anyways.

Cc: Nick Kossifidis 
Signed-off-by: Simon Wunderlich 
---
 drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c 
b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 0c5559009a28..f6dd0ecfbbf3 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -686,7 +686,7 @@ int ath_cmn_process_fft(struct ath_spec_scan_priv 
*spec_priv, struct ieee80211_h
 * loop.
 */
if (len <= fft_len + 2)
-   break;
+   return 1;
 
sample_start = [i + 1];
 
-- 
2.11.0

[PATCH] mac80211: allow scans on radar channels, unless there is CAC or CSA

[Simon Wunderlich]

Operating on a DFS channel doesn't mean we can't leave it for a short
time - actually, some features like off-channel CAC work by leaving the
operation channel to check other channels for availability (although
off-channel CAC isn't implemented in mac80211). In our case, we want to
use mesh while doing background surveys on other channels from time to
time.

Therefore, we can enable scans while on DFS channels, unless there is
CAC going on (must be continuous) or a CSA is happening.

Reported-by: Mathias Kretschmer 
Cc: Eliad Peller 
Signed-off-by: Simon Wunderlich 
---
 net/mac80211/scan.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 47d2ed570470..58a454515a5a 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -477,8 +477,11 @@ static int ieee80211_start_sw_scan(struct ieee80211_local 
*local,
 static bool ieee80211_can_scan(struct ieee80211_local *local,
   struct ieee80211_sub_if_data *sdata)
 {
-   if (ieee80211_is_radar_required(local))
-   return false;
+   if (sdata->wdev.cac_started)
+   return -EBUSY;
+
+   if (sdata->vif.csa_active)
+   return -EBUSY;
 
if (!list_empty(>roc_list))
return false;
@@ -550,7 +553,7 @@ static int __ieee80211_start_scan(struct 
ieee80211_sub_if_data *sdata,
 
lockdep_assert_held(>mtx);
 
-   if (local->scan_req || ieee80211_is_radar_required(local))
+   if (local->scan_req)
return -EBUSY;
 
if (!ieee80211_can_scan(local, sdata)) {
-- 
2.11.0

Re: [PATCH 2/2] wireless: return correct mandatory rates

[Simon Wunderlich]

Hi,

On Friday, September 8, 2017 10:53:37 AM CEST Richard Schütz wrote:
> Am 08.09.2017 um 10:43 schrieb Richard Schütz:
> > Am 08.09.2017 um 08:55 schrieb Johannes Berg:
> >> On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote:
> >>> Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B
> >>> for comparison to get all mandatory rates in 2.4 GHz band. It is safe
> >>> to do so because ERP mandatory rates are a superset of HR/DSSS
> >>> mandatory rates.
> >> 
> >> This I don't understand - what "comparison" are you talking about?
> > 
> > Sorry, I meant the condition that checks for the presence of
> > mandatory_flag at the bottom of the function.
> > 
> >>> Also force IEEE80211_RATE_MANDATORY_A for 10 MHz and 5 MHz channels
> >>> as they use "half-clocked" respectively "quarter-clocked" operation
> >>> of the OFDM rates (IEEE Std 802.11-2016, 17.1.1).
> >> 
> >> I don't think this is correct - the way the flags are used, anything on
> >> 2.4 GHz would never bother to check the MANDATORY_A flag.
> > 
> > Do we actually allow 10 MHz and 5 MHz operation in the 2.4 GHz band? As
> > far as I can tell that has only been specified for OFDM PHYs, which use
> > the 5 GHz band and are covered by IEEE80211_RATE_MANDATORY_A, but I am
> > not a hundred per cent sure about that. Cc'ing Simon Wunderlich who
> > originally implemented checking of scan_width here.
> 
> Looks like the old address is invalid now. New try.
> 

Yeah, officially only OFDM has the half/quarter clock stuff defined, not ERP 
(2.4 
GHz 11g) or DSSS, and also not HT.

However, technically, the Qualcomm/Atheros hardware (ath9k and ath5k) supports 
DSSS or HT on quarter and half rates just fine, also on 2.4 GHz.

I believe we currently support the 5/10 MHz on 2.4 GHz, although we shouldn't 
when we follow the standard strictly. The question is if we should follow the 
standard strictly - this feature is already quite limited, and people tend to 
use the ath9k/ath5k chanbw patch from OpenWRT/LEDE.

Cheers,
  Simon

signature.asc
Description: This is a digitally signed message part.

[PATCH v2 2/2] mac80211: enable VHT for mesh channel processing

[Simon Wunderlich]

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 net/mac80211/mesh.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 872a05606f06..d526fbd81d10 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -989,12 +989,14 @@ ieee80211_mesh_process_chnswitch(struct 
ieee80211_sub_if_data *sdata,
if (!sband)
return false;
 
-   sta_flags = IEEE80211_STA_DISABLE_VHT;
+   sta_flags = 0;
switch (sdata->vif.bss_conf.chandef.width) {
case NL80211_CHAN_WIDTH_20_NOHT:
sta_flags |= IEEE80211_STA_DISABLE_HT;
case NL80211_CHAN_WIDTH_20:
sta_flags |= IEEE80211_STA_DISABLE_40MHZ;
+   case NL80211_CHAN_WIDTH_40:
+   sta_flags |= IEEE80211_STA_DISABLE_VHT;
break;
default:
break;
-- 
2.11.0

[PATCH v2 0/2] extend mac80211 mesh DFS and CSA functionality

[Simon Wunderlich]

This patchset includes the remaining two patches for the CSA handling,
with Johannes change suggestions integrated.

Cheers,
 Simon

Simon Wunderlich (2):
  mac80211: mesh: support sending wide bandwidth CSA
  mac80211: enable VHT for mesh channel processing

 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/mesh.c| 49 +++---
 net/mac80211/util.c| 40 +
 3 files changed, 88 insertions(+), 3 deletions(-)

-- 
2.11.0

[PATCH v2 1/2] mac80211: mesh: support sending wide bandwidth CSA

[Simon Wunderlich]

To support HT and VHT CSA, beacons and action frames must include the
corresponding IEs.

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
Changes to PATCHv1 (Thanks Johannes)
 * change patch subject (originally: mac80211: add wide bandwidth
channel switch announcement to CSA action frames and mesh beacons)
 * use skb_put() to simplify csa handling
---
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/mesh.c| 45 +++--
 net/mac80211/util.c| 40 
 3 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c960e4999380..e3a0b295c5ce 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -2066,6 +2066,8 @@ u8 *ieee80211_ie_build_ht_cap(u8 *pos, struct 
ieee80211_sta_ht_cap *ht_cap,
 u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct ieee80211_sta_ht_cap *ht_cap,
   const struct cfg80211_chan_def *chandef,
   u16 prot_mode, bool rifs_mode);
+u8 *ieee80211_ie_build_wide_bw_cs(u8 *pos,
+ const struct cfg80211_chan_def *chandef);
 u8 *ieee80211_ie_build_vht_cap(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
   u32 cap);
 u8 *ieee80211_ie_build_vht_oper(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 2f189c59ae80..872a05606f06 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -690,6 +690,9 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
   2 + sizeof(struct ieee80211_channel_sw_ie) +
   /* Mesh Channel Switch Parameters */
   2 + sizeof(struct ieee80211_mesh_chansw_params_ie) +
+  /* Channel Switch Wrapper + Wide Bandwidth CSA IE */
+  2 + 2 + sizeof(struct ieee80211_wide_bw_chansw_ie) +
+  2 + sizeof(struct ieee80211_sec_chan_offs_ie) +
   2 + 8 + /* supported rates */
   2 + 3; /* DS params */
tail_len = 2 + (IEEE80211_MAX_SUPP_RATES - 8) +
@@ -736,8 +739,13 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh 
*ifmsh)
rcu_read_lock();
csa = rcu_dereference(ifmsh->csa);
if (csa) {
-   pos = skb_put(skb, 13);
-   memset(pos, 0, 13);
+   enum nl80211_channel_type ct;
+   struct cfg80211_chan_def *chandef;
+   int ie_len = 2 + sizeof(struct ieee80211_channel_sw_ie) +
+2 + sizeof(struct ieee80211_mesh_chansw_params_ie);
+
+   pos = skb_put(skb, ie_len);
+   memset(pos, 0, ie_len);
*pos++ = WLAN_EID_CHANNEL_SWITCH;
*pos++ = 3;
*pos++ = 0x0;
@@ -760,6 +768,39 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh 
*ifmsh)
pos += 2;
put_unaligned_le16(ifmsh->pre_value, pos);
pos += 2;
+
+   switch (csa->settings.chandef.width) {
+   case NL80211_CHAN_WIDTH_40:
+   ie_len = 2 + sizeof(struct ieee80211_sec_chan_offs_ie);
+   pos = skb_put(skb, ie_len);
+   memset(pos, 0, ie_len);
+
+   *pos++ = WLAN_EID_SECONDARY_CHANNEL_OFFSET; /* EID */
+   *pos++ = 1; /* len */
+   ct = cfg80211_get_chandef_type(>settings.chandef);
+   if (ct == NL80211_CHAN_HT40PLUS)
+   *pos++ = IEEE80211_HT_PARAM_CHA_SEC_ABOVE;
+   else
+   *pos++ = IEEE80211_HT_PARAM_CHA_SEC_BELOW;
+   break;
+   case NL80211_CHAN_WIDTH_80:
+   case NL80211_CHAN_WIDTH_80P80:
+   case NL80211_CHAN_WIDTH_160:
+   /* Channel Switch Wrapper + Wide Bandwidth CSA IE */
+   ie_len = 2 + 2 +
+sizeof(struct ieee80211_wide_bw_chansw_ie);
+   pos = skb_put(skb, ie_len);
+   memset(pos, 0, ie_len);
+
+   *pos++ = WLAN_EID_CHANNEL_SWITCH_WRAPPER; /* EID */
+   *pos++ = 5;   /* len */
+   /* put sub IE */
+   chandef = >settings.chandef;
+   pos = ieee80211_ie_build_wide_bw_cs(pos, chandef);
+   break;
+   default:
+   break;
+   }
}
rcu_read_unlock();
 
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index ac9ac6c35594..d2e885cbfdf8 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2414,6 +2414,37 @@ u8 *ieee80211_ie_build_ht

Re: [PATCH 5/7] mac80211: add wide bandwidth channel switch announcement to CSA action frames and mesh beacons

[Simon Wunderlich]

Hi Johannes,

On Friday, May 19, 2017 1:33:37 PM CEST Johannes Berg wrote:
> I've applied patches 1-4 now.
> 
> The subject is a bit long - I was going to change it to
> 
> mac80211: mesh: support sending wide bandwidth CSA
> 
> To support HT and VHT channel switch announcements, both beacons
> and action frames must include the corresponding IEs.
> 
> but:
> > +  2 + 2 + sizeof(struct
> > ieee80211_wide_bw_chansw_ie) +
> > +  2 + sizeof(struct ieee80211_sec_chan_offs_ie) +
> 
> The "2 + 2" should have a comment - no that I'm even really sure that
> you need the wrapper?
> 

right, I'll add a comment. The spec says I need it, and if I understood the 
parsing function correctly it will only search for the wide bw IE when it finds 
the wrapper.

> > -   pos = skb_put(skb, 13);
> > -   memset(pos, 0, 13);
> 
> Removing that is nice - but why do you do this:
> > +   bool have_secondary_chan_offset = false;
> > +   bool have_wide_bandwidth_cs = false;
> > +   int ie_len = 2 + sizeof(struct
> > ieee80211_channel_sw_ie) +
> > +2 + sizeof(struct
> > ieee80211_mesh_chansw_params_ie);
> > +
> > +   switch (csa->settings.chandef.width) {
> > +   case NL80211_CHAN_WIDTH_80:
> > +   case NL80211_CHAN_WIDTH_80P80:
> > +   case NL80211_CHAN_WIDTH_160:
> > +   have_wide_bandwidth_cs = true;
> > +   ie_len += 2 + 2 +
> > + sizeof(struct
> > ieee80211_wide_bw_chansw_ie);
> > +   break;
> > +   case NL80211_CHAN_WIDTH_40:
> > +   have_secondary_chan_offset = true;
> > +   ie_len += 2 + sizeof(struct
> > ieee80211_sec_chan_offs_ie);
> > +   default:
> > +   break;
> > +   }
> > +   pos = skb_put(skb, ie_len);
> > +   memset(pos, 0, ie_len);
> 
> I think having multiple calls to skb_put() would be better.
> 

OK.

>[...]
> 
> and likewise here.
> 
> That'd also be safer in a way.

Understood, I can change it this way.

Thanks a lot for the feedback!
  Simon


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 0/7] extend mac80211 mesh DFS and CSA functionality

[Simon Wunderlich]

On Tuesday, May 16, 2017 1:55:46 PM CEST Bastian Bittorf wrote:
> * Simon Wunderlich <s...@simonwunderlich.de> [16.05.2017 12:24]:
> >  * station A detects a Radar, and informs userspace
> >  * userspace of station A will initiate a CSA, kernel will execute it
> >  (action> 
> > frame, beacons)
> > 
> >  * station B picks up the CSA, and executes it as well
> >  * station B also marks the channel as unavailable
> >  * both station A and station B will send an event to userspace once the
> > 
> > channel switch is complete
> 
> ah, I remember the slides from last battlemesh.
> 
> The "problems" in userspace are: we must maintain a global list
> (so each node) which channel is the next best and we must time
> the final channel switch. IMHO the specs are saying, that we must
> switch within 30 secs after detecting the first radar-pattern.
> Also we must mark/show the new channel somehow for new/crashed/upcoming
> nodes. quite hard...

The timing is not a big problem, since the switch does not happen immediately 
but is performed after a "countdown" which is part of the channel switch 
announcement IEs. The specific rules for the countdown depend on the regulatory 
domain, but it's usually something between 1 and 5 seconds where payload 
traffic 
must not be transmitted (at least for the DFS case).

The bigger problem appears when a node is missing the CSA for whatever reason, 
or is joining the network - worst case, the mesh network can split into clouds 
on different channels. This is where we need the global list, or showing the 
next channel, etc. :)

Cheers,
 Simon


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 0/7] extend mac80211 mesh DFS and CSA functionality

[Simon Wunderlich]

Hi Basti,

On Tuesday, May 16, 2017 11:44:04 AM CEST Bastian Bittorf wrote:
> * Simon Wunderlich <s...@simonwunderlich.de> [16.05.2017 11:35]:
> > This patchset adds DFS and CSA functionality:
> thanks a lot. can you give a brief 'iw event' output when applied:
> for a two-node mesh, where station A detects CSA and station B
> should emit an event...

The idea would be:

 * station A detects a Radar, and informs userspace
 * userspace of station A will initiate a CSA, kernel will execute it (action 
frame, beacons)
 * station B picks up the CSA, and executes it as well
 * station B also marks the channel as unavailable
 * both station A and station B will send an event to userspace once the 
channel switch is complete
> 
> question: there is no userspace part for now, or maybe planned?

I've got some patches for wpa_supplicant here, but they are still quite dirty 
...

> 
> bye, bastian - now it's time for battlemesh.org 8-)

See you at battlemesh :)

Cheers,
 Simon



signature.asc
Description: This is a digitally signed message part.

[PATCH 0/7] extend mac80211 mesh DFS and CSA functionality

[Simon Wunderlich]

This patchset adds DFS and CSA functionality:

 * Mesh CSA is handled similary to IBSS, that means CSA will mark
   channels as unusable, and require userspace to handle actual
   radar signals
 * Add VHT processing for CSA in mesh mode, and some small cleanups

We have been working on this feature set for quite some time internally,
and I believe it is time to propose it for inclusion. I'll handle
any change requests to this patchset. :)

Cheers,
 Simon

Benjamin Berg (4):
  mac80211: Mark channel as unusable if a regulatory MESH CSA is
received
  wireless: Only join DFS channels in mesh mode if userspace flags
support
  wireless: Require HANDLE_DFS flag to switch channel for non-AP mode
  mac80211: Allow following CSA to DFS channels if userspace handles it

Simon Wunderlich (3):
  mac80211: add wide bandwidth channel switch announcement to CSA action
frames and mesh beacons
  mac80211: enable VHT for mesh channel processing
  mac80211: mark as action frame when parsing IEs of CSA action frames

 include/net/cfg80211.h |  4 +++
 net/mac80211/cfg.c |  1 +
 net/mac80211/ieee80211_i.h |  5 +++
 net/mac80211/mesh.c| 89 ++
 net/mac80211/spectmgmt.c   |  5 +++
 net/mac80211/util.c| 40 +
 net/wireless/mesh.c|  8 +
 net/wireless/nl80211.c | 17 -
 8 files changed, 161 insertions(+), 8 deletions(-)

-- 
2.11.0

[PATCH 6/7] mac80211: enable VHT for mesh channel processing

[Simon Wunderlich]

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 net/mac80211/mesh.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 7c6593c0d453..a57af5df7ee4 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -991,12 +991,14 @@ ieee80211_mesh_process_chnswitch(struct 
ieee80211_sub_if_data *sdata,
if (!sband)
return false;
 
-   sta_flags = IEEE80211_STA_DISABLE_VHT;
+   sta_flags = 0;
switch (sdata->vif.bss_conf.chandef.width) {
case NL80211_CHAN_WIDTH_20_NOHT:
sta_flags |= IEEE80211_STA_DISABLE_HT;
case NL80211_CHAN_WIDTH_20:
sta_flags |= IEEE80211_STA_DISABLE_40MHZ;
+   case NL80211_CHAN_WIDTH_40:
+   sta_flags |= IEEE80211_STA_DISABLE_VHT;
break;
default:
break;
-- 
2.11.0

[PATCH 2/7] wireless: Only join DFS channels in mesh mode if userspace flags support

[Simon Wunderlich]

From: Benjamin Berg <benja...@sipsolutions.net>

When joining a mesh network it is not guaranteed that userspace has a
daemon listening for radar events. This is however required for channels
requiring DFS. To flag that userspace will handle radar events, it needs
to set NL80211_ATTR_HANDLE_DFS.

This matches the current mechanism used for IBSS mode.

Signed-off-by: Benjamin Berg <benja...@sipsolutions.net>
Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 include/net/cfg80211.h | 4 
 net/wireless/mesh.c| 8 
 net/wireless/nl80211.c | 3 +++
 3 files changed, 15 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b083e6cbae8c..fa25fbb67cb6 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1441,6 +1441,9 @@ struct mesh_config {
  * @mcast_rate: multicat rate for Mesh Node [6Mbps is the default for 802.11a]
  * @basic_rates: basic rates to use when creating the mesh
  * @beacon_rate: bitrate to be used for beacons
+ * @userspace_handles_dfs: whether user space controls DFS operation, i.e.
+ * changes the channel when a radar is detected. This is required
+ * to operate on DFS channels.
  *
  * These parameters are fixed when the mesh is created.
  */
@@ -1462,6 +1465,7 @@ struct mesh_setup {
int mcast_rate[NUM_NL80211_BANDS];
u32 basic_rates;
struct cfg80211_bitrate_mask beacon_rate;
+   bool userspace_handles_dfs;
 };
 
 /**
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index ec0b1c20ac99..421a6b80ec62 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -174,6 +174,14 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device 
*rdev,
   scan_width);
}
 
+   err = cfg80211_chandef_dfs_required(>wiphy,
+   >chandef,
+   NL80211_IFTYPE_MESH_POINT);
+   if (err < 0)
+   return err;
+   if (err > 0 && !setup->userspace_handles_dfs)
+   return -EINVAL;
+
if (!cfg80211_reg_can_beacon(>wiphy, >chandef,
 NL80211_IFTYPE_MESH_POINT))
return -EINVAL;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c3bc9da30cff..d47e55e3f445 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -9962,6 +9962,9 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct 
genl_info *info)
return err;
}
 
+   setup.userspace_handles_dfs =
+   nla_get_flag(info->attrs[NL80211_ATTR_HANDLE_DFS]);
+
return cfg80211_join_mesh(rdev, dev, , );
 }
 
-- 
2.11.0

[PATCH 7/7] mac80211: mark as action frame when parsing IEs of CSA action frames

[Simon Wunderlich]

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 net/mac80211/mesh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index a57af5df7ee4..ab07974cdcf4 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1308,7 +1308,7 @@ static void mesh_rx_csa_frame(struct 
ieee80211_sub_if_data *sdata,
pos = mgmt->u.action.u.chan_switch.variable;
baselen = offsetof(struct ieee80211_mgmt,
   u.action.u.chan_switch.variable);
-   ieee802_11_parse_elems(pos, len - baselen, false, );
+   ieee802_11_parse_elems(pos, len - baselen, true, );
 
ifmsh->chsw_ttl = elems.mesh_chansw_params_ie->mesh_ttl;
if (!--ifmsh->chsw_ttl)
-- 
2.11.0

[PATCH 4/7] mac80211: Allow following CSA to DFS channels if userspace handles it

[Simon Wunderlich]

From: Benjamin Berg <benja...@sipsolutions.net>

If userspace has flagged support for DFS earlier, then we can follow CSA
to DFS channels. So instead of rejecting the switch, allow it to happen
if the flag has been set during mesh setup.

Signed-off-by: Benjamin Berg <benja...@sipsolutions.net>
Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 net/mac80211/cfg.c |  1 +
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/mesh.c| 15 ---
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 6c2e6060cd54..6980a936a437 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1874,6 +1874,7 @@ static int copy_mesh_setup(struct ieee80211_if_mesh 
*ifmsh,
ifmsh->user_mpm = setup->user_mpm;
ifmsh->mesh_auth_id = setup->auth_id;
ifmsh->security = IEEE80211_MESH_SEC_NONE;
+   ifmsh->userspace_handles_dfs = setup->userspace_handles_dfs;
if (setup->is_authenticated)
ifmsh->security |= IEEE80211_MESH_SEC_AUTHED;
if (setup->is_secure)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 60bed6c69801..c960e4999380 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -643,6 +643,8 @@ struct ieee80211_if_mesh {
unsigned long wrkq_flags;
unsigned long mbss_changed;
 
+   bool userspace_handles_dfs;
+
u8 mesh_id[IEEE80211_MAX_MESH_ID_LEN];
size_t mesh_id_len;
/* Active Path Selection Protocol Identifier */
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 3702e3d9141d..4807a5d77572 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -979,7 +979,9 @@ ieee80211_mesh_process_chnswitch(struct 
ieee80211_sub_if_data *sdata,
params.count = csa_ie.count;
 
if (!cfg80211_chandef_usable(sdata->local->hw.wiphy, ,
-IEEE80211_CHAN_DISABLED)) {
+IEEE80211_CHAN_DISABLED) ||
+   !cfg80211_reg_can_beacon(sdata->local->hw.wiphy, ,
+NL80211_IFTYPE_MESH_POINT)) {
sdata_info(sdata,
   "mesh STA %pM switches to unsupported channel (%d 
MHz, width:%d, CF1/2: %d/%d MHz), aborting\n",
   sdata->vif.addr,
@@ -995,9 +997,16 @@ ieee80211_mesh_process_chnswitch(struct 
ieee80211_sub_if_data *sdata,
NL80211_IFTYPE_MESH_POINT);
if (err < 0)
return false;
-   if (err > 0)
-   /* TODO: DFS not (yet) supported */
+   if (err > 0 && !ifmsh->userspace_handles_dfs) {
+   sdata_info(sdata,
+  "mesh STA %pM switches to channel requiring DFS (%d 
MHz, width:%d, CF1/2: %d/%d MHz), aborting\n",
+  sdata->vif.addr,
+  params.chandef.chan->center_freq,
+  params.chandef.width,
+  params.chandef.center_freq1,
+  params.chandef.center_freq2);
return false;
+   }
 
params.radar_required = err;
 
-- 
2.11.0

[PATCH 3/7] wireless: Require HANDLE_DFS flag to switch channel for non-AP mode

[Simon Wunderlich]

From: Benjamin Berg <benja...@sipsolutions.net>

In the case the channel should be switched to one requiring DFS we need
to make sure that userspace will handle radar events when they happen.
For AP mode this is assumed to be the case, as a manager like hostapd
is required. However IBSS and MESH modes can work without further
userspace assistance, so refuse to use DFS channels unless userspace
vouches that it handles DFS.

NOTE: Userspace should have already flagged support earlier during mesh
or IBSS setup. However, this information is not readily accessible
currently.

Signed-off-by: Benjamin Berg <benja...@sipsolutions.net>
[sw: style cleanups]
Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 net/wireless/nl80211.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d47e55e3f445..9eb59196a378 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7501,6 +7501,7 @@ static int nl80211_channel_switch(struct sk_buff *skb, 
struct genl_info *info)
static struct nlattr *csa_attrs[NL80211_ATTR_MAX+1];
int err;
bool need_new_beacon = false;
+   bool need_handle_dfs_flag = true;
int len, i;
u32 cs_count;
 
@@ -7512,6 +7513,12 @@ static int nl80211_channel_switch(struct sk_buff *skb, 
struct genl_info *info)
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_P2P_GO:
need_new_beacon = true;
+   /* For all modes except AP the handle_dfs flag needs to be
+* supplied to tell the kernel that userspace will handle radar
+* events when they happen. Otherwise a switch to a channel
+* requiring DFS will be rejected.
+*/
+   need_handle_dfs_flag = false;
 
/* useless if AP is not running */
if (!wdev->beacon_interval)
@@ -7634,8 +7641,13 @@ static int nl80211_channel_switch(struct sk_buff *skb, 
struct genl_info *info)
if (err < 0)
return err;
 
-   if (err > 0)
+   if (err > 0) {
params.radar_required = true;
+   if (need_handle_dfs_flag &&
+   !nla_get_flag(info->attrs[NL80211_ATTR_HANDLE_DFS])) {
+   return -EINVAL;
+   }
+   }
 
if (info->attrs[NL80211_ATTR_CH_SWITCH_BLOCK_TX])
params.block_tx = true;
-- 
2.11.0

[PATCH 5/7] mac80211: add wide bandwidth channel switch announcement to CSA action frames and mesh beacons

[Simon Wunderlich]

To support HT and VHT CSA, beacons and action frames must include the
corresponding IEs.

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/mesh.c| 47 --
 net/mac80211/util.c| 40 +++
 3 files changed, 87 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c960e4999380..e3a0b295c5ce 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -2066,6 +2066,8 @@ u8 *ieee80211_ie_build_ht_cap(u8 *pos, struct 
ieee80211_sta_ht_cap *ht_cap,
 u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct ieee80211_sta_ht_cap *ht_cap,
   const struct cfg80211_chan_def *chandef,
   u16 prot_mode, bool rifs_mode);
+u8 *ieee80211_ie_build_wide_bw_cs(u8 *pos,
+ const struct cfg80211_chan_def *chandef);
 u8 *ieee80211_ie_build_vht_cap(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
   u32 cap);
 u8 *ieee80211_ie_build_vht_oper(u8 *pos, struct ieee80211_sta_vht_cap *vht_cap,
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 4807a5d77572..7c6593c0d453 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -690,6 +690,8 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh *ifmsh)
   2 + sizeof(struct ieee80211_channel_sw_ie) +
   /* Mesh Channel Switch Parameters */
   2 + sizeof(struct ieee80211_mesh_chansw_params_ie) +
+  2 + 2 + sizeof(struct ieee80211_wide_bw_chansw_ie) +
+  2 + sizeof(struct ieee80211_sec_chan_offs_ie) +
   2 + 8 + /* supported rates */
   2 + 3; /* DS params */
tail_len = 2 + (IEEE80211_MAX_SUPP_RATES - 8) +
@@ -736,8 +738,27 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh 
*ifmsh)
rcu_read_lock();
csa = rcu_dereference(ifmsh->csa);
if (csa) {
-   pos = skb_put(skb, 13);
-   memset(pos, 0, 13);
+   bool have_secondary_chan_offset = false;
+   bool have_wide_bandwidth_cs = false;
+   int ie_len = 2 + sizeof(struct ieee80211_channel_sw_ie) +
+2 + sizeof(struct ieee80211_mesh_chansw_params_ie);
+
+   switch (csa->settings.chandef.width) {
+   case NL80211_CHAN_WIDTH_80:
+   case NL80211_CHAN_WIDTH_80P80:
+   case NL80211_CHAN_WIDTH_160:
+   have_wide_bandwidth_cs = true;
+   ie_len += 2 + 2 +
+ sizeof(struct ieee80211_wide_bw_chansw_ie);
+   break;
+   case NL80211_CHAN_WIDTH_40:
+   have_secondary_chan_offset = true;
+   ie_len += 2 + sizeof(struct ieee80211_sec_chan_offs_ie);
+   default:
+   break;
+   }
+   pos = skb_put(skb, ie_len);
+   memset(pos, 0, ie_len);
*pos++ = WLAN_EID_CHANNEL_SWITCH;
*pos++ = 3;
*pos++ = 0x0;
@@ -760,6 +781,28 @@ ieee80211_mesh_build_beacon(struct ieee80211_if_mesh 
*ifmsh)
pos += 2;
put_unaligned_le16(ifmsh->pre_value, pos);
pos += 2;
+
+   if (have_secondary_chan_offset) {
+   enum nl80211_channel_type ct;
+
+   *pos++ = WLAN_EID_SECONDARY_CHANNEL_OFFSET; /* EID */
+   *pos++ = 1; /* len */
+   ct = cfg80211_get_chandef_type(>settings.chandef);
+   if (ct == NL80211_CHAN_HT40PLUS)
+   *pos++ = IEEE80211_HT_PARAM_CHA_SEC_ABOVE;
+   else
+   *pos++ = IEEE80211_HT_PARAM_CHA_SEC_BELOW;
+   }
+
+   if (have_wide_bandwidth_cs) {
+   struct cfg80211_chan_def *chandef;
+
+   *pos++ = WLAN_EID_CHANNEL_SWITCH_WRAPPER; /* EID */
+   *pos++ = 5;   /* len */
+   /* put sub IE */
+   chandef = >settings.chandef;
+   pos = ieee80211_ie_build_wide_bw_cs(pos, chandef);
+   }
}
rcu_read_unlock();
 
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index ac9ac6c35594..d2e885cbfdf8 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2414,6 +2414,37 @@ u8 *ieee80211_ie_build_ht_oper(u8 *pos, struct 
ieee80211_sta_ht_cap *ht_cap,
return pos + sizeof(struct ieee80211_ht_operation);
 }
 
+u8 *ieee80211_ie_build_wide_bw_cs(u8 *pos,
+ const struct cfg80211_chan_def *cha

[PATCH 1/7] mac80211: Mark channel as unusable if a regulatory MESH CSA is received

[Simon Wunderlich]

From: Benjamin Berg <benja...@sipsolutions.net>

In the Mesh Channel Switch Parameters (8.4.2.105) the reason is specified
to WLAN_REASON_MESH_CHAN_REGULATORY in the case that a regulatory
limitation was the cause for the switch. This means another station
detected a radar event.

Mark the channel as unusable if this happens.

Signed-off-by: Benjamin Berg <benja...@sipsolutions.net>
[sw: style cleanup, rebase]
Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
---
 net/mac80211/ieee80211_i.h |  1 +
 net/mac80211/mesh.c| 21 +
 net/mac80211/spectmgmt.c   |  5 +
 3 files changed, 27 insertions(+)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index f8f6c148f554..60bed6c69801 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1440,6 +1440,7 @@ struct ieee80211_csa_ie {
u8 count;
u8 ttl;
u16 pre_value;
+   u16 reason_code;
 };
 
 /* Parsed Information Elements */
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 737e1f082b0d..3702e3d9141d 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -916,6 +916,21 @@ void ieee80211_stop_mesh(struct ieee80211_sub_if_data 
*sdata)
ieee80211_configure_filter(local);
 }
 
+static void ieee80211_mesh_csa_mark_radar(struct ieee80211_sub_if_data *sdata)
+{
+   int err;
+
+   /* if the current channel is a DFS channel, mark the channel as
+* unavailable.
+*/
+   err = cfg80211_chandef_dfs_required(sdata->local->hw.wiphy,
+   >vif.bss_conf.chandef,
+   NL80211_IFTYPE_MESH_POINT);
+   if (err > 0)
+   cfg80211_radar_event(sdata->local->hw.wiphy,
+>vif.bss_conf.chandef, GFP_ATOMIC);
+}
+
 static bool
 ieee80211_mesh_process_chnswitch(struct ieee80211_sub_if_data *sdata,
 struct ieee802_11_elems *elems, bool beacon)
@@ -954,6 +969,12 @@ ieee80211_mesh_process_chnswitch(struct 
ieee80211_sub_if_data *sdata,
if (err)
return false;
 
+   /* Mark the channel unavailable if the reason for the switch is
+* regulatory.
+*/
+   if (csa_ie.reason_code == WLAN_REASON_MESH_CHAN_REGULATORY)
+   ieee80211_mesh_csa_mark_radar(sdata);
+
params.chandef = csa_ie.chandef;
params.count = csa_ie.count;
 
diff --git a/net/mac80211/spectmgmt.c b/net/mac80211/spectmgmt.c
index 0782e486fe89..d2ea0017c79d 100644
--- a/net/mac80211/spectmgmt.c
+++ b/net/mac80211/spectmgmt.c
@@ -76,6 +76,11 @@ int ieee80211_parse_ch_switch_ie(struct 
ieee80211_sub_if_data *sdata,
csa_ie->mode = elems->mesh_chansw_params_ie->mesh_flags;
csa_ie->pre_value = le16_to_cpu(
elems->mesh_chansw_params_ie->mesh_pre_value);
+
+   if (elems->mesh_chansw_params_ie->mesh_flags &
+   WLAN_EID_CHAN_SWITCH_PARAM_REASON)
+   csa_ie->reason_code = le16_to_cpu(
+   elems->mesh_chansw_params_ie->mesh_reason);
}
 
new_freq = ieee80211_channel_to_frequency(new_chan_no, new_band);
-- 
2.11.0

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

Hey Kalle,

it seems like there was some discussion here and I wouldn't expect too many 
more opinions ... do you think we can have a decision based on what has been 
discussed here?

I'd be happy to rebase the remaining patches if that is necessary.

Thank you!
 Simon

On Friday, April 21, 2017 2:40:51 PM CEST Mathias Kretschmer wrote:
> Hi all,
> 
> as one of the parties who triggered this patch to be included into the
> main line kernel, we do support Simon's or Ben's point of view.
> 
> Safeguards against accidental misuse are in place. Various patches are
> (have been) already in the open, so if someone wants to be evil, it
> can't be prevented.
> 
> Also, these patches do not make up new channels out of the blue, they
> merely enable channels which are allowed in certain countries under
> specific regulations. To me it seems to be the task of the distribution
> manager (or manufacturer) to ensure that only hardware/kernel features
> are made available that are legal in the given jurisdiction.
> 
> The default behavior is to disable those extra channels. If you are
> building, i.e. First Responder solutions, you need to ensure that those
> guys use the systems incl. the frequency spectrum accordingly.
> 
> To be pragmatic and to avoid out-of-tree code maintenance, my vote would
> be for integration into mainline.
> 
> Best regards,
> 
> Mathias
> 
> 
> 
> 
> Hence, for
> 
> On 21-Apr-17 13:29, Simon Wunderlich wrote:
> > Hi,
> > 
> > On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
> >> [...]
> >> 
> >>>  In my personal view, we have quite a few obstacles which I consider
> >>>  "enough", but would be interesting to hear others opinions ...
> >>> 
> >>> I'll throw in my 2-cents. This patch is treading on very dangerous
> >>> ground.
> >>> I can't speak to other regulatory environments, but at least the FCC is
> >>> cracking down on even the possibility that anyone can operate a WiFi
> >>> device outside the regulatory bounds.
> >> 
> >> These patches make it slightly easier to use the licensed bands, but no
> >> one
> >> can accidentally use them due to the regdb and other constaints in these
> >> patches.
> >> 
> >> So, I don't think these patches offer any fundamental new vulnerability
> >> that should concern the FCC.
> >> 
> >> After all, someone who really wants to do evil can find and apply the
> >> patches without undue effort, and it could easily be that those applying
> >> the patches would then make it even easier to abuse the new channels due
> >> to
> >> laziness or poor coding choices.
> > 
> > I'm with Ben on this one. I also have followed the FCC actions in the past
> > few years, and I've also been involved into that [1,2,3]. There are
> > mailing lists on the topic if you want to get involved. I agree that the
> > topic is important, but I would prefer to not have this patch serving as
> > battleground. :)
> > 
> > The patches proposed here, as Ben says, at least put proper warnings and
> > obstacles which users have to knowingly overcome (or read). It's probably
> > safer than keeping the driver as is and having people apply random patches
> > from the internet which they don't understand or hack the code themselves.
> > Frankly, it's not that hard to enable those channels.
> > 
> > As we have seen by the number of questions and people trying to bring this
> > patch in (Ben and Julian), there is quite some interest for supporting
> > those bands. I've also got a few requests from companies to have it
> > supported (Fraunhofer is one of those).
> > 
> > Cheers,
> > 
> >Simon
> > 
> > [1] https://www.reddit.com/r/wireless/comments/3irr5b/
> > openwrt_vs_fcc_forced_firmware_lockdown/
> > [2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
> > [3] https://libreplanet.org/wiki/Save_WiFi
> 
> ___
> ath10k mailing list
> ath...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k



signature.asc
Description: This is a digitally signed message part.

Re: [Battlemesh] wifibroadcast

[Simon Wunderlich]

Hi Daniel,

On Saturday, April 22, 2017 5:37:03 PM CEST Daniel Golle wrote:
> Hi Simon,
> 
> On Fri, Apr 21, 2017 at 09:55:03PM +0200, Simon Wunderlich wrote:
> > Hi Daniel,
> > 
> > > mac80211: Parse legacy and HT rate in injected frames
> > 
> > Yup, Sven was so kind and helped with this. :D
> > 
> > I'm experimenting with some opportunistic routing ideas ...
> 
> I just realized that the radiotap headers are still not part of the
> UAPI exported by the kernel. How is one supposed to go about this
> issue? Have lots of diverging local copies of ieee80211_radiotap.h?

Propose a patch and send it to linux wireless to move it? :)

> And change all the kernel-specific types (u16 and such) into their
> corresponding userland types (u_int16)...?

Hmm, uapi is full with __u16, __u32, ... see linux/types.h

> 
> I'd be glad if you can share your idea about proper and/or intentional
> use of the kernel's radiotap capabilities...

Well, there is a radiotap parser in the kernel which is quite useful for 
reading (net/wireless/radiotap.c). And there is a radiotap library which also 
does parsing [1] (seems it's based on the kernel implementation), referenced 
from radiotap.org [2]. What is missing (or at least I didn't find it and 
implemented something on my own) is a library/function to build radiotap 
headers (i.e. for writing). There are quite a few things to consider (padding, 
alignment, etc). To make it useful, you would also need to build ieee80211 
headers at the same time ...

I have some rough working C code for all of that (integrated into something 
bigger), not sure if it would be useful to make a library out of it.

I don't have an idea about "proper" usage though. Since Johannes seems to 
maintain most of that radiotap stuff, I'm CC'ing him and linux-wireless. Maybe 
there is already more than what we know. :)

Cheers,
  Simon

[1] https://github.com/radiotap/radiotap-library/blob/master/radiotap.c
[2] http://www.radiotap.org/

signature.asc
Description: This is a digitally signed message part.

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

Hi,

On Tuesday, April 18, 2017 10:09:59 AM CEST Ben Greear wrote:
> [...]
> > In my personal view, we have quite a few obstacles which I consider
> > "enough", but would be interesting to hear others opinions ...
> > 
> > I'll throw in my 2-cents. This patch is treading on very dangerous ground.
> > I can't speak to other regulatory environments, but at least the FCC is
> > cracking down on even the possibility that anyone can operate a WiFi
> > device outside the regulatory bounds.
> These patches make it slightly easier to use the licensed bands, but no one
> can accidentally use them due to the regdb and other constaints in these
> patches.
> 
> So, I don't think these patches offer any fundamental new vulnerability
> that should concern the FCC.
> 
> After all, someone who really wants to do evil can find and apply the
> patches without undue effort, and it could easily be that those applying
> the patches would then make it even easier to abuse the new channels due to
> laziness or poor coding choices.

I'm with Ben on this one. I also have followed the FCC actions in the past few 
years, and I've also been involved into that [1,2,3]. There are mailing lists 
on the topic if you want to get involved. I agree that the topic is important, 
but I would prefer to not have this patch serving as battleground. :)

The patches proposed here, as Ben says, at least put proper warnings and 
obstacles which users have to knowingly overcome (or read). It's probably 
safer than keeping the driver as is and having people apply random patches 
from the internet which they don't understand or hack the code themselves. 
Frankly, it's not that hard to enable those channels.

As we have seen by the number of questions and people trying to bring this 
patch in (Ben and Julian), there is quite some interest for supporting those 
bands. I've also got a few requests from companies to have it supported 
(Fraunhofer is one of those).

Cheers,
  Simon


[1] https://www.reddit.com/r/wireless/comments/3irr5b/
openwrt_vs_fcc_forced_firmware_lockdown/
[2] http://hackaday.com/2016/02/26/fcc-locks-down-router-firmware/
[3] https://libreplanet.org/wiki/Save_WiFi

signature.asc
Description: This is a digitally signed message part.

Re: [v2,1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

Hi,

On Tuesday, April 18, 2017 2:36:54 PM CEST Kalle Valo wrote:
> Simon Wunderlich <s...@simonwunderlich.de> wrote:
> > From: Ben Greear <gree...@candelatech.com>
> > 
> > Many chips support channels in licensed bands. Add support for those,
> > along with a corresponding kernel config option to disable them by
> > default. Note that these channels are not selectable even if the
> > option has been compiled unless the user modifies the regulatory
> > database to explicitly enable the corresponding channels.
> > 
> > NOTE:  These channels must not be used in most regulatory
> > domains unless you have a license from the FCC or similar!
> > 
> > Signed-off-by: Ben Greear <gree...@candelatech.com>
> > [Hide this support behind a Kconfig option]
> > Signed-off-by: Julian Calaby <julian.cal...@gmail.com>
> > [only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed
> > bands, simplify] Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
> > Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
> 
> I am not sure that we should support unlicensed bands in Linux and hence
> hesitant to apply these. My view is that due to regulatory restrictions we
> should not make it too easy to use unlicensed bands. But I'm open for
> discussion, this is a challenging area and my knowledge here is limited.

thanks for your reply! I agree that we should not make it too easy, and 
therefore there are the following "obstacles" which should avoid accidental 
use of license bands:

 * we have the kernel CONFIG option which features a big fat warning
 * regulatory database must be tampered with to enabel the channels. In 
distributions, the regdb also gets signed. There is also the "internal regdb" 
CONFIG option if you compile your own kernel (rarely used, except for 
OpenWRT). In each case, a user must actively add the 4.9 GHz channels into it, 
because they are not included in the default regdb (and this should not 
change).
 * CFG80211_CERTIFICATION_ONUS is also required, which also says "you are on 
your own".

I had a comparison with ath5k, which also allows using those channels without 
at least the special configuration option (there is one enabling even more 
channels). The regdb "obstacle" is in place as well. However, ath5k is for 
very old chips and therefore the threat is limited.

In my personal view, we have quite a few obstacles which I consider "enough", 
but would be interesting to hear others opinions ...

Cheers,
  Simon

signature.asc
Description: This is a digitally signed message part.

Re: [B.A.T.M.A.N.] [batman-adv] Does batman-adv works perfectly?

[Simon Wunderlich]

Hi Xuebing,

I didn't try the QSDK on those devices, mainly because of its poor upstream 
support/community involvement. We tried it on other devices, with "mixed" 
results.

Cheers,
  Simon

On Monday, April 17, 2017 10:19:02 PM CEST Xuebing Wang wrote:
> Hi Sven and Simon,
> 
> Thank you very much for your help. I am curious that did you try QCA-WiFi
> driver for ath9k device (like AR9331) + OpenWRT, instead of trying to
> improve ath9k driver?
> 
> QCA-WiFi driver included in QSDK:
> https://www.codeaurora.org/projects/all-active-projects/qsdk
> 
> Thanks.
> Xuebing Wang
> 
> On Thu, Apr 6, 2017 at 3:13 PM, Sven Eckelmann <s...@narfation.org> wrote:
> > On Donnerstag, 6. April 2017 09:04:50 CEST Simon Wunderlich wrote:
> > > Hello Xuebing,
> > > 
> > > it sounds like you have WiFi driver issues. There are some effects like
> > 
> > key
> > 
> > > cache corruption, deafness, and other effects known for the AR93xx
> > 
> > series.
> > 
> > Correct, completely forgot about the deaf and 0xdeadbeef issues. There
> > were
> > also two workarounds for them [1,2] from Simon.
> > 
> > Kind regards,
> > 
> > Sven
> > 
> > [1] https://patchwork.kernel.org/patch/9433619/
> > [2] https://patchwork.kernel.org/patch/9433621/



signature.asc
Description: This is a digitally signed message part.

[PATCH v2 1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

From: Ben Greear <gree...@candelatech.com>

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Ben Greear <gree...@candelatech.com>
[Hide this support behind a Kconfig option]
Signed-off-by: Julian Calaby <julian.cal...@gmail.com>
[only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, 
simplify]
Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
---
Changes to PATCHv1:
 * fix bug reported by Zefir, and simplify patch more
---
 drivers/net/wireless/ath/ath9k/Kconfig   | 20 
 drivers/net/wireless/ath/ath9k/common-init.c | 15 +++
 drivers/net/wireless/ath/ath9k/hw.h  |  4 
 3 files changed, 39 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f1a626..23b8abf4449a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -116,6 +116,26 @@ config ATH9K_DFS_CERTIFIED
  developed. At this point enabling this option won't do anything
  except increase code size.
 
+config ATH9K_LICENSED_CHAN
+   bool "Support channels in licensed bands"
+   depends on ATH9K && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ This option enables support for licensed channels on such as
+  4.9 GHz (public safety).
+
+ These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+ regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+ your local radio regulator, e.g. the FCC or equivalent. Using these
+ channels without proper authorisation may result in serious legal
+ consequences.
+
+ You will also have to build a regulatory database with these channels
+ enabled to actually use them.
+
+ If you are a distro kernel builder or have any doubt whatsoever about
+ your legal ability to use these channels, say N.
+
 config ATH9K_DYNACK
bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)"
depends on ATH9K
diff --git a/drivers/net/wireless/ath/ath9k/common-init.c 
b/drivers/net/wireless/ath/ath9k/common-init.c
index 8b4f7fdabf58..3d65dce13048 100644
--- a/drivers/net/wireless/ath/ath9k/common-init.c
+++ b/drivers/net/wireless/ath/ath9k/common-init.c
@@ -86,6 +86,21 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] 
= {
CHAN5G(5785, 35), /* Channel 157 */
CHAN5G(5805, 36), /* Channel 161 */
CHAN5G(5825, 37), /* Channel 165 */
+
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+   /* 4.9Ghz channels, public safety channels, license is required in US
+* and most other regulatory domains!
+*/
+   /* 802.11j 4.9 GHz (20 MHz) */
+   CHAN5G(4920, 38), /* channel 184 */
+   CHAN5G(4940, 39), /* channel 188 */
+   CHAN5G(4960, 40), /* channel 192 */
+   CHAN5G(4980, 41), /* channel 196 */
+   /* 802.11j 5.030 - 5.080 GHz (20 MHz) */
+   CHAN5G(5040, 42), /* channel 8 */
+   CHAN5G(5060, 43), /* channel 12 */
+   CHAN5G(5080, 44), /* channel 16 */
+#endif
 };
 
 /* Atheros hardware rate code addition for short premble */
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 9cbca1229bac..2166f644599d 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -73,7 +73,11 @@
 
 #define ATH9K_RSSI_BAD -128
 
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+#define ATH9K_NUM_CHANNELS 45
+#else
 #define ATH9K_NUM_CHANNELS 38
+#endif
 
 /* Register read/write primitives */
 #define REG_WRITE(_ah, _reg, _val) \
-- 
2.11.0

[PATCH v2 3/3] ath9k: add noise floor override option

[Simon Wunderlich]

Introduce a debugfs option to manually override the noise floor,
ignoring the automatically tuned noise floor of the driver/hw.

In my tests with a AR9580 based module and a tx99 5 MHz interferer,
I could tune the noisefloor to -95 dBm or above to allow communication
again. The automatic noise floor calibration sometimes could adapt to
the situation as well, but not reliably and permanently.

I would consider this "feature" experimental and interesting for people
debugging the noise floor calibration or other effects of the hardware.

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
---
 drivers/net/wireless/ath/ath9k/calib.c |  5 ++-
 drivers/net/wireless/ath/ath9k/debug.c | 62 ++
 drivers/net/wireless/ath/ath9k/hw.h|  1 +
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c 
b/drivers/net/wireless/ath/ath9k/calib.c
index 0f71146b781d..13ab6bc46775 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -254,7 +254,9 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
if ((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(chan))
continue;
 
-   if (h)
+   if (ah->nf_override)
+   nfval = ah->nf_override;
+   else if (h)
nfval = h[i].privNF;
else
nfval = default_nf;
@@ -348,6 +350,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
 
return 0;
 }
+EXPORT_SYMBOL(ath9k_hw_loadnf);
 
 
 static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 43930c336987..2e64977a8ab6 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1191,6 +1191,65 @@ static const struct file_operations fops_tpc = {
.llseek = default_llseek,
 };
 
+static ssize_t read_file_nf_override(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   struct ath_hw *ah = sc->sc_ah;
+   char buf[32];
+   unsigned int len;
+
+   if (ah->nf_override == 0)
+   len = sprintf(buf, "off\n");
+   else
+   len = sprintf(buf, "%d\n", ah->nf_override);
+
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_nf_override(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   struct ath_hw *ah = sc->sc_ah;
+   long val;
+   char buf[32];
+   ssize_t len;
+
+   len = min(count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, len))
+   return -EFAULT;
+
+   buf[len] = '\0';
+   if (strncmp("off", buf, 3) == 0)
+   val = 0;
+   else if (kstrtol(buf, 0, ))
+   return -EINVAL;
+
+   if (val > 0)
+   return -EINVAL;
+
+   if (val < -120)
+   return -EINVAL;
+
+   ah->nf_override = val;
+
+   if (ah->curchan)
+   ath9k_hw_loadnf(ah, ah->curchan);
+
+   return count;
+}
+
+static const struct file_operations fops_nf_override = {
+   .read = read_file_nf_override,
+   .write = write_file_nf_override,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 /* Ethtool support for get-stats */
 
 #define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
@@ -1402,5 +1461,8 @@ int ath9k_init_debug(struct ath_hw *ah)
debugfs_create_u16("airtime_flags", S_IRUSR | S_IWUSR,
   sc->debug.debugfs_phy, >airtime_flags);
 
+   debugfs_create_file("nf_override", S_IRUSR | S_IWUSR,
+   sc->debug.debugfs_phy, sc, _nf_override);
+
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 2166f644599d..f06e02d1c342 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -807,6 +807,7 @@ struct ath_hw {
u32 rfkill_gpio;
u32 rfkill_polarity;
u32 ah_flags;
+   s16 nf_override;
 
bool reset_power_on;
bool htc_reset_init;
-- 
2.11.0

[PATCH v2 2/3] ath10k: add support for channels in licensed bands

[Simon Wunderlich]

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

This patch also re-introduces the phy_mode_to_band function to allow
selecting the band in a more clean way.

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
---
Changes to PATCHv1:
 * re-introduce and clean up phy to mode conversion (thanks Sebastian)
---
 drivers/net/wireless/ath/ath10k/Kconfig | 20 +
 drivers/net/wireless/ath/ath10k/core.h  |  4 +++
 drivers/net/wireless/ath/ath10k/mac.c   | 10 +++
 drivers/net/wireless/ath/ath10k/wmi.c   | 53 +++--
 4 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index b4241cf9b7ed..13a23ed33f91 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -53,3 +53,23 @@ config ATH10K_DFS_CERTIFIED
---help---
This option enables DFS support for initiating radiation on
ath10k.
+
+config ATH10K_LICENSED_CHAN
+   bool "Support channels in licensed bands"
+   depends on ATH10K && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ This option enables support for licensed channels on such as
+  4.9 GHz (public safety).
+
+ These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+ regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+ your local radio regulator, e.g. the FCC or equivalent. Using these
+ channels without proper authorisation may result in serious legal
+ consequences.
+
+ You will also have to build a regulatory database with these channels
+ enabled to actually use them.
+
+ If you are a distro kernel builder or have any doubt whatsoever about
+ your legal ability to use these channels, say N.
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index d4b9a0ec1bdc..7674641537b4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,11 @@
 #define WMI_READY_TIMEOUT (5 * HZ)
 #define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
 #define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+#define ATH10K_NUM_CHANS 47
+#else
 #define ATH10K_NUM_CHANS 40
+#endif
 
 /* Antenna noise floor */
 #define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index d60086cdc584..81848e0a3a5e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7669,6 +7669,16 @@ static const struct ieee80211_channel 
ath10k_5ghz_channels[] = {
CHAN5G(161, 5805, 0),
CHAN5G(165, 5825, 0),
CHAN5G(169, 5845, 0),
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+   CHAN5G(184, 4920, 0),
+   CHAN5G(188, 4940, 0),
+   CHAN5G(192, 4960, 0),
+   CHAN5G(196, 4980, 0),
+   CHAN5G(8,   5040, 0),
+   CHAN5G(12,  5060, 0),
+   CHAN5G(16,  5080, 0),
+#endif
+
 };
 
 struct ath10k *ath10k_mac_create(size_t priv_size)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 4e60caec7ab4..d78c778eae4c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2271,6 +2271,41 @@ static bool ath10k_wmi_rx_is_decrypted(struct ath10k *ar,
return true;
 }
 
+static inline enum nl80211_band phy_mode_to_band(u32 phy_mode, u32 channel)
+{
+   enum nl80211_band band;
+
+   switch (phy_mode) {
+   case MODE_11A:
+   case MODE_11NA_HT20:
+   case MODE_11NA_HT40:
+   case MODE_11AC_VHT20:
+   case MODE_11AC_VHT40:
+   case MODE_11AC_VHT80:
+   band = NL80211_BAND_5GHZ;
+   break;
+   case MODE_11B:
+   /* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is
+* set to MODE_11B.
+*/
+   if (channel < 1 || channel > 14) {
+   band = NL80211_BAND_5GHZ;
+   break;
+   }
+   case MODE_11G:
+   case MODE_11GONLY:
+   case MODE_11NG_HT20:
+   case MODE_11NG_HT40:
+   case MODE_11AC_VHT20_2G:
+   case MODE_11AC_VHT40_2G:
+   case MODE_11AC_VHT80_2G:
+   default:
+   band = NL80211_BAND_2GHZ;
+   }
+
+   return band;
+}
+
 int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, st

[PATCH v2 0/3] Channels in licensed bands, noise floor override

[Simon Wunderlich]

This is the revised series for adding channels in licensed bands and the
noise floor override. Thanks for the previous discussions, I've adopted
suggestions from Zefir and Sebastian accordingly and rebased the series.

For more background info, please check the v1 series:

https://www.spinics.net/lists/linux-wireless/msg160266.html

Cheers,
 Simon
 
Ben Greear (1):
  ath9k: Support channels in licensed bands

Simon Wunderlich (2):
  ath10k: add support for channels in licensed bands
  ath9k: add noise floor override option

 drivers/net/wireless/ath/ath10k/Kconfig  | 20 +
 drivers/net/wireless/ath/ath10k/core.h   |  4 ++
 drivers/net/wireless/ath/ath10k/mac.c| 10 +
 drivers/net/wireless/ath/ath10k/wmi.c| 53 +---
 drivers/net/wireless/ath/ath9k/Kconfig   | 20 +
 drivers/net/wireless/ath/ath9k/calib.c   |  5 ++-
 drivers/net/wireless/ath/ath9k/common-init.c | 15 +++
 drivers/net/wireless/ath/ath9k/debug.c   | 62 
 drivers/net/wireless/ath/ath9k/hw.h  |  5 +++
 9 files changed, 177 insertions(+), 17 deletions(-)

-- 
2.11.0

Re: [PATCH 2/3] ath10k: add support for channels in licensed bands

[Simon Wunderlich]

On Friday, March 17, 2017 7:49:55 PM CET Sebastian Gottschall wrote:
> you may quickly realize that this patch cannot be a solution
> example:
> 
> - if (channel >= 1 && channel <= 14) {
> + if (channel >= 1 && channel <= 7) {
>   status->band = NL80211_BAND_2GHZ;
> 
> 
> do you you really want to limit the 2.4 channels for all users?

Hi Sebastian,

you are right, this seems to be too limiting. I'll rework this part.

Cheers,
 Simon


signature.asc
Description: This is a digitally signed message part.

[PATCHv2 1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

From: Ben Greear <gree...@candelatech.com>

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Ben Greear <gree...@candelatech.com>
[Hide this support behind a Kconfig option]
Signed-off-by: Julian Calaby <julian.cal...@gmail.com>
[only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands, 
simplify]
Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
---
Changes to PATCHv1:
 * fix bug reported by Zefir, and simplify patch more
---
 drivers/net/wireless/ath/ath9k/Kconfig   | 20 
 drivers/net/wireless/ath/ath9k/common-init.c | 15 +++
 drivers/net/wireless/ath/ath9k/hw.h  |  4 
 3 files changed, 39 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f1a626..23b8abf4449a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -116,6 +116,26 @@ config ATH9K_DFS_CERTIFIED
  developed. At this point enabling this option won't do anything
  except increase code size.
 
+config ATH9K_LICENSED_CHAN
+   bool "Support channels in licensed bands"
+   depends on ATH9K && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ This option enables support for licensed channels on such as
+  4.9 GHz (public safety).
+
+ These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+ regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+ your local radio regulator, e.g. the FCC or equivalent. Using these
+ channels without proper authorisation may result in serious legal
+ consequences.
+
+ You will also have to build a regulatory database with these channels
+ enabled to actually use them.
+
+ If you are a distro kernel builder or have any doubt whatsoever about
+ your legal ability to use these channels, say N.
+
 config ATH9K_DYNACK
bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)"
depends on ATH9K
diff --git a/drivers/net/wireless/ath/ath9k/common-init.c 
b/drivers/net/wireless/ath/ath9k/common-init.c
index 8b4f7fdabf58..3d65dce13048 100644
--- a/drivers/net/wireless/ath/ath9k/common-init.c
+++ b/drivers/net/wireless/ath/ath9k/common-init.c
@@ -86,6 +86,21 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] 
= {
CHAN5G(5785, 35), /* Channel 157 */
CHAN5G(5805, 36), /* Channel 161 */
CHAN5G(5825, 37), /* Channel 165 */
+
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+   /* 4.9Ghz channels, public safety channels, license is required in US
+* and most other regulatory domains!
+*/
+   /* 802.11j 4.9 GHz (20 MHz) */
+   CHAN5G(4920, 38), /* channel 184 */
+   CHAN5G(4940, 39), /* channel 188 */
+   CHAN5G(4960, 40), /* channel 192 */
+   CHAN5G(4980, 41), /* channel 196 */
+   /* 802.11j 5.030 - 5.080 GHz (20 MHz) */
+   CHAN5G(5040, 42), /* channel 8 */
+   CHAN5G(5060, 43), /* channel 12 */
+   CHAN5G(5080, 44), /* channel 16 */
+#endif
 };
 
 /* Atheros hardware rate code addition for short premble */
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 9cbca1229bac..2166f644599d 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -73,7 +73,11 @@
 
 #define ATH9K_RSSI_BAD -128
 
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+#define ATH9K_NUM_CHANNELS 45
+#else
 #define ATH9K_NUM_CHANNELS 38
+#endif
 
 /* Register read/write primitives */
 #define REG_WRITE(_ah, _reg, _val) \
-- 
2.11.0

Re: [PATCH 1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

On Friday, March 17, 2017 2:40:50 PM CET Zefir Kurtisi wrote:
> On 03/16/2017 04:13 PM, Simon Wunderlich wrote:
> > @@ -126,10 +142,14 @@ int ath9k_cmn_init_channels_rates(struct ath_common
> > *common)> 
> >  {
> >  
> > struct ath_hw *ah = (struct ath_hw *)common->ah;
> > void *channels;
> > 
> > +   int num_5ghz_chan = ARRAY_SIZE(ath9k_5ghz_chantable);
> > +
> > +   if (!IS_ENABLED(CONFIG_ATH9K_LICENSED_CHAN))
> > +   num_5ghz_chan -= ATH9K_NUM_LICENSED_CHANNELS;
> 
> These two lines seem wrong to me, since the extra channels are only added to
> the list if CONFIG_ATH9K_LICENSED_CHAN is defined. If it is not, this cuts
> off the last 7 regular channels, no?

Oh, I think you are right!

I'll revise this part and re-send. Seems I can just get rid of those two lines 
...

Cheers,
Simon

signature.asc
Description: This is a digitally signed message part.

[PATCH 3/3] ath9k: add noise floor override option

[Simon Wunderlich]

Introduce a debugfs option to manually override the noise floor,
ignoring the automatically tuned noise floor of the driver/hw.

In my tests with a AR9580 based module and a tx99 5 MHz interferer,
I could tune the noisefloor to -95 dBm or above to allow communication
again. The automatic noise floor calibration sometimes could adapt to
the situation as well, but not reliably and permanently.

I would consider this "feature" experimental and interesting for people
debugging the noise floor calibration or other effects of the hardware.

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
---
 drivers/net/wireless/ath/ath9k/calib.c |  5 ++-
 drivers/net/wireless/ath/ath9k/debug.c | 62 ++
 drivers/net/wireless/ath/ath9k/hw.h|  1 +
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c 
b/drivers/net/wireless/ath/ath9k/calib.c
index 0f71146b781d..13ab6bc46775 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -254,7 +254,9 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
if ((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(chan))
continue;
 
-   if (h)
+   if (ah->nf_override)
+   nfval = ah->nf_override;
+   else if (h)
nfval = h[i].privNF;
else
nfval = default_nf;
@@ -348,6 +350,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
 
return 0;
 }
+EXPORT_SYMBOL(ath9k_hw_loadnf);
 
 
 static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 43930c336987..2e64977a8ab6 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1191,6 +1191,65 @@ static const struct file_operations fops_tpc = {
.llseek = default_llseek,
 };
 
+static ssize_t read_file_nf_override(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   struct ath_hw *ah = sc->sc_ah;
+   char buf[32];
+   unsigned int len;
+
+   if (ah->nf_override == 0)
+   len = sprintf(buf, "off\n");
+   else
+   len = sprintf(buf, "%d\n", ah->nf_override);
+
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_nf_override(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   struct ath_hw *ah = sc->sc_ah;
+   long val;
+   char buf[32];
+   ssize_t len;
+
+   len = min(count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, len))
+   return -EFAULT;
+
+   buf[len] = '\0';
+   if (strncmp("off", buf, 3) == 0)
+   val = 0;
+   else if (kstrtol(buf, 0, ))
+   return -EINVAL;
+
+   if (val > 0)
+   return -EINVAL;
+
+   if (val < -120)
+   return -EINVAL;
+
+   ah->nf_override = val;
+
+   if (ah->curchan)
+   ath9k_hw_loadnf(ah, ah->curchan);
+
+   return count;
+}
+
+static const struct file_operations fops_nf_override = {
+   .read = read_file_nf_override,
+   .write = write_file_nf_override,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 /* Ethtool support for get-stats */
 
 #define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
@@ -1402,5 +1461,8 @@ int ath9k_init_debug(struct ath_hw *ah)
debugfs_create_u16("airtime_flags", S_IRUSR | S_IWUSR,
   sc->debug.debugfs_phy, >airtime_flags);
 
+   debugfs_create_file("nf_override", S_IRUSR | S_IWUSR,
+   sc->debug.debugfs_phy, sc, _nf_override);
+
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 496e3cd1b509..eba478f052b9 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -803,6 +803,7 @@ struct ath_hw {
u32 rfkill_gpio;
u32 rfkill_polarity;
u32 ah_flags;
+   s16 nf_override;
 
bool reset_power_on;
bool htc_reset_init;
-- 
2.11.0

[PATCH 0/3] Channels in licensed bands, noise floor override

[Simon Wunderlich]

This series contains two patches to enable channels in licensed bands.
Note that there are quite a few requirements to enable those:

 * channels must be explicitly enabled using a licensed band kernel config
   which contains a warning
 * it depends on CFG80211_CERTIFICATION_ONUS
 * users must install a custom regdb, since channels in those licensed
   bands are not included in the standard regdb

The ath9k patch has been proposed two times and rejected, but it also
included some channels on fractional center frequencies, which is not
the case this time (this would require more changes in mac80211 and
also userspace). The other concern about useres accidently tuning
should not be a problem based on the requirements mentioned above. I've
added another patch doing the same thing for ath10k.

Here is some more info on our need/background:

"We are working on a project that involves the use of Public Safety 
channels (4.9x GHz). It is typical 'First Responder' scenario where a 
communication network infrastructure should be set up in catastrophe 
situations.

As this is a controlled and managed network, the organization setting up 
the network has control over the channels that are being used, when and 
for how long and in which geographical area.  The enforcement of such a 
temporary license is a major requirement in this project.

To reduce the cost for the equipment (compared to commercial offerings 
in the 4k USD range), the outdoor devices run on hardened, but standard 
embedded hardware with a recent linux kernel and use Atheros radios.

We believe, that driver support for 4.9GHz channels should be included 
in the Linux kernel, as the driver just exposes specified hardware 
features which are disabled by default via

a) a separate compile-time flag. This is similar to the code used for 
compliance testing.

b) The default CRDA should (and does) not enable such channels.

Those two safeguards seem sufficient to protect against accidental misuse."

The third patch is adding an experimental debug option to override
the noise floor level, which is usually calibrated automatically.

Cheers,
 Simon

Ben Greear (1):
  ath9k: Support channels in licensed bands

Simon Wunderlich (2):
  ath10k: add support for channels in licensed bands
  ath9k: add noise floor override option

 drivers/net/wireless/ath/ath10k/Kconfig  | 20 +
 drivers/net/wireless/ath/ath10k/core.h   |  4 ++
 drivers/net/wireless/ath/ath10k/mac.c|  9 
 drivers/net/wireless/ath/ath10k/wmi.c|  7 +++-
 drivers/net/wireless/ath/ath9k/Kconfig   | 20 +
 drivers/net/wireless/ath/ath9k/ath9k.h   |  2 +-
 drivers/net/wireless/ath/ath9k/calib.c   |  5 ++-
 drivers/net/wireless/ath/ath9k/common-init.c | 35 
 drivers/net/wireless/ath/ath9k/debug.c   | 62 
 drivers/net/wireless/ath/ath9k/hw.h  |  5 ++-
 10 files changed, 155 insertions(+), 14 deletions(-)

-- 
2.11.0

[PATCH 1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

From: Ben Greear <gree...@candelatech.com>

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Ben Greear <gree...@candelatech.com>
[Hide this support behind a Kconfig option]
Signed-off-by: Julian Calaby <julian.cal...@gmail.com>
[only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands]
Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
---
 drivers/net/wireless/ath/ath9k/Kconfig   | 20 
 drivers/net/wireless/ath/ath9k/ath9k.h   |  2 +-
 drivers/net/wireless/ath/ath9k/common-init.c | 35 +---
 drivers/net/wireless/ath/ath9k/hw.h  |  4 ++--
 4 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f1a626..23b8abf4449a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -116,6 +116,26 @@ config ATH9K_DFS_CERTIFIED
  developed. At this point enabling this option won't do anything
  except increase code size.
 
+config ATH9K_LICENSED_CHAN
+   bool "Support channels in licensed bands"
+   depends on ATH9K && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ This option enables support for licensed channels on such as
+  4.9 GHz (public safety).
+
+ These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+ regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+ your local radio regulator, e.g. the FCC or equivalent. Using these
+ channels without proper authorisation may result in serious legal
+ consequences.
+
+ You will also have to build a regulatory database with these channels
+ enabled to actually use them.
+
+ If you are a distro kernel builder or have any doubt whatsoever about
+ your legal ability to use these channels, say N.
+
 config ATH9K_DYNACK
bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)"
depends on ATH9K
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index cf076719c27e..d215c3f968d4 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -996,7 +996,7 @@ struct ath_softc {
struct device *dev;
 
struct survey_info *cur_survey;
-   struct survey_info survey[ATH9K_NUM_CHANNELS];
+   struct survey_info survey[ATH9K_MAX_NUM_CHANNELS];
 
spinlock_t intr_lock;
struct tasklet_struct intr_tq;
diff --git a/drivers/net/wireless/ath/ath9k/common-init.c 
b/drivers/net/wireless/ath/ath9k/common-init.c
index 8b4f7fdabf58..0d632c22bc16 100644
--- a/drivers/net/wireless/ath/ath9k/common-init.c
+++ b/drivers/net/wireless/ath/ath9k/common-init.c
@@ -86,6 +86,22 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] 
= {
CHAN5G(5785, 35), /* Channel 157 */
CHAN5G(5805, 36), /* Channel 161 */
CHAN5G(5825, 37), /* Channel 165 */
+
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+   /* 4.9Ghz channels, public safety channels, license is required in US
+* and most other regulatory domains!
+*/
+   /* 802.11j 4.9 GHz (20 MHz) */
+   CHAN5G(4920, 38), /* channel 184 */
+   CHAN5G(4940, 39), /* channel 188 */
+   CHAN5G(4960, 40), /* channel 192 */
+   CHAN5G(4980, 41), /* channel 196 */
+   /* 802.11j 5.030 - 5.080 GHz (20 MHz) */
+   CHAN5G(5040, 42), /* channel 8 */
+   CHAN5G(5060, 43), /* channel 12 */
+   CHAN5G(5080, 44), /* channel 16 */
+#endif
+#define ATH9K_NUM_LICENSED_CHANNELS 7
 };
 
 /* Atheros hardware rate code addition for short premble */
@@ -126,10 +142,14 @@ int ath9k_cmn_init_channels_rates(struct ath_common 
*common)
 {
struct ath_hw *ah = (struct ath_hw *)common->ah;
void *channels;
+   int num_5ghz_chan = ARRAY_SIZE(ath9k_5ghz_chantable);
+
+   if (!IS_ENABLED(CONFIG_ATH9K_LICENSED_CHAN))
+   num_5ghz_chan -= ATH9K_NUM_LICENSED_CHANNELS;
 
BUILD_BUG_ON(ARRAY_SIZE(ath9k_2ghz_chantable) +
-ARRAY_SIZE(ath9k_5ghz_chantable) !=
-ATH9K_NUM_CHANNELS);
+ARRAY_SIZE(ath9k_5ghz_chantable) >
+ATH9K_MAX_NUM_CHANNELS);
 
if (ah->caps.hw_caps & ATH9K_HW_CAP_2GHZ) {
channels = devm_kzalloc(ah->dev,
@@ -149,

[PATCH 2/3] ath10k: add support for channels in licensed bands

[Simon Wunderlich]

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Simon Wunderlich <s...@simonwunderlich.de>
Signed-off-by: Mathias Kretschmer <mathias.kretsch...@fit.fraunhofer.de>
---
 drivers/net/wireless/ath/ath10k/Kconfig | 20 
 drivers/net/wireless/ath/ath10k/core.h  |  4 
 drivers/net/wireless/ath/ath10k/mac.c   |  9 +
 drivers/net/wireless/ath/ath10k/wmi.c   |  7 +--
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index b4241cf9b7ed..13a23ed33f91 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -53,3 +53,23 @@ config ATH10K_DFS_CERTIFIED
---help---
This option enables DFS support for initiating radiation on
ath10k.
+
+config ATH10K_LICENSED_CHAN
+   bool "Support channels in licensed bands"
+   depends on ATH10K && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ This option enables support for licensed channels on such as
+  4.9 GHz (public safety).
+
+ These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+ regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+ your local radio regulator, e.g. the FCC or equivalent. Using these
+ channels without proper authorisation may result in serious legal
+ consequences.
+
+ You will also have to build a regulatory database with these channels
+ enabled to actually use them.
+
+ If you are a distro kernel builder or have any doubt whatsoever about
+ your legal ability to use these channels, say N.
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index d4b9a0ec1bdc..7674641537b4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,11 @@
 #define WMI_READY_TIMEOUT (5 * HZ)
 #define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
 #define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+#define ATH10K_NUM_CHANS 47
+#else
 #define ATH10K_NUM_CHANS 40
+#endif
 
 /* Antenna noise floor */
 #define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a25f0ec15cf8..23895af0fc63 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7669,6 +7669,15 @@ static const struct ieee80211_channel 
ath10k_5ghz_channels[] = {
CHAN5G(161, 5805, 0),
CHAN5G(165, 5825, 0),
CHAN5G(169, 5845, 0),
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+   CHAN5G(184, 4920, 0),
+   CHAN5G(188, 4940, 0),
+   CHAN5G(192, 4960, 0),
+   CHAN5G(196, 4980, 0),
+   CHAN5G(8,   5040, 0),
+   CHAN5G(12,  5060, 0),
+   CHAN5G(16,  5080, 0),
+#endif
 };
 
 struct ath10k *ath10k_mac_create(size_t priv_size)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 4e60caec7ab4..de7a4fa9d347 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2323,10 +2323,13 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
 * MODE_11B. This means phy_mode is not a reliable source for the band
 * of mgmt rx.
+*
+* On the other hand, channel 8, 12 and 16 are defined in 5GHz as well
+* (5040 - 5080 MHz), therefore apply the override only for channels <=7
 */
-   if (channel >= 1 && channel <= 14) {
+   if (channel >= 1 && channel <= 7) {
status->band = NL80211_BAND_2GHZ;
-   } else if (channel >= 36 && channel <= 169) {
+   } else if (channel >= 8 && channel <= 196) {
status->band = NL80211_BAND_5GHZ;
} else {
/* Shouldn't happen unless list of advertised channels to
-- 
2.11.0

Re: [PATCH] mac80211: Allow multiple listeners for management frames.

[Simon Wunderlich]

On Tuesday, March 14, 2017 3:06:35 PM CET Sven Eckelmann wrote:
> On Dienstag, 14. März 2017 14:51:01 CET Johannes Berg wrote:
> [...]
> 
> > I'm not sure I mentioned it to him, or even remembered it when we were
> > discussing it, but I don't think this patch is a good idea, at least
> > for action frames.
> 
> [...]
> 
> > If you restrict it to non-action I can live with it, but I don't know
> > what you really want to do with this.
> 
> I think he required it only for probe requests.
> 

The idea was to grab probe requests from userspace with a program running next 
to hostapd.

Cheers,
  Simon

signature.asc
Description: This is a digitally signed message part.

Fwd: [Battlemesh] Wireless Battlemesh v10 - Official Announcement

[Simon Wunderlich]

Hi,

this event may be interesting for anyone interested in Wireless Mesh networks!

Please join and spread the word!

Thanks,
  Simon


--  Forwarded Message  --
==
The Wireless Battle Mesh v10
5th - 11th of June 2017, Vienna, Austria
==

The next 'Wireless Battle of the Mesh' will take place from Mon 5th -
Sun 11th of June in the Austrian Museum of Folk Life And Folk Art
(http://www.volkskundemuseum.at) in Vienna.

The event aims to bring together all people from across the globe that
are interested in wireless mesh network technologies and community
networks in general. 6 days full of expert presentations, late night
hacking sessions, measurement campaigns, protocol discussions, and a
whole lotta other meshy things.

So if you are a mesh networking enthusiast, community networking
activist, or have an interest in mesh networks in general, you have to
check this out!

Continuously updated information about the event:
http://battlemesh.org/BattleMeshV10



Location


We are located in the upper floor of very nice historical museum in the
middle of Vienna. One large conference room and two adjacent hacking
areas are at our full disposal there. The whole area offers nice
atmosphere and plenty of room to deploy measurement testbeds. The
adjacent park is a beautiful analog distraction, especially in this time
of the year. The metalab - a very active local hackerspace - is only 5
minutes away.


Accommodation Offering
==

For those of you who are looking for a convenient and low cost
accommodation option: we have made block reservation for 40 people in a
nice hostel 10-15min walking distance from the Museum. The packages
include 6 nights in a four-bed room incl. breakfast - for a mere €100.
Follow the simple instructions below to get one of these hot deals  a
first come first serve scheduler is used.


Registration


The event is *free of charge* and registration is optional - but it
makes the organisation much easier if you tell us in advance that you
plan to come.

Please send a mail to v...@battlemesh.org that looks somewhat like this:



Subject: Registration

Name and/or Nick
Accommodation package: [Yes/No]
T-Shirt Size: [S/M/L/none]
Other details you want to share: (e.g. community, country, URLs, twitter
handle, dietary restrictions, ...)


We will then put your name on the public participants list:
http://battlemesh.org/BattleMeshV10/Participants

And we will answer with payment instructions for the accommodation
package to those that are interested in one.


Travel Scholarships
===

If you want to apply for a travel scholarship (compensating the costs of
a long distance flight to Vienna and back) please explicitly tell us so
in the registration mail. We will then ask you to prepare a short video
message in which you are giving a brief introduction to yourself and
your interests.


Spread the Word
===

Please help us spreading the word by forwarding this announcement to all
lists and people that might be interested. Blogging about it is also
very appreciated, and if you do so, please add a ping-back to the wiki page:

http://battlemesh.org/BattleMeshV10


The Local Infrastructure Core Team
==
Albert Rafetseder (albert.rafetseder at univie.ac.at, key ID 0x90382EC8)
Clemens Hopfer (datacop at wireloss.net, key ID 0x5EBA9D09)
Paul Fuxjaeger (paul.fuxjaeger at gmx.at, key ID 0xB5BB47E7)


Contact
===

* Web: http://battlemesh.org/BattleMeshV10
* Email: http://ml.ninux.org/mailman/listinfo/battlemesh
* IRC: irc.freenode.net #battlemesh
* Twitter: https://twitter.com/battlemesh/

___
Battlemesh mailing list
battlem...@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh

-

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 3/4] ath9k: check for deaf rx path state

[Simon Wunderlich]

Hi Felix,

On Thursday, January 26, 2017 11:26:03 AM CET Felix Fietkau wrote:
> On 2017-01-26 11:15, Simon Wunderlich wrote:
> > Hey,
> > 
> > On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote:
> >> On 2017-01-26 10:50, Simon Wunderlich wrote:
> >> > Hey Felix,
> >> > 
> >> > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote:
> >> >> Various chips occasionally run into a state where the tx path still
> >> >> appears to be working normally, but the rx path is deaf.
> >> >> 
> >> >> There is no known register signature to check for this state
> >> >> explicitly,
> >> >> so use the lack of rx interrupts as an indicator.
> >> >> 
> >> >> This detection is prone to false positives, since a device could also
> >> >> simply be in an environment where there are no frames on the air.
> >> >> However, in this case doing a reset should be harmless since it's
> >> >> obviously not interrupting any real activity. To avoid confusion, call
> >> >> the reset counters in this case "Rx path inactive" instead of
> >> >> something
> >> >> like "Rx path deaf", since it may not be an indication of a real
> >> >> hardware failure.
> >> >> 
> >> >> Signed-off-by: Felix Fietkau <n...@nbd.name>
> >> > 
> >> > As we observed in the field, it may happen that there are still RX
> >> > interrupts triggered, but just a very low number - in which case I
> >> > believe your version wouldn't fix the problem. Therefore we had a
> >> > threshold in our original patch [1].
> >> 
> >> It seems that you were seeing something different than what I was seeing
> >> in my tests. Though it could be that my issues were actually caused by
> >> something else. I had queued up these changes a while back before I
> >> finally found and fixed the IRQ issue.
> > 
> > What we found a good threshold was to check for less than 1 RX interrupt
> > per second, and check the mean average (about) every 30 seconds. If there
> > is any other AP or a station connected, it will not reset the chip, and
> > also there will be no reset on short outages.
> 
> But if there's less than 1 Rx interrupt per second, then my patch should
> also trigger, right?

yes, that function you hooked in is called once a second. However, this will 
likely lead to one reset per second one a "lonely" access point, which could 
create problems for clients connecting the first time, or power-saving clients 
who don't talk much. It's not so unlikely that an AP will not hear anything 
for a full second, and the reset puts it out of operation for some time, too. 
(Not sure how much beacons etc are affected, for example) If you can check 
only every 30 seconds on the average, you would reduce this problem.

Cheers,
 Simon

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 3/4] ath9k: check for deaf rx path state

[Simon Wunderlich]

Hey,

On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote:
> On 2017-01-26 10:50, Simon Wunderlich wrote:
> > Hey Felix,
> > 
> > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote:
> >> Various chips occasionally run into a state where the tx path still
> >> appears to be working normally, but the rx path is deaf.
> >> 
> >> There is no known register signature to check for this state explicitly,
> >> so use the lack of rx interrupts as an indicator.
> >> 
> >> This detection is prone to false positives, since a device could also
> >> simply be in an environment where there are no frames on the air.
> >> However, in this case doing a reset should be harmless since it's
> >> obviously not interrupting any real activity. To avoid confusion, call
> >> the reset counters in this case "Rx path inactive" instead of something
> >> like "Rx path deaf", since it may not be an indication of a real
> >> hardware failure.
> >> 
> >> Signed-off-by: Felix Fietkau <n...@nbd.name>
> > 
> > As we observed in the field, it may happen that there are still RX
> > interrupts triggered, but just a very low number - in which case I
> > believe your version wouldn't fix the problem. Therefore we had a
> > threshold in our original patch [1].
> 
> It seems that you were seeing something different than what I was seeing
> in my tests. Though it could be that my issues were actually caused by
> something else. I had queued up these changes a while back before I
> finally found and fixed the IRQ issue.

What we found a good threshold was to check for less than 1 RX interrupt per 
second, and check the mean average (about) every 30 seconds. If there is any 
other AP or a station connected, it will not reset the chip, and also there 
will be no reset on short outages.

However, Access Points "alone" somewhere without users may still accumulate a 
lot of false resets. Your name choice is better than ours in this regard, lets 
hope users understand that as well. :)

> 
> > We would also appreciate if you can at least briefly mention our work if
> > you resend/rework our stuff.
> 
> Sorry about that. I rebased this from older experimental patches and
> forgot to put in all the relevant context.

Cool, thanks!
Simon


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 3/4] ath9k: check for deaf rx path state

[Simon Wunderlich]

Hey Felix,


On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote:
> Various chips occasionally run into a state where the tx path still
> appears to be working normally, but the rx path is deaf.
> 
> There is no known register signature to check for this state explicitly,
> so use the lack of rx interrupts as an indicator.
> 
> This detection is prone to false positives, since a device could also
> simply be in an environment where there are no frames on the air.
> However, in this case doing a reset should be harmless since it's
> obviously not interrupting any real activity. To avoid confusion, call
> the reset counters in this case "Rx path inactive" instead of something
> like "Rx path deaf", since it may not be an indication of a real
> hardware failure.
> 
> Signed-off-by: Felix Fietkau 

As we observed in the field, it may happen that there are still RX interrupts 
triggered, but just a very low number - in which case I believe your version 
wouldn't fix the problem. Therefore we had a threshold in our original patch 
[1].

We would also appreciate if you can at least briefly mention our work if you 
resend/rework our stuff.

Thank you,
Simon

[1] https://patchwork.kernel.org/patch/9433621/

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

On Wednesday, October 26, 2016 2:58:56 PM CEST Johannes Berg wrote:
> > (NOTE: going off-channel while operating is a different topic).
> 
> Why do you think it's different?
> 
> Seems exactly the same to me, since you come back to the channel and
> start sending without any new checking?

There are two ways to leave a channel:

1.) Leave the operating channel "permanently". Then the ETSI 301 893 says:
"If no radar was detected on an Operating Channel but the RLAN stops operating 
on that channel, then the channel becomes an Available Channel." (4.7.1.4 
Master Devices (c))

Then we can select a new operating channel and re-start the process.

2.) Off-Channel CAC: This is an optional feature. Simply spoken, we keep the 
channel operating, but try to do CAC-checking on a different channel by 
shortly switching to that new channel from time to time. The new channel must 
be checked for a longer time than the standard CAC time (6 minutes for non-
weather radar channels in ETSI).

The main difference is that we keep the current channel as "operating channel" 
and are also required to be able to detect radars with the same probability.

Also note that this feature is not implemented in Linux as far as I know, and 
personally I haven't seen it in the wild yet.

From 4.7.2.3.1:

"Off-Channel CAC is defined as an optional mechanism by which an RLAN device 
monitors channel(s), different from the Operating Channel(s), for the presence 
of radar signals. The Off-Channel CAC may be used in addition to the Channel 
Availability Check defined in clause 4.7.2.2, for identifying Available 
Channels.

Off-Channel CAC is performed by a number of non-continuous checks spread over 
a period in time. This period, which is required to determine the presence of 
radar signals, is defined as the Off-Channel CAC Time.

If no radars have been detected in a channel, then that channel becomes an 
Available Channel."

Cheers,
 Simon

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

On Monday, October 24, 2016 4:38:36 PM CEST Johannes Berg wrote:
> On Mon, 2016-10-24 at 16:36 +0200, Simon Wunderlich wrote:
> > On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote:
> > > On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote:
> > > > Otherwise, it would be pretty much impossible to perform CSAs to
> > > > another DFS channel.
> > > 
> > > I was told that to do that you'd need another NIC that's pre-
> > > CAC'ing another channel.
> > 
> > Here is the portion from ETSI 301 893 v1.8.1 [1] (the most recent one
> > to my knowledege), section 4.7.1.4 which describes operation from
> >
> > master devices (Access Points):
> > [...]
> 
> Yeah I'm pretty sure there are differences in ETSI vs. FCC. Perhaps the
> information I was told about was for FCC. But perhaps it's all just
> completely wrong :)

I think I've found the right specification [1] for FCC. They doesn't state so 
explicitly that it is allowed, but I don't see any remark that this behaviour 
is forbidden, either. The important section is 5.1.1 Master devices in 905462 
D02 UNII DFS Compliance Procedures New Rules v02, which is pretty similar to 
ETSI. They say:


a)
The Master Device will use  DFS  in order to detect  Radar Waveforms with 
received signal strength above the DFS Detection Threshold in the 5250 - 5350
MHz and 5470 - 5725 MHz bands.  DFS is not required in the 5150 - 5250 MHz or 
5725 - 5825 MHz bands. 
b)
Before initiating a network on a Channel, the Master Device will perform a 
Channel Availability Check for a specified time duration (Channel Availability 
Check Time) to ensure that there is no radar system operating on the 
Channel, using DFS described under subsection a) above.
c) The  Master Device initiates a U-NII network by transmitting control 
signals that will enable other U-NII devices to Associate with the Master 
Device.
d)
During normal operation, the Master Device will monitor the Channel
(In-Service Monitoring) to ensure that there is no radar system operating on 
the Channel, using DFS described under a).
e)
If the Master Device has detected a Radar Waveform during In-Service 
Monitoring as described under d), the Operating Channel of the U-
NII network is no longer an Available Channel.  The Master Device will
instruct all associated Client Device(s) to stop transmitting on this 
Channel within the Channel Move Time. The transmissions  during  the 
Channel  Move  Time will be  limited  to  the  Channel  Closing Transmission 
Time. 


Again, no explicit "on installation" here, but there is also nothing saying 
that we can not check/operate on other channels in the meantime. (NOTE: going 
off-channel while operating is a different topic).

Cheers,
 Simon

[1] https://apps.fcc.gov/oetcf/kdb/forms/FTSSearchResultPage.cfm?
switch=P=27155

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

On Monday, October 24, 2016 4:16:02 PM CEST Johannes Berg wrote:
> On Mon, 2016-10-24 at 15:42 +0200, Simon Wunderlich wrote:
> > Otherwise, it would be pretty much impossible to perform CSAs to
> > another DFS channel.
> 
> I was told that to do that you'd need another NIC that's pre-CAC'ing
> another channel.

Here is the portion from ETSI 301 893 v1.8.1 [1] (the most recent one to my 
knowledege), section 4.7.1.4 which describes operation from master devices 
(Access Points):



b) A master device shall only start operations on Available Channels. At  
installation (or reinstallation) of the equipment, the RLAN is assumed to have 
no Available Channels within the band 5 250 MHz to 5 350 MHz and/or 5 470 MHz 
to 5 725 MHz. In such a case, before starting operations on one or more of 
these channels, the master device shall perform either a Channel Availability 
Check or an Off-Channel CAC to ensure that there are no radars operating on 
any selected channel. If no radar has been detected, the channel(s) becomes an
Available Channel(s) and remains as such until a radar signal is detected 
during the In-Service Monitoring.

The Channel Availability Check or the Off-Channel CAC may be performed over a 
wider bandwidth such that all channels within the tested bandwidth become 
Available Channels. 

NOTE 1:The initial Channel Availability Check may be activated manually at 
installation or reinstallation of the equipment.

c) Once the RLAN has started operations on an Available Channel, then that 
channel becomes an Operating Channel. During normal operation, the master 
device shall monitor all Operating Channels (In-Service Monitoring) to ensure 
that there is no radar operating within these channel(s). If no radar was 
detected on an Operating Channel but the RLAN stops operating on that channel, 
then the channel becomes an Available Channel.

NOTE 2:An RLAN is allowed to start transmissions on multiple (adjacent or non-
adjacent) Available Channels. In this case all these channels become Operating 
Channels.



As I interpret this, (b) states explicitly that we can have many available 
channels. We only need to mark channels where we detect a radar. 

BTW, there was also something like a 24h disconnect previously, which was 
removed in 2009 [2].

Cheers,
 Simon

[1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.08.01_60/
en_301893v010801p.pdf
[2] http://www.wlan-skynet.de/docs/rechtliches/etsi_301_893.shtml (german 
only)
> 
> johannes



signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2 2/2] mac80211: passively scan DFS channels if requested

[Simon Wunderlich]

On Monday, October 24, 2016 3:33:24 PM CEST Johannes Berg wrote:
> > > I think it would be reasonable only if the target channel is the
> > > one we are using and we have done CSA. But when scanning non-
> > > operative channels I don't think this could work.
> > 
> > this has been sleeping for a while.. :)
> > Would it make sense to rebase it and resubmit it for inclusion?
> > 
> > Given the previous discussion we could change the logic as:
> > * always passively scan DFS channels that are not usable
> > * always actively scan DFS channels that are usable (i.e. CAC was
> > performed).
> 
> Doesn't that contradict what you said above?
> 
> If we scan, don't we possibly lose our CAC result anyway, since we went
> off-channel? In FCC at least? In ETSI I think we're allowed to do that
> for a bit?

I believe going off-channel was allowed in general - in fact, some routers CAC 
all channels on boot up and then keep the "usable" state forever.

Otherwise, it would be pretty much impossible to perform CSAs to another DFS 
channel.

Cheers,
 Simon

signature.asc
Description: This is a digitally signed message part.

USB WiFi driver for AP mode

[Simon Wunderlich]

Hi,

we are looking for well supported USB WiFi chips/modules with the following 
requirements

 * Be able to support AP mode
 * Support at least 20 concurrent clients (stations)
 * Support multiple SSIDs
 * (preferred, optional: Support 2x2 802.11gn)

We did a survey through the various wiki pages and online information, but 
didn't find anything yet matching those requirements (and only found out 
limitations after trying ...). Any pointers are appreciated. :)

Thanks!
  Simon

signature.asc
Description: This is a digitally signed message part.

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

On Friday, September 23, 2016 10:18:49 PM CEST Pedersen, Thomas wrote:
> On Mon, 2016-09-19 at 08:43 +0200, Simon Wunderlich wrote:
> 
> > On Tuesday, September 13, 2016 5:54:38 PM CEST Pedersen, Thomas wrote:
> > 
> > > On Tue, 2016-09-13 at 14:30 +0200, Simon Wunderlich wrote:
> > > 
> > > 
> > > > [...]
> > > >
> > > >
> > > >
> > > > Thanks for the clarification. We will then stick to the 70's branch
> > > > then.
> > > > 
> > > > Does anyone have pointers for the other questions? :) I would believe
> > > > hat many 
> > > > people would be interested in running AP + Mesh encrypted at the same
> > > > time (at 
> > > > least in the open source community ...).
> > > 
> > > 
> > > 
> > > We're testing encrypted AP + Mesh quite successfully right now with
> > > this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> > > 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> > > Which chip are you using? I can poke the firmware guys for possibility
> > > of getting a 10.4.3.2 firmware build for it.
> > 
> > 
> > Hi Thomas,
> > 
> > thanks for the hint! We are using an older QCA9882. I assume your firmware
> > will 
 not work for this one? If you can poke the firmware guys, that
> > would be great.> 
> > :)
> 
> 
> Hi Simon,
> 
> According to firmware guys the latest code can actually compile down to
> any chipset, so it should simply be a matter of getting builds released.

Hi Thomas,

thats great news, thanks for the heads up!

How are we going to get those builds released? Who can I ask, or do you want 
to take care of that?

Thanks,
 Simon

signature.asc
Description: This is a digitally signed message part.

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

On Tuesday, September 13, 2016 5:54:38 PM CEST Pedersen, Thomas wrote:
> On Tue, 2016-09-13 at 14:30 +0200, Simon Wunderlich wrote:
> 
> > [...]
> >
> > Thanks for the clarification. We will then stick to the 70's branch
> > then.
> > 
> > Does anyone have pointers for the other questions? :) I would believe
> > hat many 
> > people would be interested in running AP + Mesh encrypted at the same
> > time (at 
> > least in the open source community ...).
> 
> 
> We're testing encrypted AP + Mesh quite successfully right now with
> this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> Which chip are you using? I can poke the firmware guys for possibility
> of getting a 10.4.3.2 firmware build for it.

Hi Thomas,

thanks for the hint! We are using an older QCA9882. I assume your firmware will 
not work for this one? If you can poke the firmware guys, that would be great. 
:)

We also want to test the 70.52 firmware version next, maybe there were some 
changes since the .42 we used.

Thanks,
 Simon

signature.asc
Description: This is a digitally signed message part.

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

On Tuesday, September 13, 2016 11:25:21 AM CEST Valo, Kalle wrote:
> Simon Wunderlich <s...@simonwunderlich.de> writes:
> > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> >> Simon Wunderlich <s...@simonwunderlich.de> writes:
> >> > we have done some experiments last week on ath10k, trying to run mesh
> >> > (802.11s) and access point at the same time, both encrypted.
> >> > 
> >> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> >> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which
> >> > gave
> >> > us a working encrypted 802.11s network. However, starting an AP at the
> >> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> >> > 802.11s was running unencrypted.
> >> > 
> >> > We also tested version 10.2.4.97 (from codeaurora), which is now
> >> > default
> >> > in
> >> > LEDE. However, this version apparently doesn't support 11s mesh at all
> >> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> >> > advertises support).
> >> > 
> >> > So here are my questions:
> >> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
> >> >  time?
> >> >  * Do you have any pointers how we could fix this? Could it be fixable
> >> >  in
> >> >  the>
> >> > 
> >> > driver (i.e. not in firmware)?
> >> > 
> >> >  * Does anyone have an idea if 11s will be supported in future
> >> >  versions? I
> >> > 
> >> > didn't find any changelogs, but having 11s mode no longer in the
> >> > service
> >> > map does not make me optimistic.
> >> 
> >> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> >> have no knowledge if anyone even tests that firmware branch with ath10k.
> >> I recommend to only use firmware releases from ath10k-firmware.git as we
> >> use those internally with ath10k. In any case, don't make any
> >> assumptions about future from that firmware branch as it's so old.
> > 
> > This was introduced in December 25th, 2015 after some firmware-related
> > problems. I'm CC'ing Martin Blumenstingl who suggested this change.
> > 
> > Since then, ath10k is pulling firmware from here (unless ct firmware is
> > used):
> > 
> > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain
> > /
> > 10.2.4/firmware-5.bin_10.2.4.97-1
> > 
> > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you
> > say 10.2.4.70.42-2 is more recent? I would have assumed otherwise from
> > the numbers. However, 10.2.4.70 has much more sub-revisions.
> 
> As I said before, I just deliver the firmware files to the community and
> the firmware team creates the actual releases. But my understanding is
> that these are from different branches which are built independently
> (and might have different features, like in this case the mesh support)
> so I would not make any conclusions if any firmware is "better" just
> from the numbers alone.

you are right ... those numbers are not a good pointer. I found this repo, and 
from the checkin dates it looks like 10.2.4.97 is indeed way older (from 
September 2015) than 10.2.4.70.42 (April 2016):

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/log/10.2.4

I would agree that Changelogs would be helpful.

Thanks for the clarification. We will then stick to the 70's branch then.

Does anyone have pointers for the other questions? :) I would believe hat many 
people would be interested in running AP + Mesh encrypted at the same time (at 
least in the open source community ...).

Thanks,
  Simon

signature.asc
Description: This is a digitally signed message part.

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> Simon Wunderlich <s...@simonwunderlich.de> writes:
> > we have done some experiments last week on ath10k, trying to run mesh
> > (802.11s) and access point at the same time, both encrypted.
> > 
> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
> > us a working encrypted 802.11s network. However, starting an AP at the
> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> > 802.11s was running unencrypted.
> > 
> > We also tested version 10.2.4.97 (from codeaurora), which is now default
> > in
> > LEDE. However, this version apparently doesn't support 11s mesh at all
> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> > advertises support).
> > 
> > So here are my questions:
> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
> >  time?
> >  * Do you have any pointers how we could fix this? Could it be fixable in
> >  the> 
> > driver (i.e. not in firmware)?
> > 
> >  * Does anyone have an idea if 11s will be supported in future versions? I
> > 
> > didn't find any changelogs, but having 11s mode no longer in the service
> > map does not make me optimistic.
> 
> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> have no knowledge if anyone even tests that firmware branch with ath10k.
> I recommend to only use firmware releases from ath10k-firmware.git as we
> use those internally with ath10k. In any case, don't make any
> assumptions about future from that firmware branch as it's so old.

This was introduced in December 25th, 2015 after some firmware-related 
problems. I'm CC'ing Martin Blumenstingl who suggested this change.

Since then, ath10k is pulling firmware from here (unless ct firmware is used):

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
10.2.4/firmware-5.bin_10.2.4.97-1

However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say 
10.2.4.70.42-2 is more recent? I would have assumed otherwise from the 
numbers. However, 10.2.4.70 has much more sub-revisions. Is there any document 
describing the revisions? I don't understand it at least from this wiki page 
[1].

Thanks!
Simon

[1] https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware



signature.asc
Description: This is a digitally signed message part.

ath10k mesh + ap + encryption?

[Simon Wunderlich]

Hi,

we have done some experiments last week on ath10k, trying to run mesh 
(802.11s) and access point at the same time, both encrypted. 

We have tested a recent LEDE (reboot-1519-g42f559e) but with 
firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave us a 
working encrypted 802.11s network. However, starting an AP at the same time 
didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was 
running unencrypted.

We also tested version 10.2.4.97 (from codeaurora), which is now default in 
LEDE. However, this version apparently doesn't support 11s mesh at all 
(WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 
advertises support).

So here are my questions:

 * Did anyone succesfully run AP and mesh, both encrypted at the same time?
 * Do you have any pointers how we could fix this? Could it be fixable in the 
driver (i.e. not in firmware)?
 * Does anyone have an idea if 11s will be supported in future versions? I 
didn't find any changelogs, but having 11s mode no longer in the service map 
does not make me optimistic.

Thanks,
 Simon

signature.asc
Description: This is a digitally signed message part.

Debugging RTL8192CU firmware loading on 3.12 powerpc

[Simon Wunderlich]

Hi,

we are trying to integrate a RTL8192CU based WiFi adapter (TP-Link TL-WL822N) 
on a PowerPC based platform running a vendor-supplied/modified 3.12 kernel 
using compat-wireless (I've tried 2016-01-06 and 2016-06-20 versions). While 
the adapter works fine on my Laptop (using Debian 4.6 and 4.7 kernels), it 
seems the firmware loading fails on the PowerPC box. Here is some output from 
the kernel log:

[   36.945820] rtl8192cu: Chip version 0x11
[   37.026208] rtl8192cu: MAC address: ec:08:6b:15:38:0e
[   37.031301] rtl8192cu: Board Type 0
[   37.035074] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[   37.040911] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[   37.049583] usbcore: registered new interface driver rtl8192cu
[...]
[  221.588911] rtl8192cu:_ResetDigitalProcedure1():<0-0> #=> 8051 reset 
failed!.
[  221.637599] rtl8192cu: MAC auto ON okay!
[  221.674610] rtl8192cu: Tx queue select: 0x05
[  233.233554] rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready 
fail!! REG_MCUFWDL:0x00030006 .
[  233.233566] rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not 
ready to run!

The outputs at 221 starts when I enable hostapd with a minimal AP-starting 
configuration.

Do you have any recommendations where the firmware loading problems could come 
from, and where we could start to debug? Any pointers would be appreciated.

Thank you,
  Simon

signature.asc
Description: This is a digitally signed message part.

Fwd: [Battlemesh] Announcing Battlemesh V8 Maribor, Slovenia

[Simon Wunderlich]

I'm sure there are some on this list who will be interested in joining! Please 
spread the word. :)

--  Forwarded Message  --

Subject: [Battlemesh] Announcing Battlemesh V8 Maribor, Slovenia
Date: Monday 23 March 2015, 17:13:18
From: Musti mu...@wlan-si.net
To: Battle of the Mesh Mailing List battlem...@ml.ninux.org

==
   Announcing the Wireless Battle Mesh v8
(3rd - 9th of August 2015, Maribor, Slovenia)
==

The next 'Wireless Battle of the Mesh' will take place from Mon 3rd
till Sun 9th of August at Dom Obrambe Pekre, Maribor, Slovenia. The
event aims to bring together people from across the globe to test the
performance of different routing protocols for ad-hoc networks, like
Babel, B.A.T.M.A.N., BMX, OLSR, and 802.11s. Of course, new protocols
(working on OpenWrt) are always welcome!

It is not required to be active within the mentioned protocols, so if
you are a mesh networking enthusiast, community networking activist, or
have an interest in mesh networks in general, you have to check this out!

Information about the event is gathered at:
http://battlemesh.org/BattleMeshV8


Location


The event takes place at the Dom Obrambe Pekre, Maribor, Slovenia.
It features one large dining hall with an attached smaller hall for
talks, a large lecture theater, several smaller classrooms and an
outdoor auditorium. Expect to find nice community WiFi internet
connection (open.wlan-si.net), video projectors, beverage and snack
supplies and some curious hackers.

Participant Registration and Fee


The event itself is free of charge and open for all, so to register
without hotel and food supply, simply add your name to the participant
table.

http://battlemesh.org/BattleMeshV8/Participants

If you wish low cost accommodation, a special group booking has been
arranged. Payment in advance is required to get the full benefit of
the discount. Therefore, like for the previous event, this year's
edition features an early bird low cost registration program with two
accomodation options:

Hotel Milena:
-

Hotel Milena is a family run hotel under mountain Pohorje for which
the accommodation is offered in a package. Rooms are for 2-4 people,
some rooms have a double bed only. In the case of a large number of
participants some accommodation will be in the neighbouring hotels
as well. Breakfast is included. There is a 15min walk to the
conference venue.

Early bird booking is available for 6 nights (August 3rd to 9th)
for 150 EUR if payment is received before 18th April. The price
goes up to EUR 175,00 for all later payments. These late arrangements
are subject to availability.

Camping:


Camping Kekec is a camping place in the vicinity of Hotel Milena,
all the usual camping amnesties available. No breakfast included.
There are shops nearby, walking to the conference venue takes 18 minutes.

Early bird booking is available for 6 nights (August 3rd to 9th)
for 45 EUR if payment is received before 18th April The price
goes up to EUR 55,00 for all later payments. These late arrangements
are subject to availability.

General:


For any additional information, requests and inquiries get in touch
with the local organization team: battlemeshv8 at wlan-si.net

Of course, this package is not compulsory. You can also find your own
bed and food supply yourself during the event if you wish to do so.

Payment information can be found be found here on the Battlemesh Wiki:

http://battlemesh.org/BattleMeshV8#Participant_Registration_and_Fee

Spread the Word
===

Feel free to spread the word by forwarding this mail to all lists /
people that might be interested in it. Blogging about the event is more
than welcome, and if you do so, please add a ping-back to the wiki page:

http://battlemesh.org/BattleMeshV8

Contact
===

* Web: http://battlemesh.org/BattleMeshV8
* Email: http://ml.ninux.org/mailman/listinfo/battlemesh
* IRC: irc.freenode.net #battlemesh


Kind regards,
Musti
___
Battlemesh mailing list
battlem...@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh
-

signature.asc
Description: This is a digitally signed message part.

Re: Re: [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Simon Wunderlich]

On Tuesday 13 January 2015 11:16:02 Zefir Kurtisi wrote:
 On 01/10/2015 05:26 PM, Simon Wunderlich wrote:
  On Friday 09 January 2015 19:57:37 Arend van Spriel wrote:
  On 01/09/15 17:54, Simon Wunderlich wrote:
  Performing spectral scans on 5 GHz channels may result in PHY errors
  sent by the hardware, even if DFS support is not enabled in the driver
  (e.g. channel scanning or passive monitoring). In that case channels may
  falsely get marked as 'unusable'. To fix that, only process radar PHY
  errors when radar is explicitly enabled in the driver.
  
  Hi Simon,
  
  Not an ath9k expert, but I would think those channels would already be
  marked as unusable, because DFS is disabled in the driver. Or does this
  also affect 5G channels that do not require DFS.
  
  Regards,
  Arend
  
  Hey Arend,
  
  maybe that was not really clear, but this is talking about the DFS state
  unusable. By default, channels are marked in DFS state usable, and
  after the clear channel assessment (which is done e.g. when starting AP
  mode) they are marked as available. As soon as radar is detected they
  are marked as unusable.
  
  These DFS state changes should only happen while there is something
  operating with radar enabled, e.g. AP mode. It should not happen if we
  just have monitor mode or scan for channels. These channels should then
  stay in their previous DFS state (e.g. 'usable'). This was borked and
  this patch tries to fix it. :)
  
  Cheers,
  
   Simon
 
 Hi,
 
 the issue here is that DFS and spectral use the same PHY_ERROR reporting
 mechanism, and the dfs module is still in its initial state prior the
 spectral support was added. With that, feeding the dfs detector with
 PHY_ERROR frames generated by spectral scanner might cause false radar
 detections.

Yup, that's right - we noticed that too, and its written in various places 
that the FFT and DFS hardware logic is shared. :)
 
 I did not dig how the hw-conf.radar_enabled flag is set in monitor mode,
 but if it is same as for master (i.e. set for DFS channels), then it would
 be a better approach to prevent calling ath9k_dfs_process_phyerr()
 altogether from ath9k_rx_skb_preprocess() if not set.

Hm, you mean like - if radar_enabled then dfs_process, otherwise fft_process? 
That would might be more elegant indeed ...

The monitor mode does not have the radar flag enabled, 
cfg80211_chandef_dfs_required() returns 0 in this case.

 
 And while you're at that: slaves do not need to scan for radar, might be
 worth checking if it makes sense to selectively disable radar detection in
 STA mode. I am using attached private OpenWRT patch for that - which still
 would interfere with spectral scanning. Generally, the PHY_ERROR processing
 should be reworked but becomes quite complicated when you take into account
 special use-cases. Think of radar events being treated differently
 depending on whether a master or a monitor detected them (OC-CAC vs. ISM).

I didn't check if that is enforced correctly, but 
cfg80211_chandef_dfs_required() returns if radar is required for the various 
interface types - AP, Adhoc and Mesh have it enabled if its a DFS channel, 
client, monitor, etc don't have it enabled. That gets marked in the sdata-
radar_required, and ieee80211_is_radar_required() checks all interfaces if 
there is any interface which needs radar. So that should have been taken care 
of.

Therefore I think that this is already handled in cfg80211/mac80211 and ath9k 
should not check the iftype at all, but only check the radar_enabled flag.

Off-channel CAC is certainly a different beast, but as far as I know we 
currently don't support that anyway. :)

Cheers,
Simon

signature.asc
Description: This is a digitally signed message part.

Re: Re: [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Simon Wunderlich]

On Friday 09 January 2015 19:57:37 Arend van Spriel wrote:
 On 01/09/15 17:54, Simon Wunderlich wrote:
  Performing spectral scans on 5 GHz channels may result in PHY errors
  sent by the hardware, even if DFS support is not enabled in the driver
  (e.g. channel scanning or passive monitoring). In that case channels may
  falsely get marked as 'unusable'. To fix that, only process radar PHY
  errors when radar is explicitly enabled in the driver.
 
 Hi Simon,
 
 Not an ath9k expert, but I would think those channels would already be
 marked as unusable, because DFS is disabled in the driver. Or does this
 also affect 5G channels that do not require DFS.
 
 Regards,
 Arend

Hey Arend,

maybe that was not really clear, but this is talking about the DFS state 
unusable. By default, channels are marked in DFS state usable, and after 
the clear channel assessment (which is done e.g. when starting AP mode) they 
are marked as available. As soon as radar is detected they are marked as 
unusable.

These DFS state changes should only happen while there is something operating 
with radar enabled, e.g. AP mode. It should not happen if we just have monitor 
mode or scan for channels. These channels should then stay in their previous 
DFS state (e.g. 'usable'). This was borked and this patch tries to fix it. :)

Cheers,
 Simon

signature.asc
Description: This is a digitally signed message part.

[PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

[Simon Wunderlich]

Performing spectral scans on 5 GHz channels may result in PHY errors
sent by the hardware, even if DFS support is not enabled in the driver
(e.g. channel scanning or passive monitoring). In that case channels may
falsely get marked as 'unusable'. To fix that, only process radar PHY
errors when radar is explicitly enabled in the driver.

Cc: Stable sta...@vger.kernel.org [v3.10+]
Reported-by: Mathias Kretschmer mathias.kretsch...@fokus.fraunhofer.de
Signed-off-by: Simon Wunderlich s...@simonwunderlich.de
---
 drivers/net/wireless/ath/ath9k/dfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/dfs.c 
b/drivers/net/wireless/ath/ath9k/dfs.c
index 726271c..3d04905 100644
--- a/drivers/net/wireless/ath/ath9k/dfs.c
+++ b/drivers/net/wireless/ath/ath9k/dfs.c
@@ -152,6 +152,12 @@ void ath9k_dfs_process_phyerr(struct ath_softc *sc, void 
*data,
return;
}
 
+   if (!sc-hw-conf.radar_enabled) {
+   ath_dbg(common, DFS,
+   Error: received radar phyerr while radar was 
disabled\n);
+   return;
+   }
+
datalen = rs-rs_datalen;
if (datalen == 0) {
DFS_STAT_INC(sc, datalen_discards);
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html