This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Different captures from different adapters

0

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 :

  1. Does one of you is able to decrypt packets with one of the above USB adapters? If yes, please give me some details!
  2. Why do I comparatively capture so few packets?

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 www.wireshark.org just when I connect to the AP, I see the DNS request and answers; if I do it 5 seconds later, I don't see anything). And when I try with my smartphone (deconnect and reconnect), I get nothing.

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 (link[0] != 0x80) and (wlan ra 01:23:45:67:89:AB or wlan ta 01:23:45:67:89:AB). It avoids useless beacons and selects only packets to or from the AP.

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:

1. EAPOL        Key (Message 1 of 4)
2. EAPOL        Key (Message 2 of 4)
3. EAPOL        Key (Message 3 of 4)
4. EAPOL        Key (Message 4 of 4)
5. ICMPv6       Multicast Listener Report Message v2
6. DHCP         DHCP Request
7. DHCP         DHP ACK
8. ARP          Who has 192.168.0.1? Tell 192.168.0.19
9. ARP          192.168.0.1 is at *AB:BA:AB:BA:AB:BA*
...
  • Packets 1 to 4 are sent from/to my computer to/from the main (beacons sending 01:23:45:67:89:AB) APs MAC address.
  • Packet 5 is sent from my computer to 33:33:00:00:00:16 (I don't know what that means).
  • Packet 6, being a request, is broadcasted from my computer.
  • Packet 7 comes from AB:BA:AB:BA:AB:BA.
  • Packet 8 is broadcasted from my computer.
  • Packet 9 comes from AB:BA:AB:BA:AB:BA.
  • ...

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's gravatar image

thefiercerabbit
11226
accept rate: 0%

edited 17 Jan '17, 10:46

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.

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).

On an ethernet network, it would be easy to capture packets from or to an IP address.

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...

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).

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.

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?).

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.

(17 Jan '17, 11:28) Bob Jones

One Answer:

1

Does one of you is able to decrypt packets with one of the above USB adapters? If yes, please give me some details!

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.

Why do I comparatively capture so few packets?

There are a number of reasons.
1. Capability differences, as described. If there is traffic that is on the air that only one of them can pickup, then one will see it, the other will not. 2. Receive sensitivity - this depends on the antenna and other factors. If one device has better receive sensitivity, it will be able to pickup frames better. The USB adapters usually have OK sensitivity - often there is not enough room for a good antenna. Also location matters - is the USB adapter stuck behind an open laptop? Or is it out in the open away from reflections and such? So even if both are capable of picking up the frames based on capability (e.g. channel width, guard interval, LDPC setting, frequency, MCS index, etc) one may still be better for capturing frames due to Rx sensitivity.

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.

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?

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%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

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