Aircrack-ng forum
General Category => General help => Topic started by: bush5150 on October 03, 2016, 04:29:36 am
-
Hello,
I'm struggling to figure out how to fix my issue. After a full day of searching the internet, I'm at a loss. Here's a synopsis of my issue:
I am operating the aircrack suite in Linux Mint 18, which is based of Ubuntu 16.04. I am unable to get my network interface to detect client stations on my target AP using airodump-ng. I have an X-box, 2 Androids, and 2 laptops connected to it via WPA2. My AP is a Belkin SURF F9K1001. I'm curious on network security and have a decent grasp of the basics. I love to tinker.
My WiFi NIC is an internal Qualcomm Atheros AR242x / AR542x Wireless Network Adapter, as reported with lspci. It's stock with my laptop (Sony Vaio VGN-N220e). Upon further investigation using dmesg | grep "ath5.*chip, I've identified my chip as an Atheros AR5414 which belongs to the AR5006X chipset. It's definitely ath5k. I've seen users reporting success with this adapter/chip and it's on the list of successful cards with aircrack tools. It passes the packet injection tests. I've also tried running Kali Linux USB Live to see if that would remedy it. Other remedies include: updating kernel to 4.7.5, full-upgrade, and updating linux-firmware.
Occasionally (and I mean very rare), some client stations will appear with a "not associated" to BSSID. I've tried running the same channel as my router, as well as using my router's MAC directly (it's the AP). It still doesn't show any client stations when I know that there are. I know that it somehow "works" because when I send a deauth signal to the AP, the devices disconnect and reconnect. Still, I can't see any of the client stations. The network is not "hidden" and displays correctly using either airodump or wash. I've scoured the web looking for a solution and it appears to be a fairly common one, yet I haven't found a solution that works.
Here's some system info:
$ iwconfig
enp2s0 no wireless extensions.
lo no wireless extensions.
wlp6s0 IEEE 802.11 ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:off
$ lspci | egrep -i --color 'network|ethernet'
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 PCI-E Fast Ethernet Controller (rev 16)
06:00.0 Ethernet controller: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) (rev 01)
$ dmesg | grep "ath5.*chip"
[ 24.214554] ath5k: phy0: Atheros AR5414 chip found (MAC: 0xa0, PHY: 0x61)
$ lsmod | grep ath
ath5k 139264 0
ath 24576 1 ath5k
mac80211 524288 1 ath5k
cfg80211 430080 3 ath,ath5k,mac80211
I have a question about the last one. Is this indicating that mac80211 is loaded? Would this pose a conflict with the card, as it's an IEEE card (checking output of iwconfig)? It's my understanding that mac80211 and ieee80211 can't be loaded at the same time. I've had success with injection without any changes to the kernel. Would this affect my NIC and/or be the cause of the client stations not reporting? I'm curious on your thoughts on this...
-
As explained in multiple posts, it might be because those clients are 802.11n or ac and in this case, I know your card is a 802.11bg only and will only see 802.11bg clients.
-
That's not the case here. I tested it last night and I could see the MAC's for my Android phones with a general airodump-ng query. They were listed as non-associated clients even though they were connected to my router (on the far right, my router's name was listed as probe). When I did a specific query on the router with airodump-ng, they weren't listed, even after letting it sit for 10 minutes. Why can I see them in a generic query but not a specific? If they were 802.11n, I wouldn't see them at all, but I do, so they must be either 802.11b/g.
-
>>That's not the case here.
Hold on - too early to make this call.
>>I tested it last night and I could see the MAC's for my Android phones with a general airodump-ng query.
Not sure I know what a 'general' query is. I run airodump-ng sometimes with only a channel option, and sometimes with a --bssid, --netmask option set to limit what I see. Exactly what commands do you run for general and specific cases?
>>They were listed as non-associated clients even though they were connected to my router (on the far right, my router's name was listed as probe).
It seems obvious to me the capture capabilities are not up to par. You are seeing probes, and only probes, which are most likely broadcast, hence the tool shows as unconnected. Probes typically transmit at much lower rates than could be capable, so in fact you could have issues picking up 802.11n/ac frames and still see these. The question is do you see unicast frames - and apparently you do not. Most unicast frames are data or qos-data, and go at much higher rates.
>>When I did a specific query on the router with airodump-ng, they weren't listed, even after letting it sit for 10 minutes. Why can I see them in a generic query but not a specific?
Don't know the difference from your definition.
>>If they were 802.11n, I wouldn't see them at all, but I do, so they must be either 802.11b/g.
Not sure I understand this either - it's almost never all or none. Even if the device is 802.11ac, and you can only sniff at 802.11a capability, you would still some frames. Probably no data frames, but still 802.11 ACKs, maybe some RTS/CTS, eapol. Depends. But nothing, not very likely.
At first blush this looks like promiscuous mode is not supported on your adapter. To prove, take a short capture of traffic around you with tcpdump/dumpcap/wireshark, and do you see unicast frames? Do you see data, qos-data, Null, qos-Null frames? If you only see broadcast/multicast frames, then this is the issue and it is common. Otherwise, post the trace if you can and we can take a look.
-
General query:
$ airodump-ng wlan0monIt's general because I'm not targeting anything specific, I'm just listening to everything. Lately, I can see a TON of clients that are not associated in the bottom portion of the output from airodump. Before I couldn't see any clients. At least I'm making progress.
Specific query:
$ airodump-ng wlan0mon --bssid <my AP mac> --channel <my AP channel>I'm setting it to specifically listen to the AP. When I target my specific AP, I don't see any clients listed.
My card doesn't support 802.11n. It is only capable of IEEE 802.11b/g per the manufacturer white sheet. Because of this, I shouldn't see the 802.11n devices at all, only other 802.11b or g devices.
My card, chipset, chip is listed as a supported adapter on aircrack's list (http://madwifi-project.org/wiki/Compatibility/Atheros) (madwifi's). Many people have reported success with this particular adapter. As far as promiscuous mode, I believe people wouldn't have success in using aircrack if that was the case... Nevertheless, I'll reboot into Kali and do the capture with wireshark.
Update:
My card does support promiscuous mode. I can enable and disable promiscuous mode by running:
# ip link set wlp6s0 promisc on
Here's the output from netstat (note the "P" flag for WiFi wlp6s0):
# netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
enp2s0 1500 0 0 0 0 0 0 0 0 0 BMU
lo 65536 0 13939 0 0 0 13939 0 0 0 LRU
wlp6s0 1500 0 1635 0 0 0 1723 0 0 0 BMPRU
I also ran wireshark with unicast capture filter ("not broadcast and not multicast") and was picking up traffic. I could see the Destination and the Source. More importantly, I could see the AP and my Android (communication is using 802.11g according to the header/radio information). I pulled up a lengthy YouTube video on my Android and left it streaming to see if my laptop would see the signal and it did (I don't see it as tcp, though, it shows ack's. I don't know if that's an issue, as wireshark and network sniffing is new to me). I've attached the trace. I replicated the same steps with airodump-ng running and I couldn't see my phone listed as client. I have a question about wireshark/sniffing. If I was running wireshark, should I have been picking up signals from all the routers/clients in the area, not just my phone and AP? (When I run airodump-ng, I can see all the AP's in the area, including routers and WiFi hotspots/tethers. Should I have been able to do the same in Wireshark? If I run without the filter, I can see them all when I select wlan from the Wireless menu).
-
>>Because of this, I shouldn't see the 802.11n devices at all, only other 802.11b or g devices.
This isn't true - you will see frames sent by that host at modulations that can be received by your capture interface. The bulk of data would likely be sent at the higher 802.11n/ac rates, but you would still likely see ACKs, CTS/RTS if in use, etc. So define 'shouldn't see at all'. If the airodump-ng tool requires data frames then your statement may be correct as the device would not show. But that is a specific tool requirement - change tools, and it may not hold. Also note that all radios have a Tx rate selection algorithm, so if you degrade signal strength enough, the device will communicate with the AP at lower rates so may be picked up by your sniffer. It's a moving target.
>>My card does support promiscuous mode. I can enable and disable promiscuous mode by running:
Good test to try, but unfortunately, this really has no effect on the wireless driver. Try it: with wireshark running, toggle the mode. Do you see a change?
>>I also ran wireshark with unicast capture filter ("not broadcast and not multicast") and was picking up traffic
OK - good - rules out promiscuous mode issues. This is the most common cause for me when I observe the symptoms that you have.
>> I could see the AP and my Android (communication is using 802.11g according to the header/radio information)
Good - the communication that you reference is for the frames that are visible - see all the ACKs? Each one of these is likely generated by a data frame, that you don't see. The data frame probably went at an 802.11n rate, but the ACKs go slower. I see Block Acks, and if you look at the beacons and association frames (not in the trace) you could work out if the device is using n rates by the presence and info in the HT information element.
>>(I don't see it as tcp, though, it shows ack's. I don't know if that's an issue, as wireshark and network sniffing is new to me
Maybe. If encrypted, you would not see TCP unless you decrypted the traffic. The TCP traffic would be in data or qos-data frames, which we don't see. Root cause is as MisterX says for this, mismatch in modulation because you can't pick up the high datarate frames with that capture device.
>> If I was running wireshark, should I have been picking up signals from all the routers/clients in the area, not just my phone and AP?
Yes, certainly. If they are on the channel and with range, they would be picked up. I don't know the internals of airodump-ng, but I would suspect it is just reading frames through libpcap or some other capture library and handling them. Wireshark does use libpcap and displays them in the tool.
So why does your device not show as connected? This is a question for looking in the code - or MisterX could just tell us - what does airodump-ng need to determine that a device is connected? Does it use data frames to pull out the bssid and populate the table? If so, we know why: modulation differences. If not, we still have to figure out what is going on.
-
I did some further tinkering. I set my AP to be strictly 802.11g and started YouTube on my Android (attempting to rule out the issue as 802.11n modulation differences). Even with AP at 802.11g, I still can't see the Android as a client with airodump-ng, although wireshark sure was lively (rapidly hit 15k lines). I'll keep fiddling with it, I know the answer's on its way.
-
I messed with it some more tonight. I opened up 2 terminal windows and ran
# aireplay-ng -1 1 -a <my bssid> wlp6s0monin the first one. This sent association requests to the AP, which returned successful.
In the other window, I ran
# airodump-ng wlp6s0mon --bssid <my bssid> -c 4
and surprise, surprise, I could see my own computer's MAC in the bottom portion of the window associated with the AP. I tried browsing on my other computer and on my Android, but I still couldn't see them in the bottom window. I'm excited that I could at least see something in the bottom portion of airodump-ng.
I'm still tinkering with it. Could it also be a driver issue? If so, does anyone know a good place to find drivers for regression testing?
Update:
Figured out regression in kernel (drivers).
-
Hi I am having the same problem I have the same card. How were you able to resolve the issue and get it working?