[ath9k-devel] Capture A-MPDUs

[ath9k-devel] Capture A-MPDUs

[Astrit Zhushi]

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) being sent from AP to the client are not being captured at
the monitoring node, only control frames (CTS,BlockAck). Of course, if AP
transmits to the monitoring node then aggregates can be captured.

My question is that is this a hardware limitation? I suspect that the card
is not passing to the driver aggregated frames that are not destined to
itself. Does this has to do with any state the card has to keep for
aggregation? Finally, if that is the case can the card be instructed to
pass all aggregated frames without keeping any state?

I am looking at the number of frames that are aggregated on a typical WLAN.
While this can be inferred by looking at BlockACKs, seeing actual
aggregates would be helpful as a sanity check.

Thanks,
Astrit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130806/291e3f1d/attachment.htm 

[ath9k-devel] Capture A-MPDUs

[shinnazar]

 

 

From: Astrit Zhushi [mailto:a.zhushi at cs.ucl.ac.uk] 
Sent: Tuesday, August 06, 2013 6:01 PM
To: ath9k-devel at lists.ath9k.org
Subject: [ath9k-devel] Capture A-MPDUs

 

> 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) being sent from AP to the client are not 

> being captured at the monitoring node, only control frames (CTS,BlockAck). 

> Of course, if AP transmits to the monitoring node then aggregates can be 

> captured.

May be you are missing to set the monitor flags using ?iw? utility. If so, here are some guidelines http://wireless.kernel.org/en/users/Documentation/iw?highlight=%28monitor%29#Modifying_monitor_interface_flags

> My question is that is this a hardware limitation? I suspect that the card is 

> not passing to the driver aggregated frames that are not destined to itself.

> Does this has to do with any state the card has to keep for aggregation?

> Finally, if that is the case can the card be instructed to pass all aggregated 

> frames without keeping any state?

> 

> I am looking at the number of frames that are aggregated on a typical WLAN. 

> While this can be inferred by looking at BlockACKs, seeing actual 

> aggregates would be helpful as a sanity check.

> 

> Thanks,

> Astrit

 

- Nazar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130806/7ab9041a/attachment.htm 

[ath9k-devel] Capture A-MPDUs

[Astrit Zhushi]

On Tue, Aug 6, 2013 at 3:01 PM, shinnazar <seytnazarovsho@ynu.ac.kr> wrote:

> ** **
>
> ** **
>
> *From:* Astrit Zhushi [mailto:a.zhushi at cs.ucl.ac.uk]
> *Sent:* Tuesday, August 06, 2013 6:01 PM
> *To:* ath9k-devel at lists.ath9k.org
> *Subject:* [ath9k-devel] Capture A-MPDUs****
>
> ** **
>
> > 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) being sent from AP to the client are
> not ****
>
> > being captured at the monitoring node, only control frames
> (CTS,BlockAck). ****
>
> > Of course, if AP transmits to the monitoring node then aggregates can
> be ****
>
> > captured.****
>
> May be you are missing to set the monitor flags using ?iw? utility. If so,
> here are some guidelines
> http://wireless.kernel.org/en/users/Documentation/iw?highlight=%28monitor%29#Modifying_monitor_interface_flags
>

I have already set the flags, I can see non-aggregated and control frames.


> ****
>
> > My question is that is this a hardware limitation? I suspect that the
> card is ****
>
> > not passing to the driver aggregated frames that are not destined to
> itself.****
>
> > Does this has to do with any state the card has to keep for aggregation?
> ****
>
> > Finally, if that is the case can the card be instructed to pass all
> aggregated ****
>
> > frames without keeping any state?****
>
> >** **
>
> > I am looking at the number of frames that are aggregated on a typical
> WLAN. ****
>
> > While this can be inferred by looking at BlockACKs, seeing actual ****
>
> > aggregates would be helpful as a sanity check.****
>
> >** **
>
> > Thanks,****
>
> > Astrit****
>
> ** **
>
> - Nazar
>

Thanks,
Astrit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130806/48c9cea6/attachment.htm 

[ath9k-devel] Capture A-MPDUs

[Tsaixiong]

Astrit Zhushi <a.zhushi <at> 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) being sent from AP to the client are not being captured at the 
monitoring node, only control frames (CTS,BlockAck). Of course, if AP transmits 
to the monitoring node then aggregates can be captured.
> 
> My question is that is this a hardware limitation? I suspect that the card is 
not passing to the driver aggregated frames that are not destined to itself. 
Does this has to do with any state the card has to keep for aggregation? 
Finally, if that is the case can the card be instructed to pass all aggregated 
frames without keeping any state?
> 
> I am looking at the number of frames that are aggregated on a typical WLAN. 
While this can be inferred by looking at BlockACKs, seeing actual aggregates 
would be helpful as a sanity check.
> 
> Thanks,
> 
> Astrit
> 
> 
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel <at> lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 

Dear Astrit

I am confronting with the same problem!Can you give some advice on where I 
can capture the control frame in mac80211?I want to confirm the 
receiver ,transimitter and duration of next data frame.
 
Thanks in advance.
Tsaixiong

[ath9k-devel] Capture A-MPDUs

[Kamran Nishat]

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 <ivycx1992@gmail.com> wrote:

> Astrit Zhushi <a.zhushi <at> 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) being sent from AP to the client are not being captured
> at the
> monitoring node, only control frames (CTS,BlockAck). Of course, if AP
> transmits
> to the monitoring node then aggregates can be captured.
> >
> > My question is that is this a hardware limitation? I suspect that the
> card is
> not passing to the driver aggregated frames that are not destined to
> itself.
> Does this has to do with any state the card has to keep for aggregation?
> Finally, if that is the case can the card be instructed to pass all
> aggregated
> frames without keeping any state?
> >
> > I am looking at the number of frames that are aggregated on a typical
> WLAN.
> While this can be inferred by looking at BlockACKs, seeing actual
> aggregates
> would be helpful as a sanity check.
> >
> > Thanks,
> >
> > Astrit
> >
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel <at> lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
>
> Dear Astrit
>
> I am confronting with the same problem!Can you give some advice on where I
> can capture the control frame in mac80211?I want to confirm the
> receiver ,transimitter and duration of next data frame.
>
> Thanks in advance.
> Tsaixiong
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141024/faac51a6/attachment.htm 

[ath9k-devel] Capture A-MPDUs

[Kamran Nishat]

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 <kamran.nishat@gmail.com>
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, 2014 at 1:58 PM, Tsaixiong <ivycx1992@gmail.com> wrote:
>
>> Astrit Zhushi <a.zhushi <at> 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) being sent from AP to the client are not being captured
>> at the
>> monitoring node, only control frames (CTS,BlockAck). Of course, if AP
>> transmits
>> to the monitoring node then aggregates can be captured.
>> >
>> > My question is that is this a hardware limitation? I suspect that the
>> card is
>> not passing to the driver aggregated frames that are not destined to
>> itself.
>> Does this has to do with any state the card has to keep for aggregation?
>> Finally, if that is the case can the card be instructed to pass all
>> aggregated
>> frames without keeping any state?
>> >
>> > I am looking at the number of frames that are aggregated on a typical
>> WLAN.
>> While this can be inferred by looking at BlockACKs, seeing actual
>> aggregates
>> would be helpful as a sanity check.
>> >
>> > Thanks,
>> >
>> > Astrit
>> >
>> >
>> > _______________________________________________
>> > ath9k-devel mailing list
>> > ath9k-devel <at> lists.ath9k.org
>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> >
>>
>> Dear Astrit
>>
>> I am confronting with the same problem!Can you give some advice on where I
>> can capture the control frame in mac80211?I want to confirm the
>> receiver ,transimitter and duration of next data frame.
>>
>> Thanks in advance.
>> Tsaixiong
>>
>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141024/7566ec03/attachment.htm 

[ath9k-devel] Capture A-MPDUs

[Adrian Chadd]

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 <a.zhushi@cs.ucl.ac.uk> wrote:
> 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) being sent from AP to the client are not being captured at
> the monitoring node, only control frames (CTS,BlockAck). Of course, if AP
> transmits to the monitoring node then aggregates can be captured.
>
> My question is that is this a hardware limitation? I suspect that the card
> is not passing to the driver aggregated frames that are not destined to
> itself. Does this has to do with any state the card has to keep for
> aggregation? Finally, if that is the case can the card be instructed to pass
> all aggregated frames without keeping any state?
>
> I am looking at the number of frames that are aggregated on a typical WLAN.
> While this can be inferred by looking at BlockACKs, seeing actual aggregates
> would be helpful as a sanity check.
>
> Thanks,
> Astrit
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Capture A-MPDUs

[Astrit Zhushi]

Hi,

I can successfully receive A-MPDU if the monitoring station is
associated with the AP where the data exchange is happening.

A.

On 24 October 2014 at 14:27, Adrian Chadd <adrian@freebsd.org> wrote:
> 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 <a.zhushi@cs.ucl.ac.uk> wrote:
>> 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) being sent from AP to the client are not being captured at
>> the monitoring node, only control frames (CTS,BlockAck). Of course, if AP
>> transmits to the monitoring node then aggregates can be captured.
>>
>> My question is that is this a hardware limitation? I suspect that the card
>> is not passing to the driver aggregated frames that are not destined to
>> itself. Does this has to do with any state the card has to keep for
>> aggregation? Finally, if that is the case can the card be instructed to pass
>> all aggregated frames without keeping any state?
>>
>> I am looking at the number of frames that are aggregated on a typical WLAN.
>> While this can be inferred by looking at BlockACKs, seeing actual aggregates
>> would be helpful as a sanity check.
>>
>> Thanks,
>> Astrit
>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>