Manual Control about Sending ACKs
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
Quoted 1 line · Daniel Berger
Thus I deduce ACK sending is completely done in hardware.
Yes, I believe this is the case with all of our supported hardware.
Quoted 3 lines
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
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 6 lines · On Wednesday 22 September 2010 15:02:45 John W. Linville wrote:
Quoted 1 line · Daniel Berger
Thus I deduce ACK sending is completely done in hardware.
Yes, I believe this is the case with all of our supported hardware.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines · Christian Lamparter
Quoted 3 lines
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.
Signature · 1 line
Greetings Michael.
Quoted 10 lines · Michael Büsch
Quoted 7 lines · Christian Lamparter
Quoted 3 lines
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.
Quoted 5 lines
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:
Luis
Quoted 11 lines · Luis R. Rodriguez
Quoted 10 lines · Michael Büsch
Quoted 7 lines · Christian Lamparter
Quoted 3 lines
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.
Quoted 7 lines
Quoted 5 lines
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
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
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
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
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
2010/9/22 Daniel Berger <[email protected]>:
Quoted 22 lines
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 inrx.c(we're checking CRC, length, adressed to us, ...). But, one the other hand,tx.cstates 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.
Quoted 9 lines
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.
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick