Ethereal-dev: Re: [Ethereal-dev] updated fakelink dissector + (new) README.fakelink
Jeff Morriss wrote:
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?)
Of course, doing this would involve creating new "sub protocols" (that
contain just whatever each protocol needs to route to the next protocol)
for every protocol we would want to use... And then we'd have to add
intelligence to deal with these new "sub protocols"?
In reality it would be simpler to just write out (the complete but fake)
protocol headers for each protocol.
That makes me like the "allocate a number for each protocol we want to
use raw" method all the more... (How many protocols would people really
want to store raw anyway? I suspect the number wouldn't be all that
large...)
Or am I [still] missing how to build a path to protocols?
