gmane.linux.drivers.ath9k.devel

Re: modifying priority of UDP packets

Holger Schurig — 2013-05-24T09:43:44

Have you tried the normal QoS stuff that IP supports?  The document
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/
is antique by IT standards, but most (if not all) still holds true.

Basically, you mark your important packets using firewall rules. Later
those markings are used in the QoS part of the networking stack to
prioritize those packets.

A driver is the very wrong destination for such a solution: would you
hack 1000 different ethernet-, WLAN- and Bluetooth drivers if you want
to prioritize packets?  Nope!

Re: modifying priority of UDP packets

abhinav narain — 2013-05-24T06:07:55

Well, I don't want to do it in the driver, if possible in mac80211 itself.
I looked into net/mac80211/, but I did not find any specific hint where the
TOS field is checked and subsequent allocation
takes place. Any hint will be greatly appreciated !

-
Abhinav

On Thu, May 23, 2013 at 7:07 PM, abhinav narain
<abhinavnarain10< at >gmail.com>wrote:

_______________________________________________
ath9k-devel mailing list
ath9k-devel< at >lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

modifying priority of UDP packets

abhinav narain — 2013-05-24T02:07:35

Hi all,
I wanted to modify the priority of one of specific UDP frames generated by
my specific application,
to be send on VI queue.
Can someone please tell, which files should I look into in compat-wireless
folder ?
-
Abhinav
_______________________________________________
ath9k-devel mailing list
ath9k-devel< at >lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[PATCH v3 1/3] mac80211: add STBC flag for radiotap

Oleksij Rempel — 2013-05-23T14:11:19

Some chips can tell us if received frame was
encoded with STBC or not. To make this information available
in user space we can use updated radiotap specification:
http://www.radiotap.org/defined-fields/MCS

This patch add HAVE_STBC flag and provide number
of STBC encoded spatial streams (Nss).

Signed-off-by: Oleksij Rempel <linux< at >rempel-privat.de>
---
 include/net/ieee80211_radiotap.h |  7 +++++++
 include/net/mac80211.h           |  4 ++++
 net/mac80211/rx.c                | 13 ++++++++++++-
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
< at >< at > -269,6 +269,7 < at >< at > enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_HAVE_GI0x04
 #define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
 #define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC0x20
 
 #define IEEE80211_RADIOTAP_MCS_BW_MASK0x0

[PATCH v2 1/3] mac80211: add STBC flag for radiotap

Oleksij Rempel — 2013-05-23T07:17:55

revision:
- v2. set HAVE_STBC only if it is present.
      do not set STBC flag on TX packets.

Signed-off-by: Oleksij Rempel <linux< at >rempel-privat.de>
---
 include/net/ieee80211_radiotap.h |  7 +++++++
 include/net/mac80211.h           |  4 ++++
 net/mac80211/rx.c                | 13 ++++++++++++-
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
< at >< at > -269,6 +269,7 < at >< at > enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_HAVE_GI0x04
 #define IEEE80211_RADIOTAP_MCS_HAVE_FMT0x08
 #define IEEE80211_RADIOTAP_MCS_HAVE_FEC0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC0x20
 
 #define IEEE80211_RADIOTAP_MCS_BW_MASK0x03
 #defineIEEE80211_RADIOTAP_MCS_BW_200
< at >< at > -278,6 +279,12 < at >< at > enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_MCS_SGI0x04
 #define IEEE80211_RADIOTAP_MCS_FMT_GF0x08
 #define IEEE80211

[PATCH] ath10k: sync WMI interface to FW 636

Michal Kazior — 2013-05-22T09:11:25

Signed-off-by: Michal Kazior <michal.kazior< at >tieto.com>
---
 drivers/net/wireless/ath/ath10k/wmi.h |   32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index f08dbb2..9555f5a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
< at >< at > -104,6 +104,7 < at >< at > enum wmi_service_id {
 WMI_SERVICE_STA_DTIM_PS_MODULATED_DTIM, /* Modulated DTIM support */
 WMI_STA_UAPSD_BASIC_AUTO_TRIG,    /* UAPSD AC Trigger Generation  */
 WMI_STA_UAPSD_VAR_AUTO_TRIG,      /* -do- */
+WMI_SERVICE_STA_KEEP_ALIVE,       /* STA keep alive mechanism support */
 WMI_SERVICE_TX_ENCAP,             /* Packet type for TX encapsulation */
 
 WMI_SERVICE_LAST,
< at >< at > -173,6 +174,8 < at >< at > static inline char *wmi_service_name(int service_id)
 return "BASIC UAPSD";
 case WMI_STA_UAPSD_VAR_AUTO_TRIG:
 return "VAR UAPSD";
+case WMI_SERVICE_STA_KEEP_ALIVE:
+return "STA KEEP ALIVE";
 case WMI_SERVICE

[PATCH] ath10k: fix hw scan cancelling

Michal Kazior — 2013-05-22T06:42:54

If mac80211 decides to cancel a hw scan and FW is
not behaving properly (i.e.  doesn't want to abort
scan at all) we must call
ieee80211_scan_completed(). Otherwise no more
scans will be initiated, ever.

Signed-off-by: Michal Kazior <michal.kazior< at >tieto.com>
---
 drivers/net/wireless/ath/ath10k/mac.c |   25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 2412161..34df005 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
< at >< at > -1524,7 +1524,7 < at >< at > void ath10k_reset_scan(unsigned long ptr)
 spin_unlock_bh(&ar->data_lock);
 }
 
-static void ath10k_abort_scan(struct ath10k *ar)
+static int ath10k_abort_scan(struct ath10k *ar)
 {
 struct wmi_stop_scan_arg arg = {
 .req_id = 1, /* FIXME */
< at >< at > -1540,15 +1540,17 < at >< at > static void ath10k_abort_scan(struct ath10k *ar)
 spin_lock_bh(&ar->data_lock);
 if (!ar->scan.in_progress) {
 spin_unlock_bh(&ar->

Re: AR9287 ; 2-wire coexistence expected behavior

sandeep suresh — 2013-05-22T05:49:40

Hello Mr.Adrian,
    Thanks for your comments. 
 
In fact I have used the same ath9k code available and called the initialization for 2-wire coexistence that was missing. I will test further (the following aspects)and commit the code with some documentation so that it will be useful for the community.
 
Can you please further help me:
1. Commands to enable hostapd logging whichwill log the MLME events.
2. How can I enable missed beacon transmit events? Does it get automatically enabled during "modprobe ath9k diag=0xFFFFFFFF" ?

 
Thanks & regards
Sandeep Suresh

________________________________
From: Adrian Chadd <adrian< at >freebsd.org>
To: sandeep suresh <sandeep.suresh< at >yahoo.co.in> 
Cc: ath9k-devel <ath9k-devel< at >lists.ath9k.org>; "linux-wireless< at >vger.kernel.org" <linux-wireless< at >vger.kernel.org> 
Sent: Tuesday, 21 May 2013 8:03 PM
Subject: Re: [ath9k-devel] AR9287 ; 2-wire coexistence expected behavior


Hi!

On 20 May 2013 23:40, sandeep suresh <sandeep.suresh< at >yahoo.co.in> wrote:
Cool! Can you share som

Frequency range selected while scan

Francisco Cuesta — 2013-05-21T21:13:36

Hello,

I'm working with ath9k driver and wpa supplicant, I have some doubts
related to how wpa supplicant calls the driver(80211) functions for
making a scan in station mode; concretely, I'd wish to locate how the
range of frequencies or channels, in which such a scan'll be carried
out, are defined or set.

Could someone point me out what functions of athk9 driver are used for
such purpose?

Thanks in advance,

Re: [PATCH 0/6] ath10k: vht support

Kalle Valo — 2013-05-21T19:30:04


Applied.

Re: [PATCH 6/6] ath10k: preliminary VHT support

Kalle Valo — 2013-05-21T19:19:10


Yes. I assumed this is for the AP mode, but I can be wrong.


Yeah. I'll just apply this now.

Re: [PATCH] ath10k: program FW with appropriateregdomain

Kalle Valo — 2013-05-21T18:59:50


Thanks, applied.

There's actually one checkpatch warning:

drivers/net/wireless/ath/ath10k/mac.c:1266: WARNING: Avoid CamelCase: <regpair->regDmnEnum>

But there's not much we can do about that :)

Re: [PATCH] ath10k: remove unnecessary include

Kalle Valo — 2013-05-21T18:56:24


Thanks, applied.

Re: [PATCH] ath10k: remove static mac address mask

Kalle Valo — 2013-05-21T18:55:25


Thanks, applied.

Re: [PATCH] ath10k: remove CTRY_DEFAULT assignment

Kalle Valo — 2013-05-21T18:54:13


Thanks, applied.

Re: ath9k-htc firmware related question.

Eugene Krasnikov — 2013-05-21T18:29:23

This? :) http://wireless.kernel.org/en/users/Drivers/ath9k_htc/devices

2013/5/21 Ben Greear <greearb< at >candelatech.com>:

Re: ath9k-htc firmware related question.

Ben Greear — 2013-05-21T18:24:27

Well, not obviously.  I found the firmware..looking
for the name of the company that helped get it
opened up because they were making hardware of
some sort).

If it's at the link above, it's not obvious.

Thanks,
Ben

Re: ath9k-htc firmware related question.

Eugene Krasnikov — 2013-05-21T18:18:33

Is this what you are looking for ?:)
https://github.com/qca/open-ath9k-htc-firmware

2013/5/21 Ben Greear <greearb< at >candelatech.com>:

ath9k-htc firmware related question.

Ben Greear — 2013-05-21T18:08:02

I have a vague memory of mention of a company that helped
fund the ath9k-htc firmware release because it wanted to
make a fully open system.

But, I cannot find mention of it anywhere on the wiki, etc.

Could someone remind me this company name?  I want to see
if they offer NICs for sale..seems like good folks to
support!

Thanks,
Ben

Re: [PATCH 6/6] ath10k: preliminary VHT support

Michal Kazior — 2013-05-21T11:45:30


Hmm.. so VHT works on the device without setting proper peer phymode?

Adding phymode here should be trivial here I guess anyway.

Re: AR9287 ; 2-wire coexistence expected behavior

sandeep suresh — 2013-05-21T06:40:18

Hello Mr.Adrian,
    Greetings! I resumed my experiments with 2-wire co-existence with AR9287 in WiFi AP mode.
I was able to see that WLAN_STATUS signal being suppressed when BT_ACTIVE is enabled. I used a 100ms On and 100ms Off (Period = 200ms; 50% dc) for BT_ACTIVE. Just want to confirm the following before ensuring that I am seeing the expected behavior:
 
1. As I am running the WiFi AP with co-existence, other WiFi clients are connected to my AP. by means of diagnsosis (I have enabled diagnosis with modprobe ath9k btcoex_enabled=1 diag=0xffffffff), how can I find out if any WiFi clients are loosing connection and re-connecting back to AP.
 
2. How can I come to know if any of the beacons in WiFi AP mode are getting missed? Diagnosis messages that I can look at.
 
3. As diagnosis is enabled I see the following....is this a concern as there is disable and enable of IER?
<7>ath: disable IER
<7>ath: AR_IMR 0x918104b0 IER 0x1
<7>ath: tx queue 2 (4bfc09c4), link ffde09c4
<7>ath: enable IER
<7>ath: Enabl