Quote:
|
Originally Posted by c0rnholio
Sorry for the delay, had some work to do...
|
You are my only tester right now, I can't really afford to complain. And I know this takes up quite a bit of time. Thanks.
Quote:
|
- Number of frames written is mainly under 100, some are between 100 and 200, and anly a few (about 10 packets) are 260-263 in both attacks
|
That's not too bad. When there are more than 256 written frames, it means that chopchop/the AP missed the valid frame (above 512 missed two valid frames and so on).
Quote:
- time vary between <1ms and 10ms (from what I see in the sniffer)
- unassociated attack took 1min16sec, associated attack took 1min26sec
|
The times look reasonable. My guess is that the 10ms are due to kernel switching tasks. If you want to play with the timing, there are 3 options, which control the injection rate. Frames are injected in burst and:
- -burst : number of frames in a burst (default 13)
- -bdelay : the delay between two frame in a burst in ms (default 0ms)
- -backoff : the delay between two bursts in ms (default 3ms)
Quote:
- # of packets sent in unassociated attack is: ~2.7 million
- # of packets sent in associated attack is: ~2.3 million
|
Are you sure? Not very important since everything else seems fine.
Quote:
|
- ap respond with an ACK to every wrong encrypted packet!?
|
I have to read the standard about that, but I think stations/AP have to ACK every frame they receive (just to avoid retransmissions). Some kind of knee-jerk reflex buried deep inside the firmware. I'll have to see if it's also working in monitor mode. That would be a nice way to track sniffing/silent stations (though since you need the MAC address, it might not be that useful).
Quote:
|
- noticed servere multicast storms in associated attack
|
That was the plan. I "scrambled" the packets to avoid noticeable effects on the network though.
Thanks for the testing, much appreciated. I will do more testing when I am finished with the hostap patch, and compare with yours. Any feature request for 0.2?
Note: 0.2.1-pre20 is an incomplete dev module. Though that's the one I used for the patch, it still does kernel panic (tested today) if the card is removed while operating (use "cardctl eject" or "state.wlan disable" before removing). Though I backported the patch to 0.2.0 and did not test it much, that should not happen with that version.