[ath9k-devel] NF calibration and software level simulation of packet errors

Dear all, I have a couple of questions related to the ath9k drivers. 1) I was wondering if it is possible to purposely deactivate the ACK transmission on a per-attempt basis. Specifically, I would like to simulate packet errors at driver level (i.e. software). I already looked at the methods

[ath9k-devel] anyone looked at japan certification?

Hi, I've had someone ask me about japan certification for ath9k. it apparently now requires the transmitter stop everything, beaconing included, when it sees an interferer signal. Apparently ath9k is also beaconing no matter what the interference is. Has anyone else come across this? -a

[ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

Long back 'bool' type used to be a typecast to 'int', but that changed in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes just a byte. Anyway, the bool type is implementation defined, and better we don't assume its size to be 4 bytes or 1. The problem with current code is that

[ath9k-devel] ath9k_htc runinng on USB 1 interface

Hello all, I've come across some strangeness when using a USB ath9k on a USB 1 interface. I'm getting the "BOGUS urb xfer, pipe 1 != type 3" errors that have been posted and discussed already, but the cause of the errors in my case is different than those already reported. I did some digging to

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, Sep 15, 2015 at 02:04:59PM +0530, Viresh Kumar wrote: > Long back 'bool' type used to be a typecast to 'int', but that changed > in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes > just a byte. Anyway, the bool type is implementation defined, and better > we don't

[ath9k-devel] MCS Information Corrupted in Sniffed A-MPDU Packets

Hi, Recently I used an OpenWRT router (TP-LINK WDR3500, AR9340, ATH9K) to sniff packets, and I found that the MCS information in the radiotap header is possible corrupted. In theory, all A-MPDU subframes should be sent in the same bit rate (MCS/BW/GI), since they have the same PPDU header.

Re: [ath9k-devel] [PATCH v2] ath9k: Add support for ITS-G5 band (5.9 GHz)

Hi Jouni, thanks for quick reply. On Mon, Nov 02 2015, Jouni Malinen wrote: > On Mon, Nov 02, 2015 at 11:22:57AM +0100, Michal Sojka wrote: >> The patch adds support for Intelligent Transportation System (ITS-G5) >> band to the ath9k driver. > > NAK. This would enable use of licensed 5.9 GHz

[ath9k-devel] ath9k(?): AP stops sending traffic to iPhone 4S until another 802.11n-capable STA joins

[fixed ath9k list address. sorry for the spam] Hi all, I have a pretty weird problem I've been chasing for a few weeks and have narrowed it down, but not quite solved it. It may be caused by bugs in aggregation-related code. Steps: - Set up an ath9k-based Linux AP on an ARM processor

[ath9k-devel] [PATCH v2 7/8] cfg80211: Add Kconfig option for ITS-G5 band (5.9 GHz)

This option is meant for use by drivers and other subsystems to enable support for the Intelligent Transportation System (ITS-G5) band. The option depends on CFG80211_CERTIFICATION_ONUS as the use of this band is restricted. EU allows using it only for certain applications, USA require

Re: [ath9k-devel] [PATCH v2] ath9k: incorrect queue may be stopped/awaken

Hi, Let me explain the patch more thoroughly. We are testing MCC and we've found some issues with the queues handlers, the main problem is that when we transmit a multicast/broadcast frame, where hw_queue is 8 (CAB), we check queue status, which is 2(q), and if it is full and we have to stop it,

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

* Steven Rostedt wrote: > But please, next time, go easy on the Cc list. Maybe just use bcc for those > not > on the list, stating that you BCC'd a lot of people to make sure this is > sane, > but didn't want to spam everyone with every reply. Not just that, such a

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, Sep 15, 2015 at 01:47:32PM -0400, Steven Rostedt wrote: > What do others think when there's a change that goes across the board > this much? BCC OK with you, as just an FYI, I'm doing this? Or should > just the lists be enough and if you don't see it, too bad? Bcc sounds good to me.

Re: [ath9k-devel] [PATCH v2 7/8] cfg80211: Add Kconfig option for ITS-G5 band (5.9 GHz)

On Fri, Nov 27 2015, Johannes Berg wrote: > On Thu, 2015-11-26 at 22:10 +0100, Michal Sojka wrote: >>  >> Because in [1] Jouni said that >> >>    "kernel config option + custom regdb would certainly be much >> closer to what I'd like to see from the regulatory enforcement view >> point" >> >> I

[ath9k-devel] [PATCH] ath9k: incorrect queue may be stopped/awaken

When channel context is enabled, we could be stopping/awakening an incorrect queue. --- drivers/net/wireless/ath/ath9k/xmit.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c

[ath9k-devel] [PATCH] ath9k_htc: fix handling return value of ath9k_hw_calibrate

The function can return negative values in case of error. Its result should be then tested for such case. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107

[ath9k-devel] [PATCH V2] debugfs: don't assume sizeof(bool) to be 4 bytes

Long back 'bool' type used to be a typecast to 'int', but that changed in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes just a byte. Anyway, the bool type is implementation defined, and better we don't assume its size to be 4 bytes or 1. The problem with current code is that

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

Hi Johannes, On 15-09-15, 12:37, Johannes Berg wrote: > This email has far too many people Cc'ed on it - I don't think vger is > even accepting it for that reason. You should probably restrict it to > just a few lists when you resubmit. Hmm, I know the list is too long and yes its blocked for

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

Hello, On Tue, Sep 15, 2015 at 07:42:08PM +0530, Viresh Kumar wrote: > Ah, yes. Thanks for letting me know (I just testedit as well). > > But will it look sane enough to set a boolean to anything apart from > true/false or 1/0? Yes, it will always be set to 0/1 only, but still.. Let's please

Re: [ath9k-devel] [PATCH v2] ath9k: Add support for ITS-G5 band (5.9 GHz)

On Mon, Nov 02 2015, Jouni Malinen wrote: > On Mon, Nov 02, 2015 at 06:33:45PM +0100, Michal Sojka wrote: >> Can this be solved by having proper/new regulatory flags on these >> channels that would prohibit running AP or scanning on these channels? > > I'm not sure that alone is sufficient, but

[ath9k-devel] [PATCH v2] ath9k: incorrect queue may be stopped/awaken

When channel context is enabled, we could be stopping/awakening an incorrect queue. Signed-off-by: Borja Salazar --- drivers/net/wireless/ath/ath9k/xmit.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git

[ath9k-devel] [PATCH v2 5/8] cfg80211: Add support for OCB-only channels

We don't want channels designated for Intelligent Transportation Systems to be used in other modes than OCB. We therefore introduce regulatory and channel flags that prevent scanning (for performance reasons) and beaconing on these channels. Although regulatory documents do not talk about which

[ath9k-devel] [PATCH] ath9k: fix inconsistent indenting on return statement

From: Colin Ian King minor change, indenting is one tab out. Signed-off-by: Colin Ian King --- drivers/net/wireless/ath/ath9k/xmit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/xmit.c

[ath9k-devel] [PATCH v2 6/8] cfg80211: reg: Add NL80211_RRF_USER_REGD_NEEDED flag

In order to prevent accidental use of Intelligent Transportation System band (5.9 GHz), we require system integrators to provide custom userspace regulatory database enabling the use of the band. However, drivers that provide their own regulatory database (such as ath9k) would not enable that band

Re: [ath9k-devel] [RFC v2] [resend] ath9k: allow up to 8 access point vifs on DFS channels

Hi Matthias, The patch is working for me, and I am using it, but I could not test Much further since real-life radar situations are hard to produce. Before DFS integration, combinations were less limited. I submitted the patch as a RFC only, because I suspected the DFS people had a hidden reason

Re: [ath9k-devel] [PATCH V2] debugfs: don't assume sizeof(bool) to be 4 bytes

On 14-09-15, 17:39, Arnd Bergmann wrote: > On Monday 14 September 2015 09:21:54 Viresh Kumar wrote: > > diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c > > index b4c216bab22b..bea8e425a8de 100644 > > --- a/drivers/acpi/ec_sys.c > > +++ b/drivers/acpi/ec_sys.c > > @@ -128,7 +128,7 @@

Re: [ath9k-devel] [PATCH V2] debugfs: don't assume sizeof(bool) to be 4 bytes

On 14-09-15, 09:03, Greg KH wrote: > What ever ones you think it is relevant for :) "Relevant" is a relevant term :) So, the patch which defined the type bool as _Bool was added in v2.6.19 :) 6e2182874324 ("[PATCH] Generic boolean") So, I will try at least for v3.10+ as they are used by a lot

Re: [ath9k-devel] [PATCH V2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tuesday 15 September 2015 07:34:38 Viresh Kumar wrote: > On 14-09-15, 09:03, Greg KH wrote: > > What ever ones you think it is relevant for :) > > "Relevant" is a relevant term :) > > So, the patch which defined the type bool as _Bool was added in v2.6.19 :) > > 6e2182874324 ("[PATCH]

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, 15 Sep 2015 10:38:32 -0700 Linus Torvalds wrote: > But that user interface issue doesn't seem to be the case here, an I > can't say that I mind the patch. It looks fairly sane. If Linus is fine with it, I'm fine with it too. But please, next time, go

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, 15 Sep 2015 16:34:47 +0530 Viresh Kumar wrote: > Hi Johannes, > > On 15-09-15, 12:37, Johannes Berg wrote: > > This email has far too many people Cc'ed on it - I don't think vger is > > even accepting it for that reason. You should probably restrict it to > >

[ath9k-devel] 4.4.0-rc1 kernel panic: ath_calcrxfilter+0xea/0x10a [ath9k]

Fatal exception in interrupt on 4.4.0-rc1 when acting as an AP on an amd64 box. Exception is at: ath_calcrxfilter+0xea/0x10a Image of the panic: http://imgur.com/A4WJ5TI Let me know if there's some other place you'd prefer I host that or if more help is required to debug.

Re: [ath9k-devel] [PATCH v2] ath9k: incorrect queue may be stopped/awaken

Hi, Let me explain the patch more thoroughly. We are testing MCC and we've found some issues with the queues handlers, the main problem is that when we transmit a multicast/broadcast frame, where hw_queue is 8 (CAB), we check queue status, which is 2(q), and if it is full and we have to stop it,

[ath9k-devel] [PATCH v2 4/8] cfg80211: reg: Properly handle rules for 5 and 10 MHz channels

Regulatory rules are applied to channels as if the channel is at least 20 MHz wide. This is a problem when dealing with 5 and 10 MHz channels because side channels of a regulatory rule get disabled even when they fall into rule's frequency range. This problem was already fixed in commit

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Tue, Sep 15, 2015 at 6:45 AM, Steven Rostedt wrote: > > Linus, This patch changes a lot of u32s into bools in structures. > What's your take on that? So in general, I'd tend to prefer "bool" to be used primarily as a return value for functions, but I have to say, in the

Re: [ath9k-devel] 4.4.0-rc1 kernel panic: ath_calcrxfilter+0xea/0x10a [ath9k]

some obvious stuff I forgot: dmesg | grep ath [1.378790] ath: EEPROM regdomain: 0x21 [1.378791] ath: EEPROM indicates we should expect a direct regpair map [1.378793] ath: Country alpha2 being used: AU [1.378793] ath: Regpair used: 0x21 [1.380764] ath9k :02:00.0 wlan0:

[ath9k-devel] [PATCH v2 8/8] ath9k: Add support for ITS-G5 band (5.9 GHz)

The patch adds support for Intelligent Transportation System (ITS-G5) band to the ath9k driver. The corresponding channels are allowed only if CONFIG_CFG80211_REG_ITSG5_BAND is set and if the user provides custom regulatory database. In addition, the band is limited to OCB mode. Signed-off-by:

Re: [ath9k-devel] [PATCH v2 6/8] cfg80211: reg: Add NL80211_RRF_USER_REGD_NEEDED flag

On Fri, Nov 27 2015, Johannes Berg wrote: > On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote: >>  >> The NL80211_RRF_USER_REGD_NEEDED flag introduced in this commit >> allows >> drivers to specify that certain band is enabled only if it is >> additionally enabled in user-supplied regulatory

[ath9k-devel] NF calibration and software level simulation of packet errors

Dear all, I have a couple of questions related to the ath9k drivers. 1) I was wondering if it is possible to purposely deactivate the ACK transmission on a per-attempt basis. Specifically, I would like to simulate packet errors at driver level (i.e. software). I already looked at the methods

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

On 15-09-15, 10:04, Steven Rostedt wrote: > On Tue, 15 Sep 2015 14:04:59 +0530 > Viresh Kumar wrote: > > > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c > > index 2614a839c60d..f11e17ad7834 100644 > > --- a/drivers/acpi/ec.c > > +++ b/drivers/acpi/ec.c > > @@

Re: [ath9k-devel] [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

Hi, This email has far too many people Cc'ed on it - I don't think vger is even accepting it for that reason. You should probably restrict it to just a few lists when you resubmit. > The problem with current code is that it reads/writes 4 bytes for a > boolean, which will read/update 3 excess

Re: [ath9k-devel] [PATCH V2] debugfs: don't assume sizeof(bool) to be 4 bytes

On Mon, Sep 14, 2015 at 09:21:54AM +0530, Viresh Kumar wrote: > Long back 'bool' type used to be a typecast to 'int', but that changed > in v2.6.19. And that is a typecast to _Bool now, which (mostly) takes > just a byte. Anyway, the bool type is implementation defined, and better > we don't

[ath9k-devel] [PATCH v2 0/8] Regulatory and ath9k support for ITS-G5 band (5.9 GHz)

This patch series is another attempt to mainline support for ITS-G5 band (5.9 GHz) designated for Intelligent Transportation Systems. Based on the discussion with Jouni [1], this version adds the following restrictions for using the band: 1. Custom reg db must be provided by the user. 2.

[ath9k-devel] [PATCH v2 1/8] cfg80211: reg: Remove unused function parameter

Signed-off-by: Michal Sojka --- net/wireless/reg.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/net/wireless/reg.c b/net/wireless/reg.c index 2e8d6f3..43b3e57 100644 --- a/net/wireless/reg.c +++ b/net/wireless/reg.c @@ -1052,7 +1052,7 @@ static

[ath9k-devel] [PATCH v2 3/8] cfg80211: reg: Refactor calculation of bandwidth flags

The same piece of code appears at two places. Make a function from it. Signed-off-by: Michal Sojka --- net/wireless/reg.c | 91 ++ 1 file changed, 37 insertions(+), 54 deletions(-) diff --git a/net/wireless/reg.c

Re: [ath9k-devel] [PATCH v2 5/8] cfg80211: Add support for OCB-only channels

On Fri, Nov 27 2015, Johannes Berg wrote: > On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote: > >>  #define NL80211_RRF_PASSIVE_SCANNL80211_RRF_NO_IR >> diff --git a/net/wireless/chan.c b/net/wireless/chan.c >> index 59cabc9..b1ab77a 100644 >> --- a/net/wireless/chan.c >> +++

Re: [ath9k-devel] [PATCH v2 7/8] cfg80211: Add Kconfig option for ITS-G5 band (5.9 GHz)

On Thu, Nov 26 2015, Johannes Berg wrote: > On Mon, 2015-11-23 at 19:27 +0100, Michal Sojka wrote: >> This option is meant for use by drivers and other subsystems to >> enable >> support for the Intelligent Transportation System (ITS-G5) band. The >> option depends on CFG80211_CERTIFICATION_ONUS

[ath9k-devel] [PATCH v2] ath9k: Add support for ITS-G5 band (5.9 GHz)

From: Jan Kaisrlik The patch adds support for Intelligent Transportation System (ITS-G5) band to the ath9k driver. Signed-off-by: Jan Kaisrlik Cc: Michal Sojka --- Hi all, in this second version of the patch we removed

[ath9k-devel] Sorry for the "moderation-related" noise

Hi all. In case you wonder about the bunch of older e-mails that just came through the list: There were > 300 mails waiting for moderation (*), most of them because they either were sent from non-members or were addressing too many recipients at once. Since I don't follow ath9k-devel anymore and