Wireless Partial Virtual Bitmap

can you provide a small sample pcap?

Trace is here:

https://www.cloudshark.org/captures/169a75f46227

Two packets - a beacon with TIM IE, and a PS Poll frame.

For this example, this is what I have for the TIM map:

     length  15
     offset  4
     pvm     200000000000000010002000
     Bytes:  [12] 8...19
     Bits:   64...159
     pvm as decimal: 9903520314283042199461437440

AID 64 -> 00000100 AID 72 -> 00000000 AID 80 -> 00000000 AID 88 -> 00000000 AID 96 -> 00000000 AID 104 -> 00000000 AID 112 -> 00000000 AID 120 -> 00000000 AID 128 -> 00001000 <--- device 132, per AID in PS-Poll AID 136 -> 00000000 AID 144 -> 00000100 AID 152 -> 00000000

None of the anonymizer tools seemed to work on wlan addresses. I had to edit hex manually. Know of a tool like tracewrangler for 802.11 capture files?

Bump.

I ran into this again at a customer site last week with a large wifi infrastructure - more than 1200 APs. I have to feed the packet captures into OmniPeek as it decodes the actual AIDs in the TIM map. Any tips for Wireshark, or would this be a new feature request to enhance the TIM IE decoding?

Would a Lua post-dissector creating up to thousands of individual pseudo-fields out of the individual bits of the TIM submap help you? Display filters do not support arithmetic to calculate offsets and protocol fields cannot be organized into arrays.

Or, as I think about it, rather a duplicate copy of the original bitmap which would be left-stuffed with 0s to allow use of a fixed offset, so for AID 132, you could always use xxx.xxx.my_bitmap[16:1] & 8

Or, as I think about it, rather a duplicate copy of the original bitmap which would be left-stuffed with 0s to allow use of a fixed offset, so for AID 132, you could always use xxx.xxx.my_bitmap[16:1] & 8

This sounds like it would do. What I observe is something like this...

1. There is WiFi data loss
2. So I ... capture WiFi traffic
3. Notice client stops sending PS-Poll frames for a period off time

So root cause of data loss is that no data is sent FromDS for this period, as client is not requesting it. But it's not really root cause: client will only send PS-Poll if informed that data is buffered at the AP with the TIM map entry, so to figure which device is at fault, we need to look at the TIM map to see if the AP is indicating data is waiting. If the bit is set, and no PS-Poll, it's a client issue. If not set, then need a wired trace to prove wired data arrives at AP, but it does not set the TIM map.

So a Lua dissector, as you describe, would allow me to filter by PS-Poll and then by Beacons that had this bit set, so Wireshark will easily show periods of no PS-Poll - and then whether there are beacons or not during that period.

I have not done any Lua with Wireshark before, so sounds like I need to get on it. I'll start the Lua tutorial for a dissector and see how far I get.