Hi all, I have a small project which needs to constantly capture packets from or to my AP. This works pretty well whenever I launch the script with my PCI WiFi adapter (Intel Corporations Wireless 7265) on my laptop. However, I cannot obtain the same results when capturing with my USB adapters. I own two USB adapters: the famous TP-LINK TL-WN722N (firmware Atheros AR9271) and a cheap AliExpress one (firmware Ralink MT7601U). Both accepts monitor mode. So I tested close from the AP and from the client, the three adapters capturing and starting at the exact same moment, for 30 seconds or so. More than 340 packets captured from my internal adapter, and just above 100 packets for both of the two USB adapters. In some other situations, I think the gap is even more obvious. More strangely, even if I do capture the 4 eapol packets of the handshake, I am unable to decrypt the rest of the packets if there are from the USB adapters (I can when they come from my PCI card). And I tried to tick/untick the Assume packets have FCS condition, and played with the Ignore protection bit toggle without success. So, two main questions :
EDIT 1:#YouMayCallGhostbusters The 5GHz is deactivated, and the 2.4GHz fixed in 802.11n mode (no b/g). Whenever I use the Ralink adapter as a client connected to the AP, then I can capture from the Atheros adapter and decrypt without any issue. Now, if the client is my Intel card, I can only decrypt the first packets exchanged with the AP (for instance, if I ping When I perform the capture with my Intel card, I decrypt every client (from the Ralink, Atheros or my mobile phone adapters). Is the Pairwise Transient Key (PTK) unchanged if there is no disconnection of the client, or can it be renegotiated? If it can, is it adapter dependant? EDIT 2:I think I finally understand what is going on. My project uses dumpcap and tshark. The former captures, filters and pipes raw data to the latter which decrypts and filters DNS packets. Since everything has to be run by a Raspberry Pi, the less packets on the pipe, the better. So my idea was to use a capture filter like this I captured every packet my card is sending or receiving when it connects to the AP. It clearly appears that the AP uses more than one MAC address. The schema is as follow:
Since packet 9, every packet directed to the outside world will be send to 192.168.0.1, aka AB:BA:AB:BA:AB:BA. I guess the AP has several interfaces and dispatches clients on them. When I'm lucky, the client directly talks with 01:23:45:67:89:AB and my capture filters works properly. When I'm not, I do not capture any data. On an ethernet network, it would be easy to capture packets from or to an IP address. However, I don't think the same is possible on a WLAN network, since you have to decrypt the packet first to get this information (correct me if I'm wrong). Does this mean I have to capture every single packet on the channel? I guess that's what a connected client usually do anyway (right?). Thank you very much for your answers Bob. Your wisdom is more than welcome! asked 13 Jan '17, 16:37  thefiercerabbit edited 17 Jan '17, 10:46 |
One Answer:
Yes, it is routine to decrypt wireless traces with the Intel and the Atheros chipsets listed. In fact, that Intel chipset is quite nice - it can pick up 802.11a/b/g/n/ac, 2x2:2, with LDPC. The Atheros, described here: https://wikidevi.com/wiki/TP-LINK_TL-WN722N, is listed as 802.11b/g/n, 1x2:1. The Intel, described here: https://wikidevi.com/wiki/Intel_Dual_Band_Wireless-AC_7265_(7265NGW), is listed as 802.11a/b/g/n/ac 2x2:2. Notice they have very different capabilities. Based on the capability differences (and there are others not listed here) it would seem natural that you will see variation in what you are able to capture. I do not have any experience with that MT chipset so can not comment on what it's capabilities are.
There are a number of reasons. A common complaint here is that 'I cannot decrypt'. To be able to decrypt, one needs many things and a very common root cause is not decryption capability at all, it is actually capturing data frames to decrypt. I assume you have started here: https://wiki.wireshark.org/HowToDecrypt802.11, but even then, if you get the 4-way handshake of EAPOL frames, you may still not have any real data to work on. You are seeing these effects with your good comparison study - different adapters bring in different things. So what we really need to do is match the capture capability with the device capability under review. As a simple test, reduce the capability of the AP under test to 802.11b/g only. No 802.11n, no WMM, no 40MHz, just plain-old slow 802.11b/g. Set the two adapters on the configured channel, and the general results should then be consistent from capture if you have decent signal strength (Rx RSSI). Have a client connect, and you should then start to pick up EAPOl frames, and further 802.11 data frames. Then proceed with decryption. This is walking - then to start running, increase the capability of your AP and try again until it breaks. But don't run until you can walk.
Correct, the key is usually unchanged if the client never disconnects. However, some systems have a session timeout and they will force a unicast rekey from time to time, sometimes hours, days, sometimes never. Some systems have no way to configure it so who knows what it would do. I have never heard of it being adapter dependent. Your whole issue is matching capture capability with traffic in question. If you want more evidence, provide some sample traces and we can dissect. answered 14 Jan '17, 03:43  Bob Jones edited 14 Jan '17, 11:18 Indeed it was a capture issue, since my capture filters were to selective. (15 Jan '17, 03:35) thefiercerabbit |
In my model, a separate interface would be like a separate SSID, so for a given AP, this would usually be a separate bssid. The order and number of mac addresses in the 802.11 header is dependent on frame type and other options. However, for data, the BSSID will always be there. This presentation I found on the web has some examples of addressing near the end (http://www.studioreti.it/slide/802-11-Frame_E_C.pdf).
Some what true if you have a proper capture setup. Not so if you are on a switched network and trying to collect other hosts' packets...
True, to get IPs, you do need to decrypt. Can you use MAC addresses? That may help you determine what is what first to reduce load. However, when routing, the mac of the router will be involved so may not uniquely identify the true end host without the IP.
Actually, we capture on all channels sometimes at the same time. For a stable installation in a fixed environment it may be OK, but nearly all 802.11 devices communicate in one way or another on many channels under certain conditions. For instance, roaming studies require multiple channels to be collected so we can see how a client moves from one channel to another.
One major issue with what you are doing is the likelihood of packet loss. If you lose some eapol frames, you won't be able to decrypt. The probability of lost wifi frames is not zero, not even near zero. Can you tolerate that in your application? You may find wired captures are better for this reason.