Hi,
Yes, I do agree with the reformulation you made of my need.
By the way that's finally what I did as a hack, I added a Dissector Table for the X25 "x.25.lcn" field in the packet-x25.c code , inspiring me from what is done for the "spi" table.
Then I could get this table in my lua script, and attach my dissector for the particular virtual circuit where my protocol is.
At least it works for my need... I don't realize how "ugly" it is.
Another way I know is to make a short PostDissector in which I use the "data.data" and "data.len" extractor , I build a new tbv thanks to these 2 fields,, and I call my Dissector on this rebuilt tvb.
This works also, but in that case there is 2 tvb on the "Packet Bytes" view and a "Duplicate" on the "Packet Details" view.
From: Guy Harris <guy@xxxxxxxxxxxx>
To: Sandwood Sandwood <keysandwood@xxxxxxxx>; Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Thursday, 29 September 2011, 19:36:56
Subject: Re: [Wireshark-dev] How to make a LUA written dissector appears in the "Decode As" Widget ?
On Sep 29, 2011, at 1:29 AM, Sandwood Sandwood
wrote:
> I am not in any of the case, my protocol is running on top of X.25 .
The "Decode As" widget includes no code to support X.25, so, in your case, there is no way to make any dissector, whether C or Lua or whatever, to appear in that widget.
> I checked the implementation of the X.25 dissector, for the payload, the dissector checks if it might be an IP, then OSI CLNP , then the heuristic dissector (we can't neither write heuristic dissector in LUA), then if nothing match, invokes the raw data dissector.
Then, if your protocol could have a heuristic dissector, what you need is support for heuristic dissectors in Lua. Having a heuristic dissector figure out what protocol is being carried over X.25 is more convenient than having to tell Wireshark what's carried over X.25.
> More generally I presume I can't be the first to need to "Decode the raw data with whatever Dissectors I
want"
What you need is not "decode all raw data in this capture with a particular dissector that I choose"; for example, if the dissector you want itself has a payload that it shows as raw data, that won't work right. (Your dissector might not happen to have that problem, but a general mechanism has to work in the general case, not just in your case.)
What you need is, ideally, "dissect the traffic on this particular X.25 virtual circuit with one of these dissectors", where "these dissectors" are dissectors that don't require and expect their PDUs to be carried on a particular protocol (yes, those exist). "Dissect any unknown data over X.25 with one of these dissectors" would probably be an adequate substitute in most cases.
