| Message ID | 20150712142532.GA24495@localhost (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
[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.
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?
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.
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.
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!)
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 */