Astrit Zhushi cs.ucl.ac.uk> writes:
>
> Hi,
> I need to capture aggregate MPDUs between an AP and a client (both running
iwlwifi driver). I have a monitoring node running Atheros AR9300 (MiniPCIe)
card with a monitoring interface setup. The problem is that aggregated data
frames (A-MPDUs) bei
we saw this but according to some list of iwlwifi driver. AMPDUs are off.
Are u sure, u got BlockAcks from iwlwifi
On Fri, Oct 24, 2014 at 1:58 PM, Tsaixiong wrote:
> Astrit Zhushi cs.ucl.ac.uk> writes:
>
> >
> > Hi,
> > I need to capture aggregate MPDUs between an AP and a client (both
> runni
One more thing did u tried putting your sniffing (monitoring) PC close to
the iwlwifi based device?
On Fri, Oct 24, 2014 at 2:51 PM, Kamran Nishat
wrote:
> we saw this but according to some list of iwlwifi driver. AMPDUs are off.
> Are u sure, u got BlockAcks from iwlwifi
>
> On Fri, Oct 24, 201
Hi,
The Atheros NICs will do A-MPDU de-encpasulation in hardware.
Are you not seeing any RX data frames (ie, individual MPDUs) or are
you seeing the de-encapsulated ones and not the raw A-MPDU itself?
-adrian
On 6 August 2013 02:00, Astrit Zhushi wrote:
> Hi,
>
> I need to capture aggregate
Dear all,
I am looking for information about the compliancy of the ath9k driver to
the EN 300 328 ETSI regulation.
Would someone know if ath9k has already been tested for this regulation?
Is it needed to enable any specific flag in ath9k to guarantee compliancy
to the adaptivity tests describe
Hello,
We study the effects of 802.11n frame aggregation on throughput. We
noticed a
strange pattern in the MPDU loss within an aggregated frame. It seems
that the
second half of the MPDUs (those with higher sequence numbers) in an
aggregated frame
are more likely to be lost. Is this a known fa
How did u determine that? only by looking at the Bitmaps in BlockAcks?
On Fri, Oct 24, 2014 at 9:04 PM, Ali Abedi wrote:
> Hello,
>
> We study the effects of 802.11n frame aggregation on throughput. We
> noticed a
> strange pattern in the MPDU loss within an aggregated frame. It seems
> that the
Hi,
Yes we look at the BA bitmap and also too we have printks in the driver
that
tells us what happened to the MPDUs in an aggregated frame.
Thanks,
Ali
On 24/10/2014 12:13 PM, Kamran Nishat wrote:
How did u determine that? only by looking at the Bitmaps in BlockAcks?
On Fri, Oct 24, 2014
Hi,
I was wondering if someone can help me understand receiver buffer
management on the ath9k driver.
While running TCP experiments using an AP and a wireless node (both
running AR9380 mini PCI-e cards, with PCI-e adapter) I noticed that
TCP was invoking fast retransmit. At the transmitter, the
Has anyone had time to investigate this?
Do I need to write up some scripts to reproduce this
so you can verify it yourself?
Thanks,
Ben
On 10/16/2014 03:41 PM, Ben Greear wrote:
> On 10/04/2014 07:30 AM, Ben Greear wrote:
>>
>>
>> On 10/04/2014 12:46 AM, Sujith Manoharan wrote:
>>> Ben Greear
It's not completely unsurprising - the initial channel estimate and
such is done at the beginning of each packet and stays constant. So if
there's some varying channel conditions that change that during the
duration of a packet, the tail end is going to end up having less SNR
and may end up getting
Hi,
The driver handles some corner case from the hardware where the NIC
indicates a frame is completed but the contents of the frame aren't
what it expects. Ie, the atheros vendor ID isn't in there.
Try printing out the contents of the RX descriptor when that happens
and take a look.
It may just
But for this channel conditions should be changing at the scale of 100
micro secs consistently.
On Sat, Oct 25, 2014 at 12:13 AM, Adrian Chadd wrote:
> It's not completely unsurprising - the initial channel estimate and
> such is done at the beginning of each packet and stays constant. So if
> th
We don't use a rate adaptation at this moment (i.e., fixed rate) and the
setup
is stationary. So we expect to see relatively stable channel
conditions. Even if the channel
conditions change during the aggregated frame. The first half of the MPDUs
have the same chance of experiencing worse chann
On Sat, Oct 25, 2014 at 12:53 AM, Kamran Nishat wrote:
>
> But for this channel conditions should be changing at the scale of 100
> micro secs consistently.
>
> On Sat, Oct 25, 2014 at 12:13 AM, Adrian Chadd wrote:
> > It's not completely unsurprising - the initial channel estimate and
> > such i
15 matches
Mail list logo