[RFC] ath10k: use raw tx

[RFC] ath10k: use raw tx

[Michal Kazior]

This is just a reference for anyone interested in
getting injection working with ath10k.

This just switches to raw tx mode instead of nwifi
for regular operation. Injection doesn't work yet.

I've tested this on 999.999.0.636, 10.1.467.2-1
and 10.2-00082-4. The 10.1.467.2-1 crashes as soon
as first tx completion comes in. The other two
seem to work but don't work with A-MSDU so it is
necessary to disable it:

Be sure to run:
 echo 1 64 > /sys/kernel/debug/ieee80211/phy*/ath10k/htt_max_amsdu_ampdu

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.h   |  1 +
 drivers/net/wireless/ath/ath10k/htt_tx.c | 25 ++++++++++++++++++++-----
 drivers/net/wireless/ath/ath10k/mac.c    |  9 ++++++---
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index cca6060..503cfca 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -68,6 +68,7 @@ struct ath10k_skb_cb {
 	struct {
 		u8 tid;
 		bool is_offchan;
+		bool is_raw;
 		struct ath10k_htt_txbuf *txbuf;
 		u32 txbuf_paddr;
 	} __packed htt;
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 8b27bfc..4fefea8 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -434,6 +434,7 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 	struct ath10k_skb_cb *skb_cb = ATH10K_SKB_CB(msdu);
 	struct ath10k_hif_sg_item sg_items[2];
 	struct htt_data_tx_desc_frag *frags;
+	__le16 fc = hdr->frame_control;
 	u8 vdev_id = skb_cb->vdev_id;
 	u8 tid = skb_cb->htt.tid;
 	int prefetch_len;
@@ -465,6 +466,7 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 	 * of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
 	 * fragment list host driver specifies directly frame pointer. */
 	use_frags = htt->target_version_major < 3 ||
+		    skb_cb->htt.is_raw ||
 		    !ieee80211_is_mgmt(hdr->frame_control);
 
 	skb_cb->htt.txbuf = dma_pool_alloc(htt->tx_pool, GFP_ATOMIC,
@@ -487,8 +489,12 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 		frags[1].paddr = 0;
 		frags[1].len = 0;
 
-		flags0 |= SM(ATH10K_HW_TXRX_NATIVE_WIFI,
-			     HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+		if (skb_cb->htt.is_raw)
+			flags0 |= SM(ATH10K_HW_TXRX_RAW,
+				     HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+		else
+			flags0 |= SM(ATH10K_HW_TXRX_NATIVE_WIFI,
+				     HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
 
 		frags_paddr = skb_cb->htt.txbuf_paddr;
 	} else {
@@ -528,8 +534,6 @@ 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);
-	flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L3_OFFLOAD;
-	flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L4_OFFLOAD;
 
 	/* Prevent firmware from sending up tx inspection requests. There's
 	 * nothing ath10k can do with frames requested for inspection so force
@@ -540,7 +544,18 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
 	skb_cb->htt.txbuf->cmd_hdr.msg_type = HTT_H2T_MSG_TYPE_TX_FRM;
 	skb_cb->htt.txbuf->cmd_tx.flags0 = flags0;
 	skb_cb->htt.txbuf->cmd_tx.flags1 = __cpu_to_le16(flags1);
-	skb_cb->htt.txbuf->cmd_tx.len = __cpu_to_le16(msdu->len);
+
+	/* Firmware has a buggy raw tx mode and it assumes packet is a 802.3
+	 * frame. If length here isn't properly fixed up frames xmited on the
+	 * air contain garbage at the end and have incorrect length.
+	 */
+	if (skb_cb->htt.is_raw)
+		skb_cb->htt.txbuf->cmd_tx.len = __cpu_to_le16(msdu->len -
+							ieee80211_hdrlen(fc) +
+							sizeof(struct ethhdr));
+	else
+		skb_cb->htt.txbuf->cmd_tx.len = __cpu_to_le16(msdu->len);
+
 	skb_cb->htt.txbuf->cmd_tx.id = __cpu_to_le16(msdu_id);
 	skb_cb->htt.txbuf->cmd_tx.frags_paddr = __cpu_to_le32(frags_paddr);
 	skb_cb->htt.txbuf->cmd_tx.peerid = __cpu_to_le32(HTT_INVALID_PEERID);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e568882..1aa748b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2316,13 +2316,18 @@ static void ath10k_tx(struct ieee80211_hw *hw,
 	if (info->flags & IEEE80211_TX_CTL_NO_CCK_RATE)
 		ath10k_dbg(ATH10K_DBG_MAC, "IEEE80211_TX_CTL_NO_CCK_RATE\n");
 
+	ATH10K_SKB_CB(skb)->htt.is_raw = false;
 	ATH10K_SKB_CB(skb)->htt.is_offchan = false;
 	ATH10K_SKB_CB(skb)->htt.tid = ath10k_tx_h_get_tid(hdr);
 	ATH10K_SKB_CB(skb)->vdev_id = ath10k_tx_h_get_vdev_id(ar, info);
 
+	/* For testing purposes. */
+	ATH10K_SKB_CB(skb)->htt.is_raw = true;
+
 	/* it makes no sense to process injected frames like that */
 	if (vif && vif->type != NL80211_IFTYPE_MONITOR) {
-		ath10k_tx_h_nwifi(hw, skb);
+		if (!ATH10K_SKB_CB(skb)->htt.is_raw)
+			ath10k_tx_h_nwifi(hw, skb);
 		ath10k_tx_h_update_wep_key(vif, key, skb);
 		ath10k_tx_h_add_p2p_noa_ie(ar, vif, skb);
 		ath10k_tx_h_seq_no(vif, skb);
@@ -4876,8 +4881,6 @@ int ath10k_mac_register(struct ath10k *ar)
 		ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_ADHOC);
 	}
 
-	ar->hw->netdev_features = NETIF_F_HW_CSUM;
-
 	if (config_enabled(CONFIG_ATH10K_DFS_CERTIFIED)) {
 		/* Init ath dfs pattern detector */
 		ar->ath_common.debug_mask = ATH_DBG_DFS;
-- 
1.8.5.3


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

Re: [RFC] ath10k: use raw tx

[Yeoh Chun-Yeow]

Hi, Michal

On Fri, Aug 22, 2014 at 3:52 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
> This is just a reference for anyone interested in
> getting injection working with ath10k.
>
> This just switches to raw tx mode instead of nwifi
> for regular operation. Injection doesn't work yet.
>
> I've tested this on 999.999.0.636, 10.1.467.2-1
> and 10.2-00082-4. The 10.1.467.2-1 crashes as soon
> as first tx completion comes in. The other two
> seem to work but don't work with A-MSDU so it is
> necessary to disable it:

Packet injection requires monitor mode, am I right? Firmware
999.999.0.636 has no monitor mode support, am I right?

----
ChunYeow

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

Re: [RFC] ath10k: use raw tx

[Michal Kazior]

On 29 August 2014 09:15, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
> Hi, Michal
>
> On Fri, Aug 22, 2014 at 3:52 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
>> This is just a reference for anyone interested in
>> getting injection working with ath10k.
>>
>> This just switches to raw tx mode instead of nwifi
>> for regular operation. Injection doesn't work yet.
>>
>> I've tested this on 999.999.0.636, 10.1.467.2-1
>> and 10.2-00082-4. The 10.1.467.2-1 crashes as soon
>> as first tx completion comes in. The other two
>> seem to work but don't work with A-MSDU so it is
>> necessary to disable it:
>
> Packet injection requires monitor mode, am I right?

Typically you inject frames via monitor vif in radiotap mode. This
doesn't imply anything about driver implementation.


> Firmware 999.999.0.636 has no monitor mode support, am I right?

It crashes soon after starting a lone monitor vdev but I recall it
worked as long as you run it alongside, e.g. an associated station
interface so you can try working around this problem. Or you can run
10.2.

Then Txing with monitor vdev_id will definitely crash all known
firmware binaries. Other vdev types need peer entries to be set up
before a frame can be sent with certain DA (otherwise it stays in the
queues indefinitely). Take a look at the offchannel worker in ath10k
as it may be useful if you want to get this running (at least to a
limited degree).

Also, with raw tx in ath10k you can probably try playing with mesh
because QoS Control is no longer stripped, right?


Michał

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

Re: [RFC] ath10k: use raw tx

[Yeoh Chun-Yeow]

>
> Also, with raw tx in ath10k you can probably try playing with mesh
> because QoS Control is no longer stripped, right?
>
Yes. This is one of the issues.

--------
ChunYeow

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

Re: [RFC] ath10k: use raw tx

[Ben Greear]

On 08/22/2014 12:52 AM, Michal Kazior wrote:
> This is just a reference for anyone interested in
> getting injection working with ath10k.

Did you try this with encryption?  I can reproduce the crash
in open mode on my CT firmware, but I couldn't even get
DHCP to complete with wpa2 enabled.

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: [RFC] ath10k: use raw tx

[Ben Greear]

On 08/29/2014 02:45 PM, Ben Greear wrote:
> On 08/22/2014 12:52 AM, Michal Kazior wrote:
>> This is just a reference for anyone interested in
>> getting injection working with ath10k.
>
> Did you try this with encryption?  I can reproduce the crash
> in open mode on my CT firmware, but I couldn't even get
> DHCP to complete with wpa2 enabled.

I found a null-deref in the firmware and fixed (ie, hacked around) it.

http://www.candelatech.com/downloads/firmware-2-full-community-raw-tx.bin

This seems to work fine for open encryption, at least.  I tested it with your
patch applied, on top of my other patches, on top of kvalo's latest ath tree.

I'd be curious to know if anyone else tries it.

Thanks,
Ben


>
> 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: [RFC] ath10k: use raw tx

[Michal Kazior]

On 29 August 2014 23:45, Ben Greear <greearb@candelatech.com> wrote:
> On 08/22/2014 12:52 AM, Michal Kazior wrote:
>> This is just a reference for anyone interested in
>> getting injection working with ath10k.
>
> Did you try this with encryption?  I can reproduce the crash
> in open mode on my CT firmware, but I couldn't even get
> DHCP to complete with wpa2 enabled.

Hi,

Late reply, sorry.

I've just did a quick test on 10.2 (both AP and STA) with WPA2.
Apparently the raw tx mode requires IV to be set up on host and packet
length (reported in HTT Tx command header) must be re-adjusted
differently, otherwise frames are broken (incorrect FCS, too long,
somewhat encrypted except LLC/SNAP). The best I could get were
FCS-correct undecryptable frames on air. Perhaps someone will figure
that out..

Another way around this would be to perform software crypto for tx
entirely on host.


Michał

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

Re: [RFC] ath10k: use raw tx

[Kalle Valo]

Michal Kazior <michal.kazior@tieto.com> writes:

> On 29 August 2014 23:45, Ben Greear <greearb@candelatech.com> wrote:
>> On 08/22/2014 12:52 AM, Michal Kazior wrote:
>>> This is just a reference for anyone interested in
>>> getting injection working with ath10k.
>>
>> Did you try this with encryption?  I can reproduce the crash
>> in open mode on my CT firmware, but I couldn't even get
>> DHCP to complete with wpa2 enabled.
>
> Hi,
>
> Late reply, sorry.
>
> I've just did a quick test on 10.2 (both AP and STA) with WPA2.
> Apparently the raw tx mode requires IV to be set up on host and packet
> length (reported in HTT Tx command header) must be re-adjusted
> differently, otherwise frames are broken (incorrect FCS, too long,
> somewhat encrypted except LLC/SNAP). The best I could get were
> FCS-correct undecryptable frames on air. Perhaps someone will figure
> that out..
>
> Another way around this would be to perform software crypto for tx
> entirely on host.

BTW, it would be nice to get software crypto support to ath10k, for
example with a nohwcrypt module parameter like ath9k has.

-- 
Kalle Valo

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

Re: [RFC] ath10k: use raw tx

[Ben Greear]

On 09/11/2014 03:47 AM, Kalle Valo wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> On 29 August 2014 23:45, Ben Greear <greearb@candelatech.com> wrote:
>>> On 08/22/2014 12:52 AM, Michal Kazior wrote:
>>>> This is just a reference for anyone interested in
>>>> getting injection working with ath10k.
>>>
>>> Did you try this with encryption?  I can reproduce the crash
>>> in open mode on my CT firmware, but I couldn't even get
>>> DHCP to complete with wpa2 enabled.
>>
>> Hi,
>>
>> Late reply, sorry.
>>
>> I've just did a quick test on 10.2 (both AP and STA) with WPA2.
>> Apparently the raw tx mode requires IV to be set up on host and packet
>> length (reported in HTT Tx command header) must be re-adjusted
>> differently, otherwise frames are broken (incorrect FCS, too long,
>> somewhat encrypted except LLC/SNAP). The best I could get were
>> FCS-correct undecryptable frames on air. Perhaps someone will figure
>> that out..
>>
>> Another way around this would be to perform software crypto for tx
>> entirely on host.
>
> BTW, it would be nice to get software crypto support to ath10k, for
> example with a nohwcrypt module parameter like ath9k has.

You have to hack the firmware (and patch driver) to make this work.  I have patches to make
rx-sw-crypt work with my CT firmware.  Been releasing this only for non-commercial
use, but I'd be willing to make it supported without restriction and instead
limit number of stations to < 16 when sw-crypt was enabled.  This leaves my
commercial offering worth paying for for the few people that might compete against
our testing products.

I had all sorts of trouble, similar to what you describe trying to get raw tx
to work, and eventually gave up entirely.  My method of rx-sw-crypt uses normal tx
(with hardware offload), but decrypts on the host.

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: [RFC] ath10k: use raw tx

[Ben Greear]

On 09/11/2014 03:35 AM, Michal Kazior wrote:
> On 29 August 2014 23:45, Ben Greear <greearb@candelatech.com> wrote:
>> On 08/22/2014 12:52 AM, Michal Kazior wrote:
>>> This is just a reference for anyone interested in
>>> getting injection working with ath10k.
>>
>> Did you try this with encryption?  I can reproduce the crash
>> in open mode on my CT firmware, but I couldn't even get
>> DHCP to complete with wpa2 enabled.
>
> Hi,
>
> Late reply, sorry.
>
> I've just did a quick test on 10.2 (both AP and STA) with WPA2.
> Apparently the raw tx mode requires IV to be set up on host and packet
> length (reported in HTT Tx command header) must be re-adjusted
> differently, otherwise frames are broken (incorrect FCS, too long,
> somewhat encrypted except LLC/SNAP). The best I could get were
> FCS-correct undecryptable frames on air. Perhaps someone will figure
> that out..
>
> Another way around this would be to perform software crypto for tx
> entirely on host.

That did not fix the problem for me.  The firmware/hardware could not be
convinced (by me, at least) to leave the encrypted packet alone and insisted on
doing at least partial re-crypt, or something like that.

Thanks,
Ben

>
>
> Michał
>


-- 
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: [RFC] ath10k: use raw tx

[Yeoh Chun-Yeow]

Hi, all

Did anyone try the raw tx on adhoc mode? I have tested this patch with
firmware 999.999.0.636.

The unicast frame is not transmitted using raw tx, only broadcast.

After adjust the cmd_tx.len as follow, I have managed to make the
adhoc STA to ping each others.

skb_cb->htt.txbuf->cmd_tx.len = __cpu_to_le16(msdu->len -
sizeof(struct ieee80211_hdr_3addr) + sizeof(struct ethhdr));

Can someone comment on this?

----
Chun-Yeow


On Thu, Sep 11, 2014 at 10:19 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 09/11/2014 03:35 AM, Michal Kazior wrote:
>>
>> On 29 August 2014 23:45, Ben Greear <greearb@candelatech.com> wrote:
>>>
>>> On 08/22/2014 12:52 AM, Michal Kazior wrote:
>>>>
>>>> This is just a reference for anyone interested in
>>>> getting injection working with ath10k.
>>>
>>>
>>> Did you try this with encryption?  I can reproduce the crash
>>> in open mode on my CT firmware, but I couldn't even get
>>> DHCP to complete with wpa2 enabled.
>>
>>
>> Hi,
>>
>> Late reply, sorry.
>>
>> I've just did a quick test on 10.2 (both AP and STA) with WPA2.
>> Apparently the raw tx mode requires IV to be set up on host and packet
>> length (reported in HTT Tx command header) must be re-adjusted
>> differently, otherwise frames are broken (incorrect FCS, too long,
>> somewhat encrypted except LLC/SNAP). The best I could get were
>> FCS-correct undecryptable frames on air. Perhaps someone will figure
>> that out..
>>
>> Another way around this would be to perform software crypto for tx
>> entirely on host.
>
>
> That did not fix the problem for me.  The firmware/hardware could not be
> convinced (by me, at least) to leave the encrypted packet alone and insisted
> on
> doing at least partial re-crypt, or something like that.
>
> Thanks,
> Ben
>
>>
>>
>> Michał
>>
>
>
> --
> 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

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

Re: [RFC] ath10k: use raw tx

[Michal Kazior]

On 12 September 2014 12:41, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
> Hi, all
>
> Did anyone try the raw tx on adhoc mode? I have tested this patch with
> firmware 999.999.0.636.
>
> The unicast frame is not transmitted using raw tx, only broadcast.

I did not test 636 with IBSS.


> After adjust the cmd_tx.len as follow, I have managed to make the
> adhoc STA to ping each others.
>
> skb_cb->htt.txbuf->cmd_tx.len = __cpu_to_le16(msdu->len -
> sizeof(struct ieee80211_hdr_3addr) + sizeof(struct ethhdr));
>
> Can someone comment on this?

Interesting!

Can you confirm what kind of a header your unicast frames actually
have? Do you perhaps run 4addr mode? Or maybe Data/QoS Data (2 byte
difference at least) calculation is the problem.


Michał

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

Re: [RFC] ath10k: use raw tx

[Yeoh Chun-Yeow]

On Fri, Sep 12, 2014 at 7:05 PM, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 12 September 2014 12:41, Yeoh Chun-Yeow <yeohchunyeow@gmail.com> wrote:
>
> Interesting!
>
> Can you confirm what kind of a header your unicast frames actually
> have? Do you perhaps run 4addr mode? Or maybe Data/QoS Data (2 byte
> difference at least) calculation is the problem.
>

It's a QoS Data frame. Yes (2 byte different). Probably the firmware
raw tx mode only cater for non-QoS frame?

Question, 4addr mode is allowed in adhoc mode by the firmware? No, right?

----
Chun-Yeow

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