ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: [Wireshark-dev] Is there an alternative to using hash tables in packet-ieee80211

From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
Date: Wed, 10 Apr 2019 09:10:30 -0700
Hi folks,

I have come across a number of situations where I have used hash
tables (wmem_map_new[_autoreset]) to maintain information about
stations.

This has mainly been when dealing with S1G but also SAE.

When I see the appropriate information in BEACON frames (or in other
frames), and this is usually IEs that assert the sending station is an
S1G STA or is SAE capable etc) I add that STA to the hash.

Later, when it matters, I look the STA up and can do the right thing, mostly.

The problem that arises is that you do not always see the BEACON or
other frames in the capture, and this can cause malformed packet
exceptions.

One way around this is to add preferences that allow the user to
assert that all frames in a capture are S1G or SAE or whatever.

However, I wonder if there are any other ways of dealing with this.

One example is that Association Responses differ in the Fixed Fields
between normal 802.11 and S1G (they removed the AID).

While this might be handled easily when we have an S1G radiotap header
defined, there might still be captures that do not have such a header.
Another approach I thought of was:

When starting to process the AID field in a Reassociation Resp, check
to see if the rest of the TVB parses as a series of TLVs, and if so,
the AID is not present. Or perhaps do it the other way around, since
the AID field is two bytes in length (and today has some restrictions)

Can anyone think of other approaches.

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者)