Ask Your Question

Cannot capture unicast WLAN packets from any station

asked 2019-07-06 04:25:00 +0000

esotechnica gravatar image

I am trying to sniff regular data frames over WLAN with Wireshark, but am unable to capture ANY unicast frames at all.

I have created a monitor mode virtual interface (mon0) of my WLAN interface using the iw command. I get broadcast/multicast packets, as well as a ton of management/control frames, but no unicast packets, not even from the capture PC that I am running Wireshark from, let alone from any other WLAN devices on the network.

I am running Arch Linux (Linux 5.0.10) using a TP-Link WLAN adapter with a Qualcomm Atheros AR9287 chipset. I would be grateful if anyone could suggest a reason why this is not working properly?

edit retag flag offensive close merge delete


It is not entirely clear if you are trying to do this, but one suggestion: don't try to capture in monitor mode from an adapter that is also in station/managed mode. The results are often unusual.

Dedicate the interface to capture and then troubleshooting will be easier.

Bob Jones gravatar imageBob Jones ( 2019-07-06 10:14:16 +0000 )edit

Hi Bob, if I try capturing from mon0 when the actual WLAN interface (wlp4s0) is down, I get no packets at all. I'm guessing that mon0 is just a ref to wlp4s0, so when it is down they are both down. So I guess the issue is to somehow set up a monitor mode interface that doesn't rely on wlp4s0 being up. Not sure how to do this as yet, I need to keep fiddling, but thanks for your help.

esotechnica gravatar imageesotechnica ( 2019-07-06 23:44:27 +0000 )edit

Using airmon-ng I have now created a new monitor mode interface (rather than using iw) called wlp4s0mon. This interface is the only interface attached to WLAN card (wlp4s0 no longer exists, confirmed by running 'ip link list'). airmon-ng reported that some processes may be interfering (wpa_supplicant, NetworkManager). These have now all been killed. Running wireshark on wlps40mon I get the same results, just mgmt/ctrl frames, and the occasional broadcast/multicast data frame.

esotechnica gravatar imageesotechnica ( 2019-07-07 00:17:40 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2019-07-07 07:51:39 +0000

Bob Jones gravatar image

updated 2019-07-07 07:59:33 +0000

It's still not clear exactly what you mean when you say unicast; is this ANY unicast traffic, including mgmt/control, or just data frames? If you search this site and the previous version, this issue comes up routinely. Anyway, there are likely two causes for this behavior:

Some adapters are known to support monitor mode but NOT promiscuous mode; this gives the result that only broadcast/multicast (group) traffic is collected. For example, the carl9170 driver for some Atheros chipsets had this issue for many years; it was fixed a year or two ago. The RALink series had this defect roll in and then out through some kernels over the past few years, too - there were a series of 4.x kernels where it was stuck in this state. For instance, I still have trouble updating CentOS kernels sometimes because I think they backported the driver into their 2.x and 3.x series long term kernels. I found that selecting the checkbox for promiscuous mode has no effect here in any case - the driver either passes up the unicast frames or doesn't when in monitor mode. I haven't found a wifi driver in monitor mode on Linux where this works.

Mgmt/control and group data traffic is usually sent at lower modulations than unicast data traffic, so if the capture system does not have the same or better performance envelope you may miss these high speed unicast frames. The 9287 is a bgn/2SS/SGI capable device according to wikidevi and that should be enough for most 2.4 capture.

This also assumes that you are on the correct channel, devices are close enough, not using bonded channels, etc.

How to discriminate between the two cases? If you have NO unicast traffic of any type - including mgmt and control traffic, then it is likely a driver issue. Options are to upgrade/downgrade the driver to find one that might work or just replace the hardware. WiFi adapters are cheap.

If you see some unicast traffic for hosts but not of type data, suspect that the modulation is too high for the capture system or you are too far away to capture it. This has a distinctive signature in the trace file as you will see ACKs for the host under review; we can then presume that the data frames were really there, just not picked up. Solution here is either: upgrade capture hardware or reduce the system capability by dumbing down the AP (e.g. disable 802.11n, SGI, etc.)

edit flag offensive delete link more


Hi Bob, by unicast frames I mean looking for any 'useful' data frames carrying TCP/IP traffic that are not broadcast/multicast. To find this, I used the filter 'wlan.fc.type==2' to show only 802.11 data frames. This filter shows only broadcast/multicast, and also 'Null function (no data)' unicast frames, whatever they are...

However, with your definition of unicast I actually do see unicast traffic. I see acknowledgement frames, CTS, RTS, etc between my phone and the AP. So this seems to indicate that there is no problem with monitor mode? I will try reducing the AP capability down and let you know what happens.

esotechnica gravatar imageesotechnica ( 2019-07-07 10:47:16 +0000 )edit

Success! By disabling SGI and setting to b/g mixed mode, I can now see everything. Thanks so much for your help.

esotechnica gravatar imageesotechnica ( 2019-07-07 11:19:20 +0000 )edit

With unicast control frames present, it sounds like a modulation issue of higher speed unicast data frames. Force the AP to only 802.11bg and see if things improve. Suggestion: setup a simple ping stream to the wireless client from the wired side so you know you have traffic generated to the client, produced at a fixed interval, at a fixed size (Linux default is a continuous ping, but windows needs a -t option or it only does 4x ICMP echo requests then stops). I have heard (never experienced first hand) that some adapters might support some advanced modulations in managed mode (i.e. as regular client) but when in monitor mode, they only support basic 802.11bg (or 802.11a, as appropriate). Maybe that is the case here?

What is the AP model? What are its capabilities? Verify receive signal strength of the AP and the wireless client, too ...(more)

Bob Jones gravatar imageBob Jones ( 2019-07-07 11:23:15 +0000 )edit

It's certainly interesting that in monitor mode, it can only capture b/g traffic and yet can capture 802.11n in managed mode... Or can it? is it possible that the capture WNIC is a bit flaky? That is, even though it is an 802.11n capable card, is it actually using 802.11n in managed mode, or is it dropping to some lower mode (b/g). Is there any way that I can tell from Wireshark output whether data frames were transmitted at 802.11n mode in managed mode? (I think this may not be possible, because running Wireshark on a managed mode interface will not have radiotap headers).

The AP model is a TP-link TL-WR841N. All of the configurable items are as follows:

  • Mode (bgn or bg) - set to bg currently
  • Region - Australia
  • Channel - 9
  • Channel width - 20MHz
  • Transmit power - high
  • SSID
  • Enable broadcast SSID - true
  • Enable ...
esotechnica gravatar imageesotechnica ( 2019-07-08 05:50:48 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-07-06 04:25:00 +0000

Seen: 2,136 times

Last updated: Jul 07 '19