0

I'm trying to determine whether a computer capturing WLAN frames on an 802.11n network does this correctly.

I do this by letting one computer (1) generate traffic by downloading some files, and capture that generated traffic. The other computer (2) captures the WLAN traffic generated by computer (1). Apparently I can only save traffic in Ethernet format on computer (1) (although it's sent through my wireless interface). Computer (2) receives traffic on the wireless monitor interface with link type IEEE802_11_RADIO.

This works to some degree. After a while, computer (1) sees the following (arbitrary numbers):

tshark -r /tmp/testcap -Y "eth.dst==[mac NIC] or eth.src==[mac NIC]" | wc -l

gives 3757 packets.

Computer (2) sees the following:

tshark -r /tmp/ctrlcap -Y "wlan.sa==[mac NIC] or wlan.da==[mac NIC] or wlan.ra==[mac NIC] or wlan.ta==[mac NIC]" | wc -l

gives 7234 packets.

One would imagine the number of packets would be the same, but apparently the number of packets differs a lot.

I've been looking for an explanation for this, and I came across something called MSDU aggregation (http://en.wikipedia.org/wiki/Frame_aggregation). However, if I understand correctly, this would imply the number of 802.11 packets on computer (2) would be lower than the number of Ethernet packets on computer (1), which is not the case at all.

Could anyone explain this behaviour? Would it be possible to verify if I'm capturing the right number of packets in another way?

user2862333
  • 145
  • 1
  • 6

1 Answers1

1

I do this by letting one computer (1) generate traffic by downloading some files, and capture that generated traffic. The other computer (2) captures the WLAN traffic generated by computer (1). Apparently I can only save traffic in Ethernet format on computer (1) (although it's sent through my wireless interface).

To quote the Wireshark wiki's page on capturing WLAN traffic:

When not in monitor mode, the adapter might only capture data packets; you may have to put the adapter into monitor mode to capture management and control packets. In addition, when not in monitor mode, the adapter might supply packets with fake Ethernet headers, rather than 802.11 headers, and might not supply additional radio-layer information such as data rates and signal strength. You may have to perform operating-system-dependent and adapter-type-dependent operations to enable monitor mode; information on how to do so is given below.

The key part of the quote here is "In addition, when not in monitor mode, the adapter might supply packets with fake Ethernet headers, rather than 802.11 headers".

On computer (1), you're probably not capturing in monitor mode. It might or might not be possible to capture in monitor mode on that computer; WinPcap, and thus Wireshark, doesn't support monitor mode, so if you're running Windows, you would only see 802.11 headers if you have an AirPcap adapter (separate from the 802.11 adapter over which the packets are being transmitted).

Computer (2) receives traffic on the wireless monitor interface with link type IEEE802_11_RADIO.

On that adapter, you're probably capturing in monitor mode.

The key part of the Wireshark wiki quote here is "When not in monitor mode, the adapter might only capture data packets; you may have to put the adapter into monitor mode to capture management and control packets." This means that the capture on computer (2) may see non-data packets, but the capture on computer (1) probably won't, so the capture on computer (2) may have more packets.

Try, for example:

tshark -r /tmp/ctrlcap -Y "wlan.fc.type == 2 and (wlan.sa==[mac NIC] or wlan.da==[mac NIC] or wlan.ra==[mac NIC] or wlan.ta==[mac NIC])" | wc -l

so that you eliminate non-data packets, such as beacon frames, when counting packets on computer (2).