Re: [RFC] ath10k: use raw tx
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 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
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 Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v2 2/2] ath10k: add testmode
On 08/29/14 08:03, Kalle Valo wrote: Arend van Spriel writes: On 08/28/14 10:02, Kalle Valo wrote: Kalle Valo writes: Johannes suggested to put this to a separate file as that way it's easier for the user space. In v3 I'm planning to create testmode_uapi.h for this. I suppose that file will/should end up in include/uapi/... I was thinking not to put this to the include directory. This is just a testmode interface used only by few people, not a proper driver interface. I see. In that case I would avoid the term 'uapi'. I think it will impose certain expectations. so wouldn't it be better to call it ath10k_testmode.h? We already have testmode.h so having ath10k_testmode.h in the same directory would be confusing. Would testmode_i.h be any better? What does it contain? Looks like command and attribute definitions for your testmode support. Maybe testmode_defs.h? As long as it is not uapi. Regards, Arend ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: add device/driver strings to tracepoints
Michal Kazior writes: > This makes it easier to log and debug via tracing > with more than 1 ath10k device on a system. > > Signed-off-by: Michal Kazior > --- > Not sure if pulling core.h in trace.h and using ar > pointer is the best approach here. Alternative is > to not pull core.h and pass ar->dev directly to > trace functions. Thoughts? I can't really say, I'm not that familiar with the tracing stuff. To this approach looks good but let's see what others say (if anything). -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: don't access tx_info while overwriting it
Nothing important was being overwritten so it
didn't yield any bugs yet.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/mac.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index b858c82..cdadfef 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1863,11 +1863,10 @@ static u8 ath10k_tx_h_get_tid(struct ieee80211_hdr *hdr)
return ieee80211_get_qos_ctl(hdr)[0] & IEEE80211_QOS_CTL_TID_MASK;
}
-static u8 ath10k_tx_h_get_vdev_id(struct ath10k *ar,
- struct ieee80211_tx_info *info)
+static u8 ath10k_tx_h_get_vdev_id(struct ath10k *ar, struct ieee80211_vif *vif)
{
- if (info->control.vif)
- return ath10k_vif_to_arvif(info->control.vif)->vdev_id;
+ if (vif)
+ return ath10k_vif_to_arvif(vif)->vdev_id;
if (ar->monitor_started)
return ar->monitor_vdev_id;
@@ -2323,7 +2322,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
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);
+ ATH10K_SKB_CB(skb)->vdev_id = ath10k_tx_h_get_vdev_id(ar, vif);
/* it makes no sense to process injected frames like that */
if (vif && vif->type != NL80211_IFTYPE_MONITOR) {
--
1.8.5.3
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: use raw tx
> > 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
On 29 August 2014 09:15, Yeoh Chun-Yeow wrote: > Hi, Michal > > On Fri, Aug 22, 2014 at 3:52 PM, Michal Kazior > 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
Hi, Michal On Fri, Aug 22, 2014 at 3:52 PM, Michal Kazior 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
