 | 1 | initial version |
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.)
| | 2 | No.2 Revision |
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. 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.)
