Re: attempting mesh on ath10k

Re: attempting mesh on ath10k

[Freddy Lee]

Hi Bob,

I applied the mesh fix to OpenWRT (r45590 and r62020). It works great
(thanks, Bob!), but with a potentially unforeseen consequence: When an
Archer C7 with these changes is configured to be a 5GHz AP, clients
are unable to connect normally. Experiments show that the client is
registered as a station, but pings don't complete (in many cases, not
even DHCP completes). Tested clients include one commercial phone
(Samsung Galaxy S5 running Lollipop) and another Archer C7.

Without these changes, these same clients can connect to the AP all day long.

Below are sections of verbose output of an access point test script
both without and with the mesh fix.
======= Without ath10k mesh fix =======
+ iw dev wlan0 station dump
Station 30:b5:c2:b2:69:14 (on wlan0)
        inactive time:  1390 ms
        rx bytes:       1106
        rx packets:     3
        tx bytes:       1168
        tx packets:     4
        tx retries:     0
        tx failed:      0
        signal:         -31 dBm
        signal avg:     -32 dBm
        tx bitrate:     6.0 MBit/s
        rx bitrate:     156.0 MBit/s VHT-MCS 5 VHT-NSS 3
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
+ cat /tmp/dhcp.leases
+ dhcp_lease=1434658717 30:b5:c2:b2:69:14 192.168.1.104 * *
+ cut -d  -f 3
+ echo 1434658717 30:b5:c2:b2:69:14 192.168.1.104 bcopeland_test.sh
bcopeland_test.sh
+ ip=192.168.1.104
+ echo Client IP = 192.168.1.104
Client IP = 192.168.1.104
+ ping -c 10 192.168.1.104
PING 192.168.1.104 (192.168.1.104) 56(84) bytes of data.
64 bytes from 192.168.1.104: icmp_req=1 ttl=64 time=1.50 ms
64 bytes from 192.168.1.104: icmp_req=2 ttl=64 time=0.673 ms
64 bytes from 192.168.1.104: icmp_req=3 ttl=64 time=0.888 ms
64 bytes from 192.168.1.104: icmp_req=4 ttl=64 time=0.694 ms
64 bytes from 192.168.1.104: icmp_req=5 ttl=64 time=0.662 ms
64 bytes from 192.168.1.104: icmp_req=6 ttl=64 time=0.670 ms
64 bytes from 192.168.1.104: icmp_req=7 ttl=64 time=0.664 ms
64 bytes from 192.168.1.104: icmp_req=8 ttl=64 time=0.759 ms
64 bytes from 192.168.1.104: icmp_req=9 ttl=64 time=1.29 ms
64 bytes from 192.168.1.104: icmp_req=10 ttl=64 time=0.665 ms

--- 192.168.1.104 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 0.662/0.847/1.508/0.290 ms

======= With ath10k mesh fix =======
+ iw dev wlan0 station dump
Station 30:b5:c2:b2:69:14 (on wlan0)
        inactive time:  2560 ms
        rx bytes:       382
        rx packets:     1
        tx bytes:       444
        tx packets:     2
        tx retries:     0
        tx failed:      0
        signal:         -29 dBm
        signal avg:     -33 dBm
        tx bitrate:     6.0 MBit/s
        rx bitrate:     156.0 MBit/s VHT-MCS 5 VHT-NSS 3
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
+ cat /tmp/dhcp.leases
+ dhcp_lease=
+ cut -d  -f 3
+ echo
+ ip=
+ echo Client IP =
Client IP =
+ ping -c 10
Usage: ping [-LRUbdfnqrvVaAD] [-c count] [-i interval] [-w deadline]
            [-p pattern] [-s packetsize] [-t ttl] [-I interface]
            [-M pmtudisc-hint] [-m mark] [-S sndbuf]
            [-T tstamp-options] [-Q tos] [hop1 ...] destination

Does this work on your end? If not, is there a patch that will fix it?
Please advise.

Thanks in advance,

Freddy Lee

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Mon, Jul 06, 2015 at 02:25:36PM -0700, Freddy Lee wrote:
> Hi Bob,
> 
> I applied the mesh fix to OpenWRT (r45590 and r62020). It works great
> (thanks, Bob!), but with a potentially unforeseen consequence: When an
> Archer C7 with these changes is configured to be a 5GHz AP, clients
> are unable to connect normally. Experiments show that the client is
> registered as a station, but pings don't complete (in many cases, not
> even DHCP completes). Tested clients include one commercial phone
> (Samsung Galaxy S5 running Lollipop) and another Archer C7.
> 
> Without these changes, these same clients can connect to the AP all day long.

Hmm, well, there were definitely some hacks in that version, like
setting the SSID to "A" for all vif types :)

Here's the latest patch-in-progress but I haven't tested it; it also
requires the AID series I sent to l-w last week (and still requires the
filters be disabled).  Once I get an hour to run it through the paces
and also fix the filter issue then I plan to send upstream.

From 2b7ad687190dce02bd3082b6e7145a4e01f9fb11 Mon Sep 17 00:00:00 2001
From: Bob Copeland <me@bobcopeland.com>
Date: Sun, 5 Jul 2015 08:03:28 -0400
Subject: [PATCH] ath10k: implement mesh support

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.

Some basic tests with TCP iperf using 2 ath10k devices and a couple
of ath9k devices:

   2-node VHT mesh:
   4-node linear multihop HT20 (ath9k -> ath10k -> ath9k -> ath10k):

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

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 609ca86..2501c47 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3136,7 +3136,8 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct ieee80211_vif *vif,
 	const struct ieee80211_hdr *hdr = (void *)skb->data;
 	__le16 fc = hdr->frame_control;
 
-	if (!vif || vif->type == NL80211_IFTYPE_MONITOR)
+	if (!vif || vif->type == NL80211_IFTYPE_MONITOR ||
+	    vif->type == NL80211_IFTYPE_MESH_POINT)
 		return ATH10K_HW_TXRX_RAW;
 
 	if (ieee80211_is_mgmt(fc))
@@ -4184,6 +4185,9 @@ 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:
+		arvif->vdev_type = WMI_VDEV_TYPE_AP;
+		break;
 	case NL80211_IFTYPE_AP:
 		arvif->vdev_type = WMI_VDEV_TYPE_AP;
 
@@ -4550,6 +4554,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 (vif->type == NL80211_IFTYPE_MESH_POINT) {
+			/* mesh doesn't use SSID but firmware needs it */
+			strlcpy(arvif->u.ap.ssid, "mesh",
+				sizeof(arvif->u.ap.ssid));
+			arvif->u.ap.ssid_len = 4;
+		}
 	}
 
 	if (changed & BSS_CHANGED_AP_PROBE_RESP) {
@@ -5285,6 +5296,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.
@@ -5320,6 +5332,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.
@@ -6572,6 +6585,9 @@ static const struct ieee80211_iface_limit ath10k_if_limits[] = {
 	{
 	.max	= 7,
 	.types	= BIT(NL80211_IFTYPE_AP)
+#ifdef CONFIG_MAC80211_MESH
+		| BIT(NL80211_IFTYPE_MESH_POINT)
+#endif
 	},
 };
 
@@ -6579,6 +6595,9 @@ static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
 	{
 	.max	= 8,
 	.types	= BIT(NL80211_IFTYPE_AP)
+#ifdef CONFIG_MAC80211_MESH
+		| BIT(NL80211_IFTYPE_MESH_POINT)
+#endif
 	},
 };
 
@@ -6871,6 +6890,7 @@ int ath10k_mac_register(struct ath10k *ar)
 
 	ar->hw->wiphy->interface_modes =
 		BIT(NL80211_IFTYPE_STATION) |
+		BIT(NL80211_IFTYPE_MESH_POINT) |
 		BIT(NL80211_IFTYPE_AP);
 
 	ar->hw->wiphy->available_antennas_rx = ar->supp_rx_chainmask;
-- 
2.1.4


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

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Mon, Jul 06, 2015 at 05:49:21PM -0400, Bob Copeland wrote:
> Some basic tests with TCP iperf using 2 ath10k devices and a couple
> of ath9k devices:
> 
>    2-node VHT mesh:
>    4-node linear multihop HT20 (ath9k -> ath10k -> ath9k -> ath10k):

Obviously these tests are as yet incomplete :)

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

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Mon, Jul 06, 2015 at 05:49:21PM -0400, Bob Copeland wrote:
> Here's the latest patch-in-progress but I haven't tested it; it also
> requires the AID series I sent to l-w last week (and still requires the
> filters be disabled).  Once I get an hour to run it through the paces
> and also fix the filter issue then I plan to send upstream.

Ok, so I've tested it now and I'm having some problems with raw mode
on latest driver.  On top of previously posted patch, I have the following
(not sure if the various checksum changes are really needed, but tried
to have it match last working patch).

It looks like unicast self-protected action frames (peering) works fine, but
broadcast multihop action frames (PREQs) never go over the air.  Does
this sound familiar to anyone?

diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index a60ef7d..6da3952 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -513,7 +513,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 
 	flags1 |= SM((u16)vdev_id, HTT_DATA_TX_DESC_FLAGS1_VDEV_ID);
 	flags1 |= SM((u16)tid, HTT_DATA_TX_DESC_FLAGS1_EXT_TID);
-	if (msdu->ip_summed == CHECKSUM_PARTIAL) {
+	if (msdu->ip_summed == CHECKSUM_PARTIAL &&
+	    skb_cb->txmode != ATH10K_HW_TXRX_RAW) {
 		flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L3_OFFLOAD;
 		flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L4_OFFLOAD;
 	}
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index aa81880..e136e9c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3636,12 +3636,9 @@ static void ath10k_tx(struct ieee80211_hw *hw,
 		ath10k_tx_h_8023(skb);
 		break;
 	case ATH10K_HW_TXRX_RAW:
-		/* FIXME: Packet injection isn't implemented. It should be
-		 * doable with firmware 10.2 on qca988x.
-		 */
-		WARN_ON_ONCE(1);
-		ieee80211_free_txskb(hw, skb);
-		return;
+		ath10k_tx_h_add_p2p_noa_ie(ar, vif, skb);
+		ath10k_tx_h_seq_no(vif, skb);
+		break;
 	}
 
 	if (info->flags & IEEE80211_TX_CTL_TX_OFFCHAN) {
@@ -4053,6 +4050,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 	struct ath10k *ar = hw->priv;
 	struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
 	enum wmi_sta_powersave_param param;
+	enum ath10k_hw_txrx_mode tx_mode = ATH10K_HW_TXRX_NATIVE_WIFI;
 	int ret = 0;
 	u32 value;
 	int bit;
@@ -4109,6 +4107,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 		arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
 		break;
 	case NL80211_IFTYPE_MESH_POINT:
+		tx_mode = ATH10K_HW_TXRX_RAW;
 		arvif->vdev_type = WMI_VDEV_TYPE_AP;
 		break;
 	case NL80211_IFTYPE_AP:
@@ -4193,7 +4192,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
 
 	vdev_param = ar->wmi.vdev_param->tx_encap_type;
 	ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
-					ATH10K_HW_TXRX_NATIVE_WIFI);
+					tx_mode);
 	/* 10.X firmware does not support this VDEV parameter. Do not warn */
 	if (ret && ret != -EOPNOTSUPP) {
 		ath10k_warn(ar, "failed to set vdev %i TX encapsulation: %d\n",
@@ -6969,7 +6968,7 @@ int ath10k_mac_register(struct ath10k *ar)
 		goto err_free;
 	}
 
-	ar->hw->netdev_features = NETIF_F_HW_CSUM;
+	/* ar->hw->netdev_features = NETIF_F_HW_CSUM; */
 
 	if (config_enabled(CPTCFG_ATH10K_DFS_CERTIFIED)) {
 		/* Init ath dfs pattern detector */

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

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

Re: attempting mesh on ath10k

[Bob Copeland]

[trimmed CC to list]

On Sun, Jul 12, 2015 at 10:25:32AM -0400, Bob Copeland wrote:
> It looks like unicast self-protected action frames (peering) works fine, but
> broadcast multihop action frames (PREQs) never go over the air.  Does
> this sound familiar to anyone?

Actually, it's any group addressed frame.  I tried playing with various
values for htt_data_tx_ext_tid as well as just using the tid on the frame
(in mesh group addressed frames still have a qos header with tid=0).

[  662.170000] XXX htt tx completion msdu_id 0 discard 0 no_ack 0 success 1
[  662.470000] XXX tx seq: 264 txmode 0
[  662.470000] XXX htt tx flags0 5 flags1 3136 len 39 id 0 frags_paddr 07337028, msdu_paddr 06513e2e vdev 0 tid 17 freq 0
[  662.480000] XXX htt tx completion msdu_id 0 discard 0 no_ack 0 success 1
[  662.600000] XXX tx seq: 265 txmode 0
[  662.600000] XXX htt tx flags0 5 flags1 2048 len 156 id 0 frags_paddr 07337028, msdu_paddr 06932028 vdev 0 tid 0 freq 0
[  662.620000] XXX tx seq: 266 txmode 0
[  662.620000] XXX htt tx flags0 5 flags1 2048 len 116 id 1 frags_paddr 07337000, msdu_paddr 06921028 vdev 0 tid 0 freq 0
[  662.630000] XXX htt tx completion msdu_id 0 discard 0 no_ack 1 success 0
[  662.640000] XXX htt tx completion msdu_id 1 discard 0 no_ack 1 success 0
[  663.090000] XXX tx seq: 267 txmode 0

The 'success 1' ones are unicast, the success 0 are mcast (in this case
using the frame's tid, otherwise it would be 16.)

Kind of odd that it's not working, since my earlier snapshot worked...
I guess at worst I can bisect compat-wireless versions but that will
take some time.

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

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

Re: attempting mesh on ath10k

[Michal Kazior]

On 13 July 2015 at 03:43, Bob Copeland <me@bobcopeland.com> wrote:
> [trimmed CC to list]
>
> On Sun, Jul 12, 2015 at 10:25:32AM -0400, Bob Copeland wrote:
>> It looks like unicast self-protected action frames (peering) works fine, but
>> broadcast multihop action frames (PREQs) never go over the air.  Does
>> this sound familiar to anyone?
>
> Actually, it's any group addressed frame.  I tried playing with various
> values for htt_data_tx_ext_tid as well as just using the tid on the frame
> (in mesh group addressed frames still have a qos header with tid=0).

Just a quick question: did you try applying the sw crypto/raw mode
patch[1] and using it for mesh?

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


Michał

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote:
> > Actually, it's any group addressed frame.  I tried playing with various
> > values for htt_data_tx_ext_tid as well as just using the tid on the frame
> > (in mesh group addressed frames still have a qos header with tid=0).
> 
> Just a quick question: did you try applying the sw crypto/raw mode
> patch[1] and using it for mesh?
> 
> [1]: https://patchwork.kernel.org/patch/6600721/

Thanks for the pointer, will give it a try.

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

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote:
> On 13 July 2015 at 03:43, Bob Copeland <me@bobcopeland.com> wrote:
> > Actually, it's any group addressed frame.  I tried playing with various
> > values for htt_data_tx_ext_tid as well as just using the tid on the frame
> > (in mesh group addressed frames still have a qos header with tid=0).
> 
> Just a quick question: did you try applying the sw crypto/raw mode
> patch[1] and using it for mesh?
> 
> [1]: https://patchwork.kernel.org/patch/6600721/

I gave this a try and still no luck.  But I have working and non-working
snapshots with only a few months of changes between them so I can bisect
it.

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

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote:
> On 13 July 2015 at 03:43, Bob Copeland <me@bobcopeland.com> wrote:
> > [trimmed CC to list]
> >
> > On Sun, Jul 12, 2015 at 10:25:32AM -0400, Bob Copeland wrote:
> >> It looks like unicast self-protected action frames (peering) works fine, but
> >> broadcast multihop action frames (PREQs) never go over the air.  Does
> >> this sound familiar to anyone?
> >
> > Actually, it's any group addressed frame.  I tried playing with various
> > values for htt_data_tx_ext_tid as well as just using the tid on the frame
> > (in mesh group addressed frames still have a qos header with tid=0).
> 
> Just a quick question: did you try applying the sw crypto/raw mode
> patch[1] and using it for mesh?
> 
> [1]: https://patchwork.kernel.org/patch/6600721/

Ok, I have this working again against the latest driver, including that
patch -- I don't think anything was wrong with it, just didn't have both
raw tx and decap set properly and had some baggage from the original
patch to jettison.

Still a bit WIP but this patchset against openwrt r46584 seems to work
for me:

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

The mac80211 bits (except for VHT) are upstream but openwrt doesn't have
them yet.

(BTW thanks to Cococorp for sending me a few APs to make testing a lot easier!)

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

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

Re: attempting mesh on ath10k

[Bartosz Markowski]

On 27 May 2015 at 13:12, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, May 27, 2015 at 08:51:05AM +0200, Bartosz Markowski wrote:

[...]

>> Are there any plans to push this work upstream?
>
> Hi Bartosz,
>
> Yes, I plan to upstream it.  I'm waiting on a hardware to arrive so I can
> implement VHT mesh with two ath10k chips; once that's in and working I'll
> clean it up and submit.

Great! Thanks for your effort.

-- 
Bartosz

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Wed, May 27, 2015 at 08:51:05AM +0200, Bartosz Markowski wrote:
> On 28 April 2015 at 14:25, Bob Copeland <me@bobcopeland.com> wrote:
> > On Tue, Apr 28, 2015 at 07:47:40AM +0200, Michal Kazior wrote:
> >> > Perhaps there is a BSSID filter enabled or something like that (in mesh
> >> > there's no BSSID, just individual addresses on group addressed frames).
> >>
> >> In that case try creating a monitor interface and bring it up. This
> >> should prompt ath10k to create monitor vdev and subsequently disable
> >> most Rx filters in firmware.
> 
> Are there any plans to push this work upstream?

Hi Bartosz,

Yes, I plan to upstream it.  I'm waiting on a hardware to arrive so I can
implement VHT mesh with two ath10k chips; once that's in and working I'll
clean it up and submit.

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

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

Re: attempting mesh on ath10k

[Bartosz Markowski]

On 28 April 2015 at 14:25, Bob Copeland <me@bobcopeland.com> wrote:
> On Tue, Apr 28, 2015 at 07:47:40AM +0200, Michal Kazior wrote:
>> > Perhaps there is a BSSID filter enabled or something like that (in mesh
>> > there's no BSSID, just individual addresses on group addressed frames).
>>
>> In that case try creating a monitor interface and bring it up. This
>> should prompt ath10k to create monitor vdev and subsequently disable
>> most Rx filters in firmware.

Are there any plans to push this work upstream?

Regards,
Bartosz

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

Re: attempting mesh on ath10k

[Ben Greear]

On 04/28/2015 05:57 AM, Bob Copeland wrote:
> On Tue, Apr 28, 2015 at 08:50:01PM +0800, Chun-Yeow Yeoh wrote:
>> Great works, Bob.
>>
>> Which AP firmware that you have tested with?
>
> That is with:
>
> [   16.670000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
> 0x043202ff) fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128
>
> I think it should work with CT too.  I need to go back and validate
> that, and also make sure I can repro the AID crash on CT.  A confounding
> factor is that every time I build new drivers for OpenWRT, it overwrites
> the firmware again...


If you feel adventurous, and want to apply some of my ath10k patches,
I have a way to dump some of the interesting registers in CT firmware,
including the rx-filter register.

Maybe I can figure out what needs to be twiddled w/out having to add
a monitor device.

I could also potentially add a vdev type or flag for mesh interface,
but that would definitely require driver hacks to enable the new
flag and it would not be compatible with other upstream firmware.

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Tue, Apr 28, 2015 at 08:50:01PM +0800, Chun-Yeow Yeoh wrote:
> Great works, Bob.
> 
> Which AP firmware that you have tested with?

That is with:

[   16.670000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c,
0x043202ff) fw 10.2.4.45 api 4 htt 2.1 wmi 5 cal otp max_sta 128

I think it should work with CT too.  I need to go back and validate
that, and also make sure I can repro the AID crash on CT.  A confounding
factor is that every time I build new drivers for OpenWRT, it overwrites
the firmware again...

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

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

Re: attempting mesh on ath10k

[Yeoh Chun-Yeow]

Great works, Bob.

Which AP firmware that you have tested with?

----
Chun-Yeow

On Tue, Apr 28, 2015 at 8:41 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Sat, Apr 25, 2015 at 01:55:32AM +0800, Chun-Yeow Yeoh wrote:
>> Hi, Bob
>>
>> I have tried converting the "adhoc" mode on the
>> firmware-2.bin_999.999.0.636 as mesh interface.
>>
>> You can find my patches here:
>> https://github.com/chunyeow/ath/commits/mesh
>>
>> But probably too many workaround and won't be able to interoperate
>> with other mesh interface.
>
> Yeah, I think adhoc will not work so well due to TSF sync and the
> distributed beacon algorithm.  So I'm happy that AP approach seems
> viable; of course dedicated mesh vdev type would be nice :)
>
> --
> Bob Copeland %% http://bobcopeland.com/

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Sat, Apr 25, 2015 at 01:55:32AM +0800, Chun-Yeow Yeoh wrote:
> Hi, Bob
> 
> I have tried converting the "adhoc" mode on the
> firmware-2.bin_999.999.0.636 as mesh interface.
> 
> You can find my patches here:
> https://github.com/chunyeow/ath/commits/mesh
> 
> But probably too many workaround and won't be able to interoperate
> with other mesh interface.

Yeah, I think adhoc will not work so well due to TSF sync and the
distributed beacon algorithm.  So I'm happy that AP approach seems
viable; of course dedicated mesh vdev type would be nice :)

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

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Tue, Apr 28, 2015 at 07:47:40AM +0200, Michal Kazior wrote:
> > Perhaps there is a BSSID filter enabled or something like that (in mesh
> > there's no BSSID, just individual addresses on group addressed frames).
> 
> In that case try creating a monitor interface and bring it up. This
> should prompt ath10k to create monitor vdev and subsequently disable
> most Rx filters in firmware.

Indeed, that did the trick, thanks!  So mesh is functional now with raw mode
patch and a few hacks:

root@archer:~# iw dev
phy#0
        Interface mon0
                ifindex 8
                wdev 0x2
                addr e8:de:27:d6:9c:d0
                type monitor
        Interface wlan0
                ifindex 4
                wdev 0x1
                addr e8:de:27:d6:9c:d0
                type mesh point
                channel 149 (5745 MHz), width: 20 MHz (no HT), center1: 5745 MHz

root@archer:~# ping 10.10.10.13
PING 10.10.10.13 (10.10.10.13): 56 data bytes
64 bytes from 10.10.10.13: seq=0 ttl=64 time=10.031 ms
64 bytes from 10.10.10.13: seq=1 ttl=64 time=1.074 ms
64 bytes from 10.10.10.13: seq=2 ttl=64 time=1.074 ms
64 bytes from 10.10.10.13: seq=3 ttl=64 time=1.082 ms
64 bytes from 10.10.10.13: seq=4 ttl=64 time=1.032 ms
64 bytes from 10.10.10.13: seq=5 ttl=64 time=2.905 ms
64 bytes from 10.10.10.13: seq=6 ttl=64 time=1.093 ms
64 bytes from 10.10.10.13: seq=7 ttl=64 time=1.205 ms
64 bytes from 10.10.10.13: seq=8 ttl=64 time=1.057 ms
64 bytes from 10.10.10.13: seq=9 ttl=64 time=1.039 ms
64 bytes from 10.10.10.13: seq=10 ttl=64 time=1.107 ms
64 bytes from 10.10.10.13: seq=11 ttl=64 time=1.040 ms
^C
--- 10.10.10.13 ping statistics ---
12 packets transmitted, 12 packets received, 0% packet loss
round-trip min/avg/max = 1.032/1.978/10.031 ms

root@archer:~# iw dev wlan0 mpath dump
DEST ADDR         NEXT HOP          IFACE       SN      METRIC  QLEN
EXPTIME         DTIM    DRET    FLAGS
00:03:7f:10:4e:2d 00:03:7f:10:4e:2d wlan0       2427    1366    0
0       100     0       0x4

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

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

Re: attempting mesh on ath10k

[Michal Kazior]

On 27 April 2015 at 15:00, Bob Copeland <me@bobcopeland.com> wrote:
> On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote:
>> So, progress!
>>
>> There's still an issue with datapath -- while it looks like we can establish
>> plinks, I couldn't get unicast traffic flowing even if manually setting up
>> mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
>> in the same room to monitor and see where the problem lies.
>
> Now I had a chance to monitor it, and in so doing, rediscovered this patch of
> Chun-Yeow's:
>
> http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html
>
> In fact my broadcasts were truncated and the above change makes the broadcast
> ARPs look correct over the air.  The (non-ath10k) target mesh STA replies with
> broadcast PREQ but that is not received / processed / replied-to by the
> ath10k device.
>
> Perhaps there is a BSSID filter enabled or something like that (in mesh
> there's no BSSID, just individual addresses on group addressed frames).

In that case try creating a monitor interface and bring it up. This
should prompt ath10k to create monitor vdev and subsequently disable
most Rx filters in firmware.


Michał

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

Re: attempting mesh on ath10k

[Bob Copeland]

On Sun, Apr 26, 2015 at 10:15:52AM -0400, Bob Copeland wrote:
> So, progress!
> 
> There's still an issue with datapath -- while it looks like we can establish
> plinks, I couldn't get unicast traffic flowing even if manually setting up
> mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
> in the same room to monitor and see where the problem lies.

Now I had a chance to monitor it, and in so doing, rediscovered this patch of
Chun-Yeow's:

http://lists.infradead.org/pipermail/ath10k/2014-September/003206.html

In fact my broadcasts were truncated and the above change makes the broadcast
ARPs look correct over the air.  The (non-ath10k) target mesh STA replies with
broadcast PREQ but that is not received / processed / replied-to by the
ath10k device.

Perhaps there is a BSSID filter enabled or something like that (in mesh
there's no BSSID, just individual addresses on group addressed frames).

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

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

Re: attempting mesh on ath10k

[Ben Greear]

On 04/26/2015 07:15 AM, Bob Copeland wrote:
> On Fri, Apr 24, 2015 at 06:38:02PM -0700, Ben Greear wrote:
>> I have IBSS support working, and at least non-encrypted raw transmit
>> can work in my firmware, though raw tx requires Michal's RFC patch
>> he posted some time ago.
>
> (Michal's RFC patch is in my repo.)
>
> So I got a bit further.  I was still getting a crash with CT firmware, but,
> suspecting that we pass something invalid in assoc message for mesh, I forced
> peer->aid = 1 and then it no longer crashes shortly after adding the first
> peer on either CT or QCA firmware.

Please send me the crash dump...and let me know the firmware version if the
info is not in the dump.

Thanks,
Ben

>
> I pushed that hack into my repo for now -- I think we want to rethink how and
> when AIDs are generated in mesh.
>
> # iw dev wlan0 station dump
> Station 00:03:7f:10:4e:2d (on wlan0)
>          inactive time:  400 ms
>          rx bytes:       34019
>          rx packets:     959
>          tx bytes:       152
>          tx packets:     3
>          tx retries:     0
>          tx failed:      0
>          signal:         -27 dBm
>          signal avg:     -26 dBm
>          tx bitrate:     6.0 MBit/s
>          rx bitrate:     9.0 MBit/s
>          mesh llid:      220
>          mesh plid:      455
>          mesh plink:     ESTAB
>          mesh local PS mode:     ACTIVE
>          mesh peer PS mode:      ACTIVE
>          mesh non-peer PS mode:  ACTIVE
>          authorized:     yes
>          authenticated:  yes
>          preamble:       long
>          WMM/WME:        yes
>          MFP:            no
>          TDLS peer:      no
>
> So, progress!
>
> There's still an issue with datapath -- while it looks like we can establish
> plinks, I couldn't get unicast traffic flowing even if manually setting up
> mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
> in the same room to monitor and see where the problem lies.
>


-- 
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: attempting mesh on ath10k

[Bob Copeland]

On Fri, Apr 24, 2015 at 06:38:02PM -0700, Ben Greear wrote:
> I have IBSS support working, and at least non-encrypted raw transmit
> can work in my firmware, though raw tx requires Michal's RFC patch
> he posted some time ago.

(Michal's RFC patch is in my repo.)

So I got a bit further.  I was still getting a crash with CT firmware, but,
suspecting that we pass something invalid in assoc message for mesh, I forced
peer->aid = 1 and then it no longer crashes shortly after adding the first
peer on either CT or QCA firmware.

I pushed that hack into my repo for now -- I think we want to rethink how and
when AIDs are generated in mesh.

# iw dev wlan0 station dump
Station 00:03:7f:10:4e:2d (on wlan0)
        inactive time:  400 ms
        rx bytes:       34019
        rx packets:     959
        tx bytes:       152
        tx packets:     3
        tx retries:     0
        tx failed:      0
        signal:         -27 dBm
        signal avg:     -26 dBm
        tx bitrate:     6.0 MBit/s
        rx bitrate:     9.0 MBit/s
        mesh llid:      220
        mesh plid:      455
        mesh plink:     ESTAB
        mesh local PS mode:     ACTIVE
        mesh peer PS mode:      ACTIVE
        mesh non-peer PS mode:  ACTIVE
        authorized:     yes
        authenticated:  yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no

So, progress!

There's still an issue with datapath -- while it looks like we can establish
plinks, I couldn't get unicast traffic flowing even if manually setting up
mpaths and arp table entries.  I haven't yet got all of my 5 ghz capable gear
in the same room to monitor and see where the problem lies.

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

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

Re: attempting mesh on ath10k

[Ben Greear]

On 04/24/2015 10:55 AM, Yeoh Chun-Yeow wrote:
> Hi, Bob
>
> I have tried converting the "adhoc" mode on the
> firmware-2.bin_999.999.0.636 as mesh interface.
>
> You can find my patches here:
> https://github.com/chunyeow/ath/commits/mesh
>
> But probably too many workaround and won't be able to interoperate
> with other mesh interface.
>
> I have also found out the immediate crashes when peer mesh STA is
> added by the firmware if using "AP" mode.
> https://github.com/chunyeow/ath/commit/c09a7ef83a5912d1965756b9ce4c9a22ae1dcf08
>
> Hi, Ben
>
> You have any updates on CT firmware to support the mesh mode?
>
> Please advice. Thanks

I have IBSS support working, and at least non-encrypted raw transmit
can work in my firmware, though raw tx requires Michal's RFC patch
he posted some time ago.

Don't know about mesh, but if you can crash my firmware, please send
me the debug info and I'll see if I can figure out why.

I am not sure raw tx with encryption is possible...and at the least,
it is probably not something I'll attempt to do for fun anytime soon.

Thanks,
Ben


>
> ---
> Chun-Yeow
>
>
> On Fri, Apr 24, 2015 at 8:50 PM, Bob Copeland <me@bobcopeland.com> wrote:
>> Hi all,
>>
>> I have played around a little bit with the raw mode patches trying to
>> get mesh working on ath10k.  I've hacked the driver slightly to use an
>> AP vif in the firmware in "mesh" mode, which seems to produce proper looking
>> beacons over the air.
>>
>> However, when I bring up a second mesh node, the ath10k device crashes
>> upon trying to send the first mesh peering action frame.  Here's what
>> dmesg looks like:
>>
>> [   43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140
>> [   44.310000] XXX trying to create peer 00:03:7f:10:4e:2d
>> [   44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d
>> [   44.320000] XXX sending WMI cmd 36892
>> [   44.320000] XXX sending WMI cmd nowait 36892
>> [   44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d
>> [   44.330000] XXX peer 00:03:7f:10:4e:2d added
>> [   44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new)
>> [   44.350000] XXX sending WMI cmd 36896
>> [   44.350000] XXX sending WMI cmd nowait 36896
>> [   44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented
>> [   44.360000] mesh: sending popen to 00:03:7f:10:4e:2d
>> [   44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0
>> [   44.390000] XXX sending WMI cmd 36905
>> [   44.390000] XXX sending WMI cmd nowait 36905
>> [   44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c
>> [   44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a
>> [   44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
>> [   44.420000] ath10k_pci 0000:01:00.0: firmware register dump:
>> [   44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31
>> [   44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00
>> [   44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078
>> [   44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
>> [   44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000
>> [   44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677
>> [   44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE
>> [   44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04
>> [   44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04
>> [   44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8
>> [   44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688
>> [   44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44
>> [   44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
>> [   44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350
>> [   44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001
>>
>> My hacky compat-wireless snapshot is over here, any suggestions on what to
>> try next to debug further are welcome:
>>
>>      https://github.com/bcopeland/ath10k-mesh
>>
>> [Also I tried skipping the mgmt tx datapath and use normal datapath,
>> as seen in the final patch, but that doesn't change things, it crashes
>> either way.]
>>
>> Maybe I'm not setting up peers correctly or something like that?
>>
>> --
>> Bob Copeland %% http://bobcopeland.com/
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


-- 
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: attempting mesh on ath10k

[Yeoh Chun-Yeow]

Hi, Bob

I have tried converting the "adhoc" mode on the
firmware-2.bin_999.999.0.636 as mesh interface.

You can find my patches here:
https://github.com/chunyeow/ath/commits/mesh

But probably too many workaround and won't be able to interoperate
with other mesh interface.

I have also found out the immediate crashes when peer mesh STA is
added by the firmware if using "AP" mode.
https://github.com/chunyeow/ath/commit/c09a7ef83a5912d1965756b9ce4c9a22ae1dcf08

Hi, Ben

You have any updates on CT firmware to support the mesh mode?

Please advice. Thanks

---
Chun-Yeow


On Fri, Apr 24, 2015 at 8:50 PM, Bob Copeland <me@bobcopeland.com> wrote:
> Hi all,
>
> I have played around a little bit with the raw mode patches trying to
> get mesh working on ath10k.  I've hacked the driver slightly to use an
> AP vif in the firmware in "mesh" mode, which seems to produce proper looking
> beacons over the air.
>
> However, when I bring up a second mesh node, the ath10k device crashes
> upon trying to send the first mesh peering action frame.  Here's what
> dmesg looks like:
>
> [   43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140
> [   44.310000] XXX trying to create peer 00:03:7f:10:4e:2d
> [   44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d
> [   44.320000] XXX sending WMI cmd 36892
> [   44.320000] XXX sending WMI cmd nowait 36892
> [   44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d
> [   44.330000] XXX peer 00:03:7f:10:4e:2d added
> [   44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new)
> [   44.350000] XXX sending WMI cmd 36896
> [   44.350000] XXX sending WMI cmd nowait 36896
> [   44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented
> [   44.360000] mesh: sending popen to 00:03:7f:10:4e:2d
> [   44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0
> [   44.390000] XXX sending WMI cmd 36905
> [   44.390000] XXX sending WMI cmd nowait 36905
> [   44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c
> [   44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a
> [   44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
> [   44.420000] ath10k_pci 0000:01:00.0: firmware register dump:
> [   44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31
> [   44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00
> [   44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078
> [   44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
> [   44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000
> [   44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677
> [   44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE
> [   44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04
> [   44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04
> [   44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8
> [   44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688
> [   44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44
> [   44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
> [   44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350
> [   44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001
>
> My hacky compat-wireless snapshot is over here, any suggestions on what to
> try next to debug further are welcome:
>
>     https://github.com/bcopeland/ath10k-mesh
>
> [Also I tried skipping the mgmt tx datapath and use normal datapath,
> as seen in the final patch, but that doesn't change things, it crashes
> either way.]
>
> Maybe I'm not setting up peers correctly or something like that?
>
> --
> Bob Copeland %% http://bobcopeland.com/
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

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

attempting mesh on ath10k

[Bob Copeland]

Hi all,

I have played around a little bit with the raw mode patches trying to
get mesh working on ath10k.  I've hacked the driver slightly to use an
AP vif in the firmware in "mesh" mode, which seems to produce proper looking
beacons over the air.

However, when I bring up a second mesh node, the ath10k device crashes
upon trying to send the first mesh peering action frame.  Here's what
dmesg looks like:

[   43.860000] ath10k_pci 0000:01:00.0: wmi event debug mesg len 140
[   44.310000] XXX trying to create peer 00:03:7f:10:4e:2d
[   44.310000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d
[   44.320000] XXX sending WMI cmd 36892
[   44.320000] XXX sending WMI cmd nowait 36892
[   44.330000] XXX waiting for peer create 00:03:7f:10:4e:2d
[   44.330000] XXX peer 00:03:7f:10:4e:2d added
[   44.340000] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new)
[   44.350000] XXX sending WMI cmd 36896
[   44.350000] XXX sending WMI cmd nowait 36896
[   44.350000] ath10k_pci 0000:01:00.0: received event id 36891 not implemented
[   44.360000] mesh: sending popen to 00:03:7f:10:4e:2d
[   44.380000] ath10k_pci 0000:01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0
[   44.390000] XXX sending WMI cmd 36905
[   44.390000] XXX sending WMI cmd nowait 36905
[   44.390000] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c
[   44.400000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a
[   44.410000] ath10k_pci 0000:01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1
[   44.420000] ath10k_pci 0000:01:00.0: firmware register dump:
[   44.430000] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3 0x009A98BE 0x00955B31
[   44.440000] ath10k_pci 0000:01:00.0: [04]: 0x009A98BE 0x00060330 0x0000001E 0x00000B00
[   44.440000] ath10k_pci 0000:01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x00000078
[   44.450000] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
[   44.460000] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x009A6CCF 0x00000000 0x00000000
[   44.470000] ath10k_pci 0000:01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677
[   44.480000] ath10k_pci 0000:01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE
[   44.480000] ath10k_pci 0000:01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04
[   44.490000] ath10k_pci 0000:01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04
[   44.500000] ath10k_pci 0000:01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8
[   44.510000] ath10k_pci 0000:01:00.0: [40]: 0x809AFD68 0x0040AD94 0x00400000 0x00416688
[   44.520000] ath10k_pci 0000:01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44
[   44.520000] ath10k_pci 0000:01:00.0: [48]: 0x809486FA 0x0040AE04 0x00000001 0x00000000
[   44.530000] ath10k_pci 0000:01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350
[   44.540000] ath10k_pci 0000:01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x00000001

My hacky compat-wireless snapshot is over here, any suggestions on what to
try next to debug further are welcome:

    https://github.com/bcopeland/ath10k-mesh

[Also I tried skipping the mgmt tx datapath and use normal datapath,
as seen in the final patch, but that doesn't change things, it crashes
either way.]

Maybe I'm not setting up peers correctly or something like that?

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

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