Some types of frames disappear after some time

[HeyGF]

Hi, thanks for this nice tool!

I'm running nexmon_csi on ASUS AC86U as a passive sniffer to capture the CSIs from another router that my phone is connected to. It can capture many different types of frames from the router's Mac address. But when I browse websites on my phone, which generates many different types of wifi packets, many different types of frames are missing after some time.

For example, below figure shows that before ~10s, the CSIs are from many different types like 0x80 (beacon), 0x88 (data), 0x94, etc. But after ~10s, many frame types just disappeared, and only 0x88 left after 40s.

I use wireshark on my laptop to monitor the wifi traffic, showing that these different types of frames always exist.

After this happens, even restarting the tool won't help. And I have to reboot the AC86U router.

Does something trigger the tool to only monitor (filter) some types of frames? And why it's stuck to these types and only reboot will help?

Thanks!

[zeroby0]

That's a really nifty plot!

Nexmon_CSI tries to capture all the packets in the air, but it cannot capture everything. The radio is disabled when CSI data is being copied from the wifi chip to system memory, so packets in the air are not captured when that's happening.

So maybe the router isn't capturing other packets when there's a lot of data? You could try filtering for only 0x80 packets and browse to see what happens then.

I've also seen control type packets sent with data headers. When I pinged my router with a very high throughput, the ACK of multiple packets was batched and sent as a data packet. So that could be happening too.

[HeyGF]

Thanks!

"I've also seen control type packets sent with data headers. When I pinged my router with a very high throughput, the ACK of multiple packets was batched and sent as a data packet. So that could be happening too."

The packets captured using other tools like wireshark. We can see other types of frames like 0x80 are sent normally even after 10s/40s.

You could try filtering for only 0x80 packets and browse to see what happens then.

I just did the tests. After the router is stuck, no packets including 0x80 are received if I use the 0x80 frame type filter. If no frame filter is used, then the frames are mainly 0x88 data frames (like the above figure).

After rebooting the router and reload the patch dhd, 0x80 frames are received normally when I use the 0x80 frame type filter (it's also a little weird that there are one frame of 0xB4, 0xC4 and 0xD4 even applying the 0x80 filter):

In summary, when there are a lot of frames (of different types) when browsing, it's weird that the 0x88 data frames seem to be normally received while other types are missing. Not sure if it's because the priority of 0x88 frame filter is set/triggered and stuck for some reason. And only rebooting will help.

I'm checking if it's similar to the AMSDU issue on raspberry pi.

Thanks for any comments!