Hi folks -Attached is a small tool called "packetspammer" I just made from ripping bits out of penumbrad, it sends 256-byte broadcast packets using the management interface at a rate you define. It only depends on libpcap-devel to compile.
# packetspammer <wlan0-type-interface> <delay between packets in us> eg # packetspammer wlan0 0packetspammer brings up the management interface and determines which one it is using /sys, the paths in there might need meddling with if the very recent /sys clearout patch stuff is in your kernel, but it is working with Linville's FC7 #3 2961 kernel which is what I am using here. Then it loops using libpcap to spam broadcast packets down the management interface.
So I try packetspammer on iwlwifi and zd1211rw-mac80211: both are associated to a WPA protected network during the test and a second machine in Monitor mode looks on.
* zd1211rw-mac80211: packets spew out at any delay, including 0. Remains associated during the testing. The netdev start and stop stuff must regulate the packet flow. Good!
* iwlwifi: drops dead without dmesg error after 55 - 89 packets (0us - 1000us delay). Association lost, no further packets are sent until the thing is rmmodded, will not reassociate with wpa_supplicant restart unless it is rmmodded and insmodded back in. Even at 1s delay between packets, eventually it falls over. Bad!
Also notice that packets cannot be sent by packetspammer until the interface is brought up, which I guess is reasonable enough, but also I found not until the interface was associated with a WPA network, which is a problem if the plan is to use the injection action to do the work of association in userspace.
I hope maybe this can help validate and find the source of any fragility. -Andy
Attachment:
packetspammer-0.1.tar.gz
Description: GNU Zip compressed data
