TL;DR - I Think you may not be authenticating with the AP before trying to replay packets to up the IVs, if you're positive you are, don't even bother reading this lol...
I don't own your card but I own a similar one and have a decent amount of experience Pen Testing Wireless systems. Forgive me if this sounds condescending or anything... I don't know anything specific about your card or its drivers in particular, but I'm simply going to give some trouble-shooting advice as to what you may possibly be doing wrong with respect to your inability to generate new IV's... (since your wireless NIC passed the injection test, it should be fine... my Alfa Awus XXXXXXX was plug-in play... they're extremely Linux friendly.)
OK... anyways, you mentioned you're trying to generate IV's so I'm immediately going to assume you are trying to access a WEP encrypted wireless network. You dropped your card into monitor mode with airmon-ng, you are writing traffic to a file with airodump-ng, and you want to replay arp packets with aireplay-ng. The problem is that if you test this on your home router, it will work perfectly fine, and then as soon as you go to test it in the field/in the lab, everything falls apart. This is because you need to do one of two things:
Either 1) Spoof the MAC address of a legitimate client (one whose DHCP lease is still valid... usually good for a few days, sometimes less, sometimes infinity...)
Or 2) Use aireplay-ng to do a fakeauth with the AP so it thinks you're a client on the router and actually listens to you
The router, by default, ignores packets from anyone it "doesn't know"... meaning someone that hasn't tried to authenticate (successfully?... idk if there is any trickery in the aireplay-ng --fakeauth command or not) with the router within the past few days (or Ever... depending on DHCP lease time) will be ignored. So you can either "authenicate" yourself with the router using a command similar to:
Code:
sudo aireplay-ng --fakeauth 5 -a <AP_bssid> <interface>
and Then do your:
Code:
aireplay-ng --arpreplay -b <AP_bssid> <interface> -x <#of packets per second... default is 500-750... toss to 1000 for better results, if you don't mind bogging their network for 5 min>
(-x is totally optional, just figure'd I'd mention it... unless you're trying to be quite (in which case you should just go All passive sniffing), there's no reason not to crank that number up)
OR, the other way is to spoof the MAC address of a currently connected client (or recently connected such that they're still authenticated) obtained by looking for clients connected to stations in airodump-ng at the bottom (particularly the station you're interested in), and just pass aireplay-ng a "source MAC" address, which I believe is the "-h" or "-c" option (-h is source... but I believe -c is for client at some point for something...). From a Pen Testing standpoint this is the clear choice simply because when an IT admin or simply a home user looks back at any logs they might have kept regarding traffic on their network, they'll see the insane spike in traffic, but it will all appear to be coming from their own machine... no sign of an outside intruder is ever present (other than the conclusions such a spike might lead a knowledgeable person to demise). So, to use aireplay-ng to spoof a client's MAC address in your replay attack, your command might look something like:
Code:
sudo aireplay-ng --arpreplay -b <AP_bssid> -h <connected_client_MACaddress> -x <900> <interface>
The reason this works at home and then not somewhere else is because your router most likely already had your computer in its list of "authenticated" devices and so you were able to skip the MAC spoofing and/or --fakeauth'ing part without any issues. Also, make sure the network you are Pen Testing has a legitimate client connected to it generating some traffic... otherwise it's impossible to do any arpreplaying if there are only beacons coming from the router and nothing to work with. Lastly, once you see a client associated with the AP and are capturing packets with airodump-ng, look into aireplay-ng's --deauth function. I'm not going to sit around and act like I know what's really going on with Everything in the WiFi process... but in My Experience, DOSing a client off the network for 5-10 minutes would usually help result in an arp packet being captured (and therefore replayed) in aireplay-ng upon letting the client reestablish connectivity... maybe that packet is associated with initial connection or re-syncing of sorts... or maybe it was just coincidence... either way this is the technique to capture WPA/WPA2 handshakes so it's definitely worth looking into. Hope this helped, or at least gave you inspiration to keep trying knowing that someone somewhat cares!!! (Made this account just now to post this... this situation was my biggest "WTF AM I DOING WRONG AHHHHH!!!" *pull hair out* moment in all of my wireless pen testing days hahaha.
If you knew All of this and your problem is actually one with your drivers, I am truly sorry I just wasted 5 minutes of your time and 30 minutes of mine lol... Good Luck!!
Oh and just for the record, I've done all my work on Ubuntu, not BT... but for the most part Linux is Linux *shrug* (apparently except drivers though, heh... =p ).
Problems with Alfa Awus 036NHR in BT5R3
Re: Problems with Alfa Awus 036NHR in BT5R3 -- need to spoof client MAC?
Posting Permissions