Manual Control about Sending ACKs

Manual Control about Sending ACKs

[Daniel Berger]

[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

Hi,

im a Student in Germany currently working on a project concerning
wireless security.
For testing purposes we would like to send ACKs to packets, which
weren't adressed to us, or suppress sending normal ACKs.
I've looked through mac80211's code and found there much, what looks
like the ACK-sending-action is triggered in rx.c (we're checking CRC,
length, adressed to us, ...). But, one the other hand, tx.c states in a
comment
/* TODO: These control frames are not currently sent by
* mac80211, but should they be implemented, this function
* needs to be updated to support duration field calculation. *
[...]
* ACK: 0 if immediately previous directed data/mgmt had
*    more=0, with more=1 duration in ACK frame is duration
*    from previous frame minus time needed to transmit ACK
*    and its SIFS
*/
Furthermore ath9k e.g. write parameters for configuring the sending of
ACKs direct into hw's memory...

Thus I deduce ACK sending is completely done in hardware.
Is this right? Is there any possible solution to my problem of sending
ACKs to 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Manual Control about Sending ACKs

[Daniel Berger]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

Hi,

im a Student in Germany currently working on a project concerning
wireless security.
For testing purposes we would like to send ACKs to packets, which
weren't adressed to us, or suppress sending normal ACKs.
I've looked through mac80211's code and found there much, what looks
like the ACK-sending-action is triggered in rx.c (we're checking CRC,
length, adressed to us, ...). But, one the other hand, tx.c states in a
comment
/* TODO: These control frames are not currently sent by
* mac80211, but should they be implemented, this function
* needs to be updated to support duration field calculation. *
[...]
* ACK: 0 if immediately previous directed data/mgmt had
*    more=0, with more=1 duration in ACK frame is duration
*    from previous frame minus time needed to transmit ACK
*    and its SIFS
*/
Furthermore ath9k e.g. write parameters for configuring the sending of
ACKs directly into hw's memory... and doesn't do much more.

Thus I deduce ACK sending is completely done in hardware.
Is my conclusion and understanding right? Is there any possible solution
to my problem of sending ACKs manually? Would that be fast enough for
the SIFS and other stations' ACK timeout?

I would appreciate a short message to help me out.
Greetings from sunny Germany
Daniel Berger

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Manual Control about Sending ACKs

[John W. Linville]

On Wed, Sep 22, 2010 at 12:39:53PM +0200, Daniel Berger wrote:

> Thus I deduce ACK sending is completely done in hardware.

Yes, I believe this is the case with all of our supported hardware.

> Is my conclusion and understanding right? Is there any possible solution
> to my problem of sending ACKs manually? Would that be fast enough for
> the SIFS and other stations' ACK timeout?

I suspect you need to be looking at hacking firmware.  You might look
at the open-source ar9170 firmware or the b43-openfwwf project.

Good luck!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: Manual Control about Sending ACKs

[Christian Lamparter]

On Wednesday 22 September 2010 15:02:45 John W. Linville wrote:
> On Wed, Sep 22, 2010 at 12:39:53PM +0200, Daniel Berger wrote:
> 
> > Thus I deduce ACK sending is completely done in hardware.
> 
> Yes, I believe this is the case with all of our supported hardware.
> 
> > Is my conclusion and understanding right? Is there any possible solution
> > to my problem of sending ACKs manually? Would that be fast enough for
> > the SIFS and other stations' ACK timeout?
> 
> I suspect you need to be looking at hacking firmware.
> You might look at the open-source ar9170 firmware
> or the b43-openfwwf project.

probably not ar9170 either.
The ACK - mechanism (response control) is mostly hardwired in
the chip, there is not much to control here.

Re: Manual Control about Sending ACKs

[Michael Büsch]

On Wed, 2010-09-22 at 15:45 +0200, Christian Lamparter wrote:

> > I suspect you need to be looking at hacking firmware.
> > You might look at the open-source ar9170 firmware
> > or the b43-openfwwf project.
> 
> probably not ar9170 either.
> The ACK - mechanism (response control) is mostly hardwired in
> the chip, there is not much to control here.

The ack mechanism is implemented in firmware for the b43 chip and I
think it's understood pretty much completely how ACKing works in
the firmware. So you may want to take a look at b43-openfwwf.
The guys who created b43-openfwwf also experimented with this
kind of stuff, so you might want to contact them.

-- 
Greetings Michael.

Re: Manual Control about Sending ACKs

[Luis R. Rodriguez]

On Wed, Sep 22, 2010 at 6:54 AM, Michael Büsch <mb@bu3sch.de> wrote:
> On Wed, 2010-09-22 at 15:45 +0200, Christian Lamparter wrote:
>
>> > I suspect you need to be looking at hacking firmware.
>> > You might look at the open-source ar9170 firmware
>> > or the b43-openfwwf project.
>>
>> probably not ar9170 either.
>> The ACK - mechanism (response control) is mostly hardwired in
>> the chip, there is not much to control here.
>
> The ack mechanism is implemented in firmware for the b43 chip and I
> think it's understood pretty much completely how ACKing works in
> the firmware. So you may want to take a look at b43-openfwwf.
> The guys who created b43-openfwwf also experimented with this
> kind of stuff, so you might want to contact them.

You can also look at ath_hw_set_bssid_mask() for ath5k, ath9k, which
I've documented quite extensively:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/wireless/ath/hw.c;h=a8f81ea09f143cc56c981f80db73469196ddb4c6;hb=HEAD#l26

  Luis

Re: Manual Control about Sending ACKs

[Ben Greear]

On 09/22/2010 10:12 AM, Luis R. Rodriguez wrote:
> On Wed, Sep 22, 2010 at 6:54 AM, Michael Büsch<mb@bu3sch.de>  wrote:
>> On Wed, 2010-09-22 at 15:45 +0200, Christian Lamparter wrote:
>>
>>>> I suspect you need to be looking at hacking firmware.
>>>> You might look at the open-source ar9170 firmware
>>>> or the b43-openfwwf project.
>>>
>>> probably not ar9170 either.
>>> The ACK - mechanism (response control) is mostly hardwired in
>>> the chip, there is not much to control here.
>>
>> The ack mechanism is implemented in firmware for the b43 chip and I
>> think it's understood pretty much completely how ACKing works in
>> the firmware. So you may want to take a look at b43-openfwwf.
>> The guys who created b43-openfwwf also experimented with this
>> kind of stuff, so you might want to contact them.
>
> You can also look at ath_hw_set_bssid_mask() for ath5k, ath9k, which

Just in case I'm missing something:  It doesn't appear that upstream ath5k has any
support for virtual interfaces?  I'm trying to get ath5k working
now, based on my .31 patches...

Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Manual Control about Sending ACKs

[Daniel Berger]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Hi and thank you altogether,
I am now in contact with the current maintainer of openfwwf.
Francesco answered positive.

Furthermore, overlooking their code, my plans really seem possible.
If people here are in interest I may post back experience with this
stuff?

Daniel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Manual Control about Sending ACKs

[Nick Kossifidis]

2010/9/22 Daniel Berger <daniel@dat-berger.de>:
> Hi,
>
> im a Student in Germany currently working on a project concerning
> wireless security.
> For testing purposes we would like to send ACKs to packets, which
> weren't adressed to us, or suppress sending normal ACKs.
> I've looked through mac80211's code and found there much, what looks
> like the ACK-sending-action is triggered in rx.c (we're checking CRC,
> length, adressed to us, ...). But, one the other hand, tx.c states in a
> comment
> /* TODO: These control frames are not currently sent by
> * mac80211, but should they be implemented, this function
> * needs to be updated to support duration field calculation. *
> [...]
> * ACK: 0 if immediately previous directed data/mgmt had
> *    more=0, with more=1 duration in ACK frame is duration
> *    from previous frame minus time needed to transmit ACK
> *    and its SIFS
> */
> Furthermore ath9k e.g. write parameters for configuring the sending of
> ACKs directly into hw's memory... and doesn't do much more.
>
> Thus I deduce ACK sending is completely done in hardware.
> Is my conclusion and understanding right? Is there any possible solution
> to my problem of sending ACKs manually? Would that be fast enough for
> the SIFS and other stations' ACK timeout?
>
> I would appreciate a short message to help me out.
> Greetings from sunny Germany
> Daniel Berger
>

On ath5k (and i think also ath9k) you can disable hw ACKS using the
SW_DIAG register on PCU but i haven't tested it.


-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Re: Manual Control about Sending ACKs

[Daniel Berger]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

Hi Björn,

actually we're a bit short on time and should come to an ending at the
end of october (though ack control is only a part of our topic).
Thus, today we've already worked on this topic and at a first step
suceeded to compile the original stuff for the well-known WRT54GL
hardware and created a new testbed...

For further information me may communicate off list.

Daniel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]