On Wed, Nov 5, 2014 at 11:03 AM, Ben Greear wrote:
> Does not appear to be an AP problem, as ath9k stations to the ath10k AP are
> all
> in the 20ms range.
Ah, ok, I just assumed you were using ath10k as an AP. In that case I
know nothing :)
___
ath1
On Wed, Nov 5, 2014 at 9:39 AM, Ben Greear wrote:
> On 11/03/2014 05:35 PM, Avery Pennarun wrote:
>> On Mon, Nov 3, 2014 at 8:04 PM, Ben Greear wrote:
>>> If I am reading my results right, it takes over 2 seconds to associate an
>>> ath10k station with WPA2 PSK o
On Mon, Nov 3, 2014 at 8:04 PM, Ben Greear wrote:
> If I am reading my results right, it takes over 2 seconds to associate an
> ath10k station with WPA2 PSK on my systems.
>
> I was thinking this should be quite a bit faster than this...
>
> Has anyone done any similar measurements?
I haven't not
On Fri, Oct 3, 2014 at 3:37 AM, Michal Kazior wrote:
> On 3 October 2014 08:39, Avery Pennarun wrote:
>> On Fri, Oct 3, 2014 at 2:10 AM, Michal Kazior
>> wrote:
>>> Was the Macbook Air disconnected cleanly on the AP?
>>
>> In my particular test case, I was
On Fri, Oct 3, 2014 at 2:10 AM, Michal Kazior wrote:
> On 3 October 2014 07:48, Avery Pennarun wrote:
>> Steps:
>> - start capturing packets, either on the ath10k AP itself or a
>> secondary monitor system
>> - on the Macbook Air (which has joined your SSID at leas
Hi all,
We're chasing a problem where, with an ath10k device running as access
point and a Macbook Air as a client, responses to probe requests are
sometimes missed by the Macbook Air because they are delayed for a
long time, and the Macbook has changed channels by the time they come
through.
ath
On Tue, Sep 23, 2014 at 12:06 PM, Ben Greear wrote:
> On 09/23/2014 12:17 AM, Michal Kazior wrote:
>> On 22 September 2014 19:42, Ben Greear wrote:
>>> Has anyone looked into what it would take to use standard host OS's
>>> rate control (minstrel_ht) with ath10k?
>>>
>>> I suspect the ath10k rate
On Tue, Sep 23, 2014 at 12:02 PM, Ben Greear wrote:
> I have not tried 10.2, the latest snapshot I can get is from last
> December, so it does not appear anyone is actively working on it,
> and if it took 8 months to get into the ath10k driver, it must not be
> obviously better??
We tried the 10.
On Wed, Aug 27, 2014 at 2:55 AM, Michal Kazior wrote:
> Avery wrote:
>> Any guesses about why the offchannel time would be too short on ath10k?
>
> Try setting up a larger beacon interval, e.g. 300ms.
wireshark confirmed that the beacon interval was changed, but
offchannel time was weirdly still
On Tue, Aug 19, 2014 at 3:01 AM, Michal Kazior wrote:
> On 19 August 2014 08:30, Kalle Valo wrote:
>> Yes, my understanding as well is that the ath10k firmware is like that.
>> But I'm no firmware expert :)
>>
>> I assume that the 10.x firmware does support hw_scan when in AP mode and
>> we would
On Tue, Aug 19, 2014 at 5:56 PM, Adrian Chadd wrote:
> Yeah, but you have to be careful to not drop any queued frames or
> associated station state. Hence why it's done as a separate vdev,
> rather than being done under software channel change control.
That makes sense. So how doomed am I if I w
On Tue, Aug 19, 2014 at 11:23 AM, Adrian Chadd wrote:
> Yes. The whole point is that the firmware knows about the vdev and you
> set the channel on that. The intention is that there's multiple vdevs
> and if they're on different channels (eg STA + P2P, or STA + STA) then
> the firmware can handle
On Tue, Aug 19, 2014 at 1:50 AM, Kalle Valo wrote:
> Avery Pennarun writes:
>> In the ath9k and several other drivers, commands like the following
>> work while in AP mode:
>>
>> iw wlan0 scan -u ap-force passive
>> and
>> iw wlan0 offchannel 2452 1
Hi,
In the ath9k and several other drivers, commands like the following
work while in AP mode:
iw wlan0 scan -u ap-force passive
and
iw wlan0 offchannel 2452 100
On ath10k (using a driver from v3.15-rc1 as of April 13th), these tell
me the operation is not supported.
Are there any plans to
14 matches
Mail list logo
