various discrepancies in IEEE 802.11 address matching

[infrastation]

I tried to relate the code in gen_wlanhostop() with IEEE 802.11-2012, which happened to be at hand, and could make the following observations:

• The Q_ADDR4 case does not check that the frame type is "data" (the comment says other frame types should not match, but it is wrong to assume that).
• The Q_ADDR1, Q_ADDR2 and Q_ADDR3 cases do not look immediately wrong.
• The Q_RA case comment says "Not present in management frames", which contradicts Section 8.3.3.1 point a), which says: "The Address 1 field of the management frame is the RA (=DA)..."; the code does not seem to be consistent with the spec either; the code tests for the single IEEE80211_FC0_TYPE_DATA bit rather than the 2-bit frame type bitmask, which matches the "reserved" (0b11) frame type as well.
• The Q_TA case comment says: "Not present in management frames", which contradicts Section 8.3.3.1 point b), which says: "The Address 2 field of the management frame is the TA (=SA)..."; the comment says "If the high-order bit of the type value is 0, this is a management frame.", but the code tests for the IEEE80211_FC0_TYPE_DATA bit being set, which either requires a better comment, or a different code.
• The Q_SRC case has the initial comment almost right, except for "data" frames ToDS=0 and FromDS=1 it assumes the MSDU case, in which case address 3 is indeed the SA, but in the A-MSDU case it is BSSID; also for ToDS=1 and FromDS=1 it assumes the MSDU case, in which case address 4 is indeed the SA, but in the A-MSDU case it is BSSID; there may be other discrepancies because the code is quite convoluted.
• The Q_DST case similarly disregards MSDU/A-MSDU difference for ToDS=1; the comment says "If the low-order bit of the type value is 1, this is either a control frame or a frame with a reserved type, and thus not a frame with an SA." — SA is the source address, the actual code tests for IEEE80211_FC0_TYPE_CTL being unset, so this certainly requires at least the correct comment.

This may require generating different filter code for some cases, even more so after relating with 2020 revision of the standard. In this case it would be necessary to add "apply" tests first to make it obvious that the new filter program has the same effect where the effect is correct, or has a different effect where it used to be incorrect.

On a separate note, the current set of frame subtypes in the lexer is incomplete and may require additions to get up to date.