On Sun, Aug 13, 2017 at 7:10 AM, Иван Николов <ivannikolov007@xxxxxxxxx> wrote:
> Hello,
>
> I'm working on a way to parse a vendor-specific packets IEEE 802.11 packets,
> in particular I want to analyze packet captures from ESP8266 (the ESP-NOW
> protocol). I wrote a proof-of-concept dissector for the protocol and edited
> the `epan/dissectors/packet-ieee80211.c` file and inserted my dissector
> manually in the `add_ff_action_vendor_specific` function then recompiled
> Wireshark from the modified source. While this did work for me, I can't help
> but feel like this is a problem that could be solved better - right now I
> have to recompile Wireshark from source on every release.
>
> The function I'm referencing has a `switch` statement for the OUI with 2
> cases (OUI_MARVELL and OUI_WFA) and a default case, which has a comment
> "Don't know how to handle this vendor".
>
> I'd like to ask whether the community is interested in a patch, including
> another dissector table for that very purpose - allowing Wireshark users to
> write dissectors in Lua and to not have to patch C code in order to analyze
> traffic, containing unknown 802.11 vendor-specific data.
>
> I'm interested in implementing this functionality, but I'm unsure if I have
> the required knowledge of the inner workings of Wireshark. Moreover, I'm not
> sure if the decision to NOT include such a dissector table is intentional.
>
> I'm hoping someone can point me to the 'correct' way to solve the problem of
> dissectors for vendor specific data, or in case this is not currently
> possible, this post starts a discussion on the topic of whether this is
> needed in Wireshark and how to properly implement this at the architecte
> level.
>
> I previously asked a similar question in the ask.wireshark.org portal -
> https://ask.wireshark.org/questions/56816/ieee-80211-vendor-specific-action
> . It includes an example capture (relevant part starts at packet No. 587).
Was that in add_ff_action_vendor_specific?
Be aware that I am adding an additional WFA subdissector as well (the
code is in review but I have some changes coming), however, there is a
need to make life easier there.
The correct approach is likely to add a dissector table and then
convert existing Vendor specific dissector code in packet-ieee80211.c
to separate dissectors.
Indeed, the whole 802.11 dissector could do with a good cleanup.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
