c0rnholio wrote: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.
- 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).
- 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)
- # 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.
- 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).
- noticed servere multicast storms in associated attack
That was the plan. I "scrambled" the packets to avoid noticeable effects on the network though.
cheers
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.