Wireshark-bugs: [Wireshark-bugs] [Bug 8594] Adding support for IEEE-802.11ad protocol at the cur
Comment # 37
on bug 8594
from Jalil Moraney
Hi,
I pushed the code through Gerrit:
https://code.wireshark.org/review/#/c/632/
Comments regarding previous issues:
> It is based of final 802.11ad spec (available on ieee website ?)
The first patch was based on the 9th draft (IMO the last as well) of the
standrad.
I checked manually to see if something changed, not sure if covered everything.
> "this" in "I don't know how this could achieved" being "have the dissectors
> for radio metadata pass that information to the 802.11 dissector", or "this"
> being "assume the frame isn't a 60 GHz frame"?
this = have the dissectors for radio metadata pass that information to the
802.11 dissector.
> May be add a preference to force decode as DMG Packet
Another thing that I don't know how to do.
> Also there is some (minor) warnings when build with Clang analyser
> Unused offset - in some places
Fixed, while commenting out the offset assignment. (If not accepted, please
offer another fix).
> add_ff_beacon_interval_ctrl and add_ff_beacon_interval_ctrl_detail is the
> some code ? (only arg for get value)
Fixed.
> Why in dissect_ieee80211_extension get cc and dis value directly ? (no need
> to pass in add_ff_beacon_interval_ctrl_detail
Fixed.
> There is no a bitmask error in Sector Sweep ? (between Direction and CDOWN)
True, fixed.
> for beacon Interval Control, it is no possible to split flag in 2 group ? (a
> group with 2 bytes and other group with 4 bytes ?) (i known there is not yet
> FT_UINT64 Bitmask...)
This one is pretty problematic, there is a:
field spawning bits 7 till 9 (preventing splitting to 1 and 5 byte splits).
field spawning bits 15 till 18 (preventing splitting to 2 and 4 byte splits).
field spawning bits 20 till 26 (preventing splitting to 3 and 3 byte splits).
field spawning bits 31 till 36 (preventing splitting to 4 and 2 byte splits).
field spawning bits 317 till 42 (preventing splitting to 5 and 1 byte splits).
The current situation is the best format I managed to have.
> other bitmask issue in Tag : DMG Capabilitites (148) about Maximum SC/OFDM
> Rx / Tx and Total Number of Sectors / RXSS Length)
True, fixed.
> For DMG Operating, not need to display bitmask (for PS Request, Min....)
Removed.
> There is also some Malformed packet (see frame number 31022... (Action No
> Ack))
As I said before, I truly believe these packets are indeed malformed.
> And there is also some trailing whitespace
Removed.
Thanks,
Jalil
You are receiving this mail because:
- You are watching all bug changes.
