See https://code.wireshark.org/review/23065

It could probably use some review for "naming".  I'm not familiar enough with 
the dissector to know if fields/dissector table name makes sense.

In regards to not already having a dissector table, not all developers think 
about it, especially if there is only a case or two.  Then a situation like 
yours comes along, and it gets changed. It also looks like "public fields" may 
need its own dissector table for vendor specific functionality too.

 
 
-----Original Message-----
From: Иван Николов <[email protected]>
To: wireshark-dev <[email protected]>
Sent: Sun, Aug 13, 2017 10:55 am
Subject: [Wireshark-dev] Vendor-specific dissectors for 802.11



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).

Best regards, Ivan


___________________________________________________________________________Sent 
via:    Wireshark-dev mailing list <[email protected]>Archives:    
https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev             
mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to