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
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
On Wed, Sep 22, 2010 at 6:54 AM, Michael Büsch <[email protected]> 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
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.
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.
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
2010/9/22 Daniel Berger <[email protected]>:
> 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
On 09/22/2010 10:12 AM, Luis R. Rodriguez wrote:
> On Wed, Sep 22, 2010 at 6:54 AM, Michael Büsch<[email protected]> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
Hi Daniel,
I'm a student from Germany as well and working on a project concerning
industrial WLAN.
We also want to control about the sending of ACKs.
We are using a Atheros card and the ath5k driver.
I'm interested in your experience and of course I will tell you my.
But it can take some time, I'm still in the beginning of the project.
Regards,
Bj?rn
-----Urspr?ngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von Daniel Berger
Gesendet: Mittwoch, 22. September 2010 20:39
An: [email protected]
Betreff: Re: Manual Control about Sending ACKs
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
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
[email protected] might be all we have. Be ready.