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