[PATCH 0/3] ath10k mesh support

[PATCH 0/3] ath10k mesh support

[Bob Copeland]

Hi,

This patchset implements mesh support for ath10k.  In the end there aren't
too many changes required now that raw mode is upstream.

When the module is loaded with (newly implemented) modparam rawmode=1, it
will enable operating an open mesh STA via something like the following:

    if=wlan0
    meship=10.10.1.10
    ip link set $if down
    ip addr flush $if
    iw dev $if set type mp
    ip link set $if up
    ip addr add $meship/24 dev $if
    iw dev $if set freq 5745 80 5775
    iw dev $if mesh join mesh-vht

Prerequisites:

* latest mac80211-next is needed to ensure that a valid AID is supplied with
stations, without which firmware will crash.

* another mac80211 patch is needed to enable VHT mesh; I'll be sending this
separately to linux-wireless, but you can find it here:

http://bobcopeland.com/kernel/wl/20150816/

Notes:
* Even with 80 MHz VHT enabled, performance is not great: I get about 65 Mbps
OTA.  It looks like we only send 1 frame per a-mpdu; any thoughts on how
to fix would be welcome.

* I'm not crazy about requiring a modparam and advertising mesh interfaces
that are only really usable when the modparam is set, but I'm not sure how
to set rx decap mode on the fly and whether we can do that on a per-vif
basis.

* monitor vdev for getting all multicasts is a bit heavy handed, would
be nice if there was something like ath9k's all mcast filter flag.

Bob Copeland (3):
  ath10k: enable monitor when OTHER_BSS requested
  ath10k: check for encryption before adding MIC_LEN
  ath10k: implement mesh support

 drivers/net/wireless/ath/ath10k/core.c   |  6 ++++++
 drivers/net/wireless/ath/ath10k/htt_tx.c |  3 ++-
 drivers/net/wireless/ath/ath10k/mac.c    | 34 +++++++++++++++++++++++++++-----
 3 files changed, 37 insertions(+), 6 deletions(-)

-- 
2.1.4


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 1/3] ath10k: enable monitor when OTHER_BSS requested

[Bob Copeland]

By default, ath10k restricts received frames to those matching BSSID.
When other BSS frames are requested (e.g. in mesh mode), add an internal
monitor device so those frames are not filtered.

Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 96f4285..5c85896 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1050,6 +1050,7 @@ static bool ath10k_mac_monitor_vdev_is_needed(struct ath10k *ar)
 		return false;
 
 	return ar->monitor ||
+	       ar->filter_flags & FIF_OTHER_BSS ||
 	       test_bit(ATH10K_CAC_RUNNING, &ar->dev_flags);
 }
 
-- 
2.1.4


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 2/3] ath10k: check for encryption before adding MIC_LEN

[Bob Copeland]

In the case of raw mode without nohwcrypt parameter, we
should still make sure the frame is protected before
adding MIC_LEN to avoid skb_under_panic errors.

Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath/ath10k/htt_tx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 704bb5e..e0075cf 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -526,7 +526,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 	     ieee80211_has_protected(hdr->frame_control)) {
 		skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
 	} else if (!skb_cb->htt.nohwcrypt &&
-		   skb_cb->txmode == ATH10K_HW_TXRX_RAW) {
+		   skb_cb->txmode == ATH10K_HW_TXRX_RAW &&
+		   ieee80211_has_protected(hdr->frame_control)) {
 		skb_put(msdu, IEEE80211_CCMP_MIC_LEN);
 	}
 
-- 
2.1.4


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 3/3] ath10k: implement mesh support

[Bob Copeland]

Add support for mesh to ath10k.  We simply use an AP virtual
interface in the firmware in order to enable beaconing
without TSF adoption, and use the raw (802.11) transmit mode.

Due to firmware limitations, the firmware must operate in raw
(non-native 802.11) mode.  As this is configured at firmware init
time, a new "rawmode" modparam is added, and mesh interfaces
are available only if rawmode=true.

Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
 drivers/net/wireless/ath/ath10k/core.c |  6 ++++++
 drivers/net/wireless/ath/ath10k/mac.c  | 33 ++++++++++++++++++++++++++++-----
 2 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 2551067..e176bb4 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -34,16 +34,19 @@ unsigned int ath10k_debug_mask;
 static unsigned int ath10k_cryptmode_param;
 static bool uart_print;
 static bool skip_otp;
+static bool rawmode;
 
 module_param_named(debug_mask, ath10k_debug_mask, uint, 0644);
 module_param_named(cryptmode, ath10k_cryptmode_param, uint, 0644);
 module_param(uart_print, bool, 0644);
 module_param(skip_otp, bool, 0644);
+module_param(rawmode, bool, 0644);
 
 MODULE_PARM_DESC(debug_mask, "Debugging mask");
 MODULE_PARM_DESC(uart_print, "Uart target debugging");
 MODULE_PARM_DESC(skip_otp, "Skip otp failure for calibration in testmode");
 MODULE_PARM_DESC(cryptmode, "Crypto mode: 0-hardware, 1-software");
+MODULE_PARM_DESC(rawmode, "Use raw 802.11 frame datapath");
 
 static const struct ath10k_hw_params ath10k_hw_params_list[] = {
 	{
@@ -1101,6 +1104,9 @@ static int ath10k_core_init_firmware_features(struct ath10k *ar)
 	ar->htt.max_num_amsdu = ATH10K_HTT_MAX_NUM_AMSDU_DEFAULT;
 	ar->htt.max_num_ampdu = ATH10K_HTT_MAX_NUM_AMPDU_DEFAULT;
 
+	if (rawmode)
+		set_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags);
+
 	if (test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) {
 		ar->wmi.rx_decap_mode = ATH10K_HW_TXRX_RAW;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 5c85896..72b0589 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4153,6 +4153,14 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 	case NL80211_IFTYPE_ADHOC:
 		arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
 		break;
+	case NL80211_IFTYPE_MESH_POINT:
+		if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) {
+			ret = -EINVAL;
+			ath10k_warn(ar, "must load driver with rawmode=1 to add mesh interfaces\n");
+			goto err;
+		}
+		arvif->vdev_type = WMI_VDEV_TYPE_AP;
+		break;
 	case NL80211_IFTYPE_AP:
 		arvif->vdev_type = WMI_VDEV_TYPE_AP;
 
@@ -4193,6 +4201,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 	 * become corrupted, e.g. have garbled IEs or out-of-date TIM bitmap.
 	 */
 	if (vif->type == NL80211_IFTYPE_ADHOC ||
+	    vif->type == NL80211_IFTYPE_MESH_POINT ||
 	    vif->type == NL80211_IFTYPE_AP) {
 		arvif->beacon_buf = dma_zalloc_coherent(ar->dev,
 							IEEE80211_MAX_FRAME_LEN,
@@ -4527,6 +4536,13 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
 		if (ret)
 			ath10k_warn(ar, "failed to update beacon template: %d\n",
 				    ret);
+
+		if (ieee80211_vif_is_mesh(vif)) {
+			/* mesh doesn't use SSID but firmware needs it */
+			strncpy(arvif->u.ap.ssid, "mesh",
+				sizeof(arvif->u.ap.ssid));
+			arvif->u.ap.ssid_len = 4;
+		}
 	}
 
 	if (changed & BSS_CHANGED_AP_PROBE_RESP) {
@@ -5266,6 +5282,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
 	} else if (old_state == IEEE80211_STA_AUTH &&
 		   new_state == IEEE80211_STA_ASSOC &&
 		   (vif->type == NL80211_IFTYPE_AP ||
+		    vif->type == NL80211_IFTYPE_MESH_POINT ||
 		    vif->type == NL80211_IFTYPE_ADHOC)) {
 		/*
 		 * New association.
@@ -5301,6 +5318,7 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
 	} else if (old_state == IEEE80211_STA_ASSOC &&
 		    new_state == IEEE80211_STA_AUTH &&
 		    (vif->type == NL80211_IFTYPE_AP ||
+		     vif->type == NL80211_IFTYPE_MESH_POINT ||
 		     vif->type == NL80211_IFTYPE_ADHOC)) {
 		/*
 		 * Disassociation.
@@ -6614,14 +6632,16 @@ static const struct ieee80211_iface_limit ath10k_if_limits[] = {
 	},
 	{
 	.max	= 7,
-	.types	= BIT(NL80211_IFTYPE_AP)
+	.types	= BIT(NL80211_IFTYPE_AP) |
+		  BIT(NL80211_IFTYPE_MESH_POINT)
 	},
 };
 
 static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
 	{
 	.max	= 8,
-	.types	= BIT(NL80211_IFTYPE_AP)
+	.types	= BIT(NL80211_IFTYPE_AP) |
+		  BIT(NL80211_IFTYPE_MESH_POINT)
 	},
 };
 
@@ -6660,7 +6680,8 @@ static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {
 		.max = 2,
 		.types = BIT(NL80211_IFTYPE_AP) |
 			 BIT(NL80211_IFTYPE_P2P_CLIENT) |
-			 BIT(NL80211_IFTYPE_P2P_GO),
+			 BIT(NL80211_IFTYPE_P2P_GO) |
+			 BIT(NL80211_IFTYPE_MESH_POINT)
 	},
 	{
 		.max = 1,
@@ -6680,7 +6701,8 @@ static const struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = {
 	{
 		.max = 1,
 		.types = BIT(NL80211_IFTYPE_AP) |
-			 BIT(NL80211_IFTYPE_P2P_GO),
+			 BIT(NL80211_IFTYPE_P2P_GO) |
+			 BIT(NL80211_IFTYPE_MESH_POINT),
 	},
 	{
 		.max = 1,
@@ -6970,7 +6992,8 @@ int ath10k_mac_register(struct ath10k *ar)
 
 	ar->hw->wiphy->interface_modes =
 		BIT(NL80211_IFTYPE_STATION) |
-		BIT(NL80211_IFTYPE_AP);
+		BIT(NL80211_IFTYPE_AP) |
+		BIT(NL80211_IFTYPE_MESH_POINT);
 
 	ar->hw->wiphy->available_antennas_rx = ar->supp_rx_chainmask;
 	ar->hw->wiphy->available_antennas_tx = ar->supp_tx_chainmask;
-- 
2.1.4


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Unable to set channel above 100 with latest CT Kernel and Firmware

[Harms, Hannes]

Hi,

I am trying to set up the latest Kernel (4.2rc6) and firmware 
(10.1.467-ct-14) form Candela for a 5Ghz network.
Unfortunately I am not able to set channels above 100, although 
regulatory domain is set to DE.
Maybe someone has an advice what is going wrong?

Regards
Hannes

My configuration:

Debian with Kernel 4.2-rc6  form Candela (self compiled)
Firmware: 10.1.467-ct-14

iw reg get
country DE: DFS-ETSI
     (2400 - 2483 @ 40), (N/A, 20), (N/A)
     (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
     (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
     (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
     (57000 - 66000 @ 2160), (N/A, 40), (N/A)

iw list
     Frequencies:
             * 5180 MHz [36] (17.0 dBm)
             * 5200 MHz [40] (17.0 dBm)
             * 5220 MHz [44] (17.0 dBm)
             * 5240 MHz [48] (17.0 dBm)
             * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
               DFS state: usable (for 550 sec)
               DFS CAC time: 60000 ms
             * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
               DFS state: usable (for 550 sec)
               DFS CAC time: 60000 ms
             * 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
               DFS state: usable (for 550 sec)
               DFS CAC time: 60000 ms
             * 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
               DFS state: usable (for 550 sec)
               DFS CAC time: 60000 ms
             * 5500 MHz [100] (disabled)
             * 5520 MHz [104] (disabled)
             * 5540 MHz [108] (disabled)
             * 5560 MHz [112] (disabled)
             * 5580 MHz [116] (disabled)
             * 5600 MHz [120] (disabled)
             * 5620 MHz [124] (disabled)
             * 5640 MHz [128] (disabled)
             * 5660 MHz [132] (disabled)
             * 5680 MHz [136] (disabled)
             * 5700 MHz [140] (disabled)
             * 5720 MHz [144] (disabled)
             * 5745 MHz [149] (disabled)
             * 5765 MHz [153] (disabled)
             * 5785 MHz [157] (disabled)
             * 5805 MHz [161] (disabled)
             * 5825 MHz [165] (disabled)


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 0/3] ath10k mesh support

[Kalle Valo]

Bob Copeland <me@bobcopeland.com> writes:

> This patchset implements mesh support for ath10k.  In the end there aren't
> too many changes required now that raw mode is upstream.
>
> When the module is loaded with (newly implemented) modparam rawmode=1, it
> will enable operating an open mesh STA via something like the following:
>
>     if=wlan0
>     meship=10.10.1.10
>     ip link set $if down
>     ip addr flush $if
>     iw dev $if set type mp
>     ip link set $if up
>     ip addr add $meship/24 dev $if
>     iw dev $if set freq 5745 80 5775
>     iw dev $if mesh join mesh-vht

Can you add this example to patch 3, please? Also mention in patch 3
what firmware version you used to test this. Oh, but I haven't made a
firmware release with RAW_MODE flag set. Need to do that.

> Prerequisites:
>
> * latest mac80211-next is needed to ensure that a valid AID is supplied with
> stations, without which firmware will crash.
>
> * another mac80211 patch is needed to enable VHT mesh; I'll be sending this
> separately to linux-wireless, but you can find it here:
>
> http://bobcopeland.com/kernel/wl/20150816/
>
> Notes:
> * Even with 80 MHz VHT enabled, performance is not great: I get about 65 Mbps
> OTA.  It looks like we only send 1 frame per a-mpdu; any thoughts on how
> to fix would be welcome.
>
> * I'm not crazy about requiring a modparam and advertising mesh interfaces
> that are only really usable when the modparam is set, but I'm not sure how
> to set rx decap mode on the fly and whether we can do that on a per-vif
> basis.

This is good enough for now, but I would prefer that we advertise mesh
support to user space only when the rawmode modparam is set. I guess we
should start building all iface_limits dynamically? But that's future
cleanup.

This looks good to me, I'll just wait that mac80211-next trickles down
to ath.git. But before that can you resend and also CC linux-wireless so
that this gets wider review?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Unable to set channel above 100 with latest CT Kernel and Firmware

[Kalle Valo]

"Harms, Hannes" <hannes.harms@tu-bs.de> writes:

> I am trying to set up the latest Kernel (4.2rc6) and firmware
> (10.1.467-ct-14) form Candela for a 5Ghz network.
> Unfortunately I am not able to set channels above 100, although
> regulatory domain is set to DE.
> Maybe someone has an advice what is going wrong?

Btw, please don't hijack threads (ie. reply to an existing thread and
change subject) as it confuses patchwork[1]. Instead start a new thread.

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

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 0/3] ath10k mesh support

[Bob Copeland]

On Tue, Aug 18, 2015 at 02:50:20PM +0300, Kalle Valo wrote:
> Bob Copeland <me@bobcopeland.com> writes:
> >
> >     if=wlan0
> >     meship=10.10.1.10
> >     ip link set $if down
> >     ip addr flush $if
> >     iw dev $if set type mp
> >     ip link set $if up
> >     ip addr add $meship/24 dev $if
> >     iw dev $if set freq 5745 80 5775
> >     iw dev $if mesh join mesh-vht
> 
> Can you add this example to patch 3, please? Also mention in patch 3
> what firmware version you used to test this. Oh, but I haven't made a
> firmware release with RAW_MODE flag set. Need to do that.

Sure -- yes I guess this patch is also missing a check for the firmware
feature flag (although it works on 10.2.4.70-2 apparently) -- will add
once you do such a release.

> > * I'm not crazy about requiring a modparam and advertising mesh interfaces
> > that are only really usable when the modparam is set, but I'm not sure how
> > to set rx decap mode on the fly and whether we can do that on a per-vif
> > basis.
> 
> This is good enough for now, but I would prefer that we advertise mesh
> support to user space only when the rawmode modparam is set. I guess we
> should start building all iface_limits dynamically? But that's future
> cleanup.

I started down this path originally, but "it's complicated."  There's a
bit of a combinatorial explosion problem since there are already 4
different if_limits with different combinations.  I guess we could
iterate over them and set the bits just before calling into mac80211,
but we'd need to cast away a const or two.

-- 
Bob Copeland %% http://bobcopeland.com/

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Unable to set channel above 100 with latest CT Kernel and Firmware

[Ben Greear]

On 08/18/2015 04:54 AM, Kalle Valo wrote:
> "Harms, Hannes" <hannes.harms@tu-bs.de> writes:
>
>> I am trying to set up the latest Kernel (4.2rc6) and firmware
>> (10.1.467-ct-14) form Candela for a 5Ghz network.
>> Unfortunately I am not able to set channels above 100, although
>> regulatory domain is set to DE.
>> Maybe someone has an advice what is going wrong?

This is unlikely to be a firmware issue, as we routinely run on channel 149.

Have you tried an older kernel to see if it is a regression somewhere in
the stack/driver?

Thanks,
Ben

>
> Btw, please don't hijack threads (ie. reply to an existing thread and
> change subject) as it confuses patchwork[1]. Instead start a new thread.
>
> [1] https://patchwork.kernel.org/patch/7023511/
>

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH 0/3] ath10k mesh support

[Ben Greear]

On 08/18/2015 05:42 AM, Bob Copeland wrote:
> On Tue, Aug 18, 2015 at 02:50:20PM +0300, Kalle Valo wrote:
>> Bob Copeland <me@bobcopeland.com> writes:
>>>
>>>     if=wlan0
>>>     meship=10.10.1.10
>>>     ip link set $if down
>>>     ip addr flush $if
>>>     iw dev $if set type mp
>>>     ip link set $if up
>>>     ip addr add $meship/24 dev $if
>>>     iw dev $if set freq 5745 80 5775
>>>     iw dev $if mesh join mesh-vht
>>
>> Can you add this example to patch 3, please? Also mention in patch 3
>> what firmware version you used to test this. Oh, but I haven't made a
>> firmware release with RAW_MODE flag set. Need to do that.
> 
> Sure -- yes I guess this patch is also missing a check for the firmware
> feature flag (although it works on 10.2.4.70-2 apparently) -- will add
> once you do such a release.
> 
>>> * I'm not crazy about requiring a modparam and advertising mesh interfaces
>>> that are only really usable when the modparam is set, but I'm not sure how
>>> to set rx decap mode on the fly and whether we can do that on a per-vif
>>> basis.
>>
>> This is good enough for now, but I would prefer that we advertise mesh
>> support to user space only when the rawmode modparam is set. I guess we
>> should start building all iface_limits dynamically? But that's future
>> cleanup.
> 
> I started down this path originally, but "it's complicated."  There's a
> bit of a combinatorial explosion problem since there are already 4
> different if_limits with different combinations.  I guess we could
> iterate over them and set the bits just before calling into mac80211,
> but we'd need to cast away a const or two.

I've been carrying a patch in my kernel that makes the limits non-const,
but it was not wanted upstream.

Building the limits dynamically in ath10k, by casting as needed, seems fine to me,
and it would help support additional features that I use in CT firmware,
like module params to tune the number of vdevs, peers, etc.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k