Re: attempting mesh on ath10k
On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote: On 13 July 2015 at 03:43, Bob Copeland m...@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
On Mon, Jul 13, 2015 at 10:13:59AM +0200, Michal Kazior wrote: On 13 July 2015 at 03:43, Bob Copeland m...@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
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
On Wed, May 27, 2015 at 08:51:05AM +0200, Bartosz Markowski wrote: On 28 April 2015 at 14:25, Bob Copeland m...@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
On 27 May 2015 at 13:12, Bob Copeland m...@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
On 28 April 2015 at 14:25, Bob Copeland m...@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
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
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.67] ath10k_pci :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
Great works, Bob. Which AP firmware that you have tested with? Chun-Yeow On Tue, Apr 28, 2015 at 8:41 PM, Bob Copeland m...@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
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
On 27 April 2015 at 15:00, Bob Copeland m...@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
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
attempting mesh on ath10k
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.86] ath10k_pci :01:00.0: wmi event debug mesg len 140 [ 44.31] XXX trying to create peer 00:03:7f:10:4e:2d [ 44.31] ath10k_pci :01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d [ 44.32] XXX sending WMI cmd 36892 [ 44.32] XXX sending WMI cmd nowait 36892 [ 44.33] XXX waiting for peer create 00:03:7f:10:4e:2d [ 44.33] XXX peer 00:03:7f:10:4e:2d added [ 44.34] ath10k_pci :01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new) [ 44.35] XXX sending WMI cmd 36896 [ 44.35] XXX sending WMI cmd nowait 36896 [ 44.35] ath10k_pci :01:00.0: received event id 36891 not implemented [ 44.36] mesh: sending popen to 00:03:7f:10:4e:2d [ 44.38] ath10k_pci :01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0 [ 44.39] XXX sending WMI cmd 36905 [ 44.39] XXX sending WMI cmd nowait 36905 [ 44.39] ath10k_pci :01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c [ 44.40] ath10k_pci :01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a [ 44.41] ath10k_pci :01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1 [ 44.42] ath10k_pci :01:00.0: firmware register dump: [ 44.43] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 0x009A98BE 0x00955B31 [ 44.44] ath10k_pci :01:00.0: [04]: 0x009A98BE 0x00060330 0x001E 0x0B00 [ 44.44] ath10k_pci :01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x0078 [ 44.45] ath10k_pci :01:00.0: [12]: 0x0009 0x 0x00958360 0x0095836B [ 44.46] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A6CCF 0x 0x [ 44.47] ath10k_pci :01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677 [ 44.48] ath10k_pci :01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE [ 44.48] ath10k_pci :01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04 [ 44.49] ath10k_pci :01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04 [ 44.50] ath10k_pci :01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8 [ 44.51] ath10k_pci :01:00.0: [40]: 0x809AFD68 0x0040AD94 0x0040 0x00416688 [ 44.52] ath10k_pci :01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44 [ 44.52] ath10k_pci :01:00.0: [48]: 0x809486FA 0x0040AE04 0x0001 0x [ 44.53] ath10k_pci :01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350 [ 44.54] ath10k_pci :01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x0001 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
Re: attempting mesh on ath10k
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 m...@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.86] ath10k_pci :01:00.0: wmi event debug mesg len 140 [ 44.31] XXX trying to create peer 00:03:7f:10:4e:2d [ 44.31] ath10k_pci :01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d [ 44.32] XXX sending WMI cmd 36892 [ 44.32] XXX sending WMI cmd nowait 36892 [ 44.33] XXX waiting for peer create 00:03:7f:10:4e:2d [ 44.33] XXX peer 00:03:7f:10:4e:2d added [ 44.34] ath10k_pci :01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new) [ 44.35] XXX sending WMI cmd 36896 [ 44.35] XXX sending WMI cmd nowait 36896 [ 44.35] ath10k_pci :01:00.0: received event id 36891 not implemented [ 44.36] mesh: sending popen to 00:03:7f:10:4e:2d [ 44.38] ath10k_pci :01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0 [ 44.39] XXX sending WMI cmd 36905 [ 44.39] XXX sending WMI cmd nowait 36905 [ 44.39] ath10k_pci :01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c [ 44.40] ath10k_pci :01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a [ 44.41] ath10k_pci :01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1 [ 44.42] ath10k_pci :01:00.0: firmware register dump: [ 44.43] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 0x009A98BE 0x00955B31 [ 44.44] ath10k_pci :01:00.0: [04]: 0x009A98BE 0x00060330 0x001E 0x0B00 [ 44.44] ath10k_pci :01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x0078 [ 44.45] ath10k_pci :01:00.0: [12]: 0x0009 0x 0x00958360 0x0095836B [ 44.46] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A6CCF 0x 0x [ 44.47] ath10k_pci :01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677 [ 44.48] ath10k_pci :01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE [ 44.48] ath10k_pci :01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04 [ 44.49] ath10k_pci :01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04 [ 44.50] ath10k_pci :01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8 [ 44.51] ath10k_pci :01:00.0: [40]: 0x809AFD68 0x0040AD94 0x0040 0x00416688 [ 44.52] ath10k_pci :01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44 [ 44.52] ath10k_pci :01:00.0: [48]: 0x809486FA 0x0040AE04 0x0001 0x [ 44.53] ath10k_pci :01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350 [ 44.54] ath10k_pci :01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x0001 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
Re: attempting mesh on ath10k
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 m...@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.86] ath10k_pci :01:00.0: wmi event debug mesg len 140 [ 44.31] XXX trying to create peer 00:03:7f:10:4e:2d [ 44.31] ath10k_pci :01:00.0: wmi peer create vdev_id 0 peer_addr 00:03:7f:10:4e:2d [ 44.32] XXX sending WMI cmd 36892 [ 44.32] XXX sending WMI cmd nowait 36892 [ 44.33] XXX waiting for peer create 00:03:7f:10:4e:2d [ 44.33] XXX peer 00:03:7f:10:4e:2d added [ 44.34] ath10k_pci :01:00.0: wmi peer assoc vdev 0 addr 00:03:7f:10:4e:2d (new) [ 44.35] XXX sending WMI cmd 36896 [ 44.35] XXX sending WMI cmd nowait 36896 [ 44.35] ath10k_pci :01:00.0: received event id 36891 not implemented [ 44.36] mesh: sending popen to 00:03:7f:10:4e:2d [ 44.38] ath10k_pci :01:00.0: wmi mgmt tx skb 86fb4e40 len 84 ftype 00 stype d0 [ 44.39] XXX sending WMI cmd 36905 [ 44.39] XXX sending WMI cmd nowait 36905 [ 44.39] ath10k_pci :01:00.0: firmware crashed! (uuid 839037ff-ad03-4442-9114-f99e03204c [ 44.40] ath10k_pci :01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 a [ 44.41] ath10k_pci :01:00.0: debug 1 debugfs 1 tracing 0 dfs 1 testmode 1 [ 44.42] ath10k_pci :01:00.0: firmware register dump: [ 44.43] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 0x009A98BE 0x00955B31 [ 44.44] ath10k_pci :01:00.0: [04]: 0x009A98BE 0x00060330 0x001E 0x0B00 [ 44.44] ath10k_pci :01:00.0: [08]: 0x00447730 0x009C3014 0x00446970 0x0078 [ 44.45] ath10k_pci :01:00.0: [12]: 0x0009 0x 0x00958360 0x0095836B [ 44.46] ath10k_pci :01:00.0: [16]: 0x00958080 0x009A6CCF 0x 0x [ 44.47] ath10k_pci :01:00.0: [20]: 0x409A98BE 0x0040AB14 0x0040FAA8 0x0043E677 [ 44.48] ath10k_pci :01:00.0: [24]: 0x809A9958 0x0040AB74 0x0043E7CC 0xC09A98BE [ 44.48] ath10k_pci :01:00.0: [28]: 0x8099F2E9 0x0040AB94 0x009C3014 0x0040AD04 [ 44.49] ath10k_pci :01:00.0: [32]: 0x8098933F 0x0040ABB4 0x0043D0D8 0x0040AD04 [ 44.50] ath10k_pci :01:00.0: [36]: 0x809B38C0 0x0040ABD4 0x009C3014 0x0043D0D8 [ 44.51] ath10k_pci :01:00.0: [40]: 0x809AFD68 0x0040AD94 0x0040 0x00416688 [ 44.52] ath10k_pci :01:00.0: [44]: 0x809BDA75 0x0040ADE4 0x0040AE08 0x00411D44 [ 44.52] ath10k_pci :01:00.0: [48]: 0x809486FA 0x0040AE04 0x0001 0x [ 44.53] ath10k_pci :01:00.0: [52]: 0x80948E2C 0x0040AEA4 0x0041E424 0x00412350 [ 44.54] ath10k_pci :01:00.0: [56]: 0x809BCF0D 0x0040AEC4 0x0041E424 0x0001 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 gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com
