[Sorry, I didn't mean to start a new thread about this subject... I
just wanted to publish changes I had made before a lot of this debate
got going.]
Richard Sharpe wrote:
OK,
rather than calling it a fake-link, why not a raw capture. We have
precedent from the various raw protocol support on some versions of UNIX
(which unfortunately seems to have meant raw-IP).
The only "problem" I see with that is that it's not quite "raw": each
packet needs to have some kind of header on it (to tell us the length).
But, that's not a big deal... "raw capture" is fine by me.
Secondly, rather than having a 16-bit protocol type, how about a 32-bit
protocol type which would allow us to, say map IP-types and port-numbers
etc without having to resort to more large tables.
I had contemplated whether 16-bits would be enough, but I figured it
would be...
What do you mean about port-numbers?
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?
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?"
I guess that would have the advantage that we could have a more limited
number of cases: 1 case for all protocols that can run over Ethernet
instead of 1 case or each such protocol (That would certainly save on
the "horizontal" explosion of raw protocols...). Is that what you intend?
Wacky (dirty, ugly, horrible but still mildly interesting) idea: put
the (Ethereal) protocol name in ASCII in the packet header:
protocol="mtp3",length=172 . "packet-raw.c" could do a
'find_dissector()' on this string and voila... Hehe, amusing thought,
anyway...
Regards,
-Jeff