Ethereal-dev: Re: [Ethereal-dev] updated fakelink dissector + (new) README.fakelink
Richard Sharpe wrote:
On Wed, 9 Jul 2003, Jeff Morriss wrote:
[...]
Of, how about having a variable length type with:
First field being DLT-TYPE
Second field being a sub-type based on that
Third field being ...
Thus, a raw IP capture might have header types of:
0x0006 0x0001 0x0805 <capture-len> <data>
^ ^ ^
| | |
| | +----- IP ...
| +---------- DLT_EN10MB (ethernet II?)
+----------------- 6-bytes total type info
I've been contemplating this, but I don't quite get how it works
(sorry--my inexperience is probably showing).
I see that you're building a path to IP (in this case through Ethernet II).
Do you mean this as a packet-header or file-header?
I would prefer to see it in a per-packet header so that we can have
mixtures of raw PDUs in a capture file, however, that can be handled by
having one DLT-type that says mixed.
How is this path information translated into "Give <data> to the IP
dissector"? Does someone need to know "Okay, he said DLT_EN10MB so
let's set "ethertype" to 0x0805 and call whatever dissector wants that?"
OK, so we need one packet-xxx.c file that corresponds to the raw DLT type
and it walks the path of omitted lower layer headers, selecting the
dissector table each time, and when it gets to the final one, calls the
dissector with a TVB being the PDU we actually have.
Ah, okay, I think I (finally) get it...
Would we really want to put that much intelligence into "packet-raw.c"?
It would have to know, for each protocol, what that protocol routes
things on...
What about leaving the routing in the individual dissectors, like:
packet-raw.c would look at DLT_EN10MB and say, "Okay, I'll pass the rest
of this header + data to the Ethernet dissector (via a new entry point
in the Ethernet dissector).
The Ethernet dissector would, in this new entry point, pick off whatever
data it needs from the header (the next 16 bits--"ethertype"), and pass
the remaining header + data to a new entry point in whatever dissector
those 16 bits indicate (in this case IP).
IP would pick off whatever data it needs (8 bits--"ip.proto") to route
the remaining header + data on...
(Are there any heuristic-only dissectors that this wouldn't work for?)
