Revision history [back]

What "iw" command do I need to run to see clients of this AP?

You did not give us enough information to know for sure, but probably no command will help you here. The performance envelope of the capture system has to be at least as big, or bigger, than the traffic you want to capture. With only one side of the communication (the beacon), we know what the AP will do; with an Association Request from the client, we would know what the client under review can do, performance wise, but this is not shown.

The beacon supports HT and VHT, 3SS, SGI, and LDPC.

For HT:

.... .... .... ...1 = HT LDPC coding capability: Transmitter supports receiving LDPC coded packets

For VHT:

.... .... .... .... .... .... ...1 .... = Rx LDPC: Supported

We don't know the client, but that capture adapter is, I think, an RTL8812au(https://wikidevi.com/wiki/ALFA_Network_AWUS036ACH). I have one of these chips:

 #lsusb
 Senao EUB1200AC AC1200 DB Wireless Adapter [Realtek RTL8812AU]

and from iw info it is a 2SS, SGI, but no LDPC (look under capabilities for RX LDPC):

#iw phy phy5 info
Band 2:
                Capabilities: 0x1a72
                        HT20/HT40
                        Static SM Power Save
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        RX STBC 2-streams
                        Max AMSDU length: 7935 bytes
                        DSSS/CCK HT40

                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported

I would suspect that your client under review uses LPDC or is using 3SS to communicate with the AP, but your capture adapter is only 2SS and no LDPC. Most mobile devices are 2SS, so that leaves the probability at LDPC mismatch. However, some clients can do 3SS so it can't be ruled out at this point; in fact, it could be both. In any event, the AP can handle higher modulations than the capture setup so you have to be careful.

How to prove?

1. Check the Association Request of the client and compare these performance-related fields
2. Use a known adapter that can handle this performance envelope, and look at the radiotap header information from the frames that are captured between the client and AP and try to figure out what is unique about them that the 8812au can't pick up

You can also see if you can disable LDPC (very much depends on the AP and client - only need to disable on one of them) and/or allow only 2SS as a test to get the target traffic within the envelope of the test capability. I have not seen any Linux commands that control LDPC capabilities - either adapters have the capability and use it or don't when in monitor mode.