Ethereal-dev: Re: [Ethereal-dev] updated fakelink dissector + (new) README.fakelink

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jeff Morriss <morriss@xxxxxxxxx>
Date: Wed, 09 Jul 2003 14:04:14 -0400

[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