Ethereal-dev: Re: [Ethereal-dev] updated fakelink dissector + (new) README.fakelink
On Wed, 13 Aug 2003, Martin Regner wrote:
As a preliminary comment, this is good, because several of us are wanting
these types of extensions to the libpcap format or a new format to handle
more interesting things.
> I think that it would be good to request a LINKTYPE_ for MTP2 from
> tcpdump-workers and maybe also a LINKTYPE_ for MTP3 as well.
> I will have use for it - and I have seen other people wanting to store
> MTP2/MTP3 in libpcap files.
I agree ...
> For MTP3 you can put in some octets to get MTP3 over MTP2 as an
> alternative to use a special linktype for MTP3, I think.
>
> It is at least more nicer than having to add IP/SCTP/M3UA headers as
> you have right now.
However, we still have to solve the issue of finding the dissector in
Ethereal to dissect the PDUs that are in the file, esp WRT what you
introduce below. Of course, that might mean that we need to restructure
Ethereal and provide other ways to search for dissectors.
> However I anyway want to use something similar to the "fake link"
> dissector since I want to mix several completely different protocols
> in the same file. I also want to be able to put Tag/Length/Value data
> in some of the packets. For example I may want to add some text
> comments to certain frames, and maybe want to add e.g. the "source
> address" for the MTP2/MTP3 messages.
>
> I'm working on putting together the ideas I have, but it will probably
> take one or two weeks before I have some draft, because I have several
> other things I'm working on.
>
> The preferred way of specifying the "link type" in each packet should
> then be to use the libpcap LINKTYPE_ values, so it would anyway be good
> to have a linktype value for MTP2.
>
> In my preliminar ideas there will be several other ways of specifying
> "link types", at least as a temporar solution until a LINKTYPE has been
> allocated from tcpdump-workers (e.g. tcp-port-number, udp-port-number,
> sctp-port-number, sctp-ppi, protocol-name, fake-link-proto-number, ...).
>
> =======================================
>
> Since I'm not finished with the thinking yet I'm not sure exactly how
> my "fake link" will look, but a sample frame could maybe look something
> similar to below.
>
> 0x01 Version byte=1
You might want a version string here ...
> 0x00 Frametype=0 (0=Decode by libpcap LINKTYPE, 1=Decode by
> tcp-port, 2=Decode by udp-port , ...)
Hmmm, you might want more bytes here, and this does not seem to get at
your needs for multiple frame/PDU types in the capture, unless one of the
values here is: 0xFF=frame/pdu type in the frame.
> 0x02 Filtering info=2 (which could mean that source-address-string
> and dest-address-string included as first TLV data)
>
> 0x07 Bitmask: TLV-data-included, Frame is marked, Frame is selected
> ....
>
> 0xA0 0x07 Format-id=0xA007 (The format-id will not be used to decode
> the frame, but could be used to indicate a specific reserved
> format, in this case maybe MTP2 data with some specific TLV
> data; source address, destination address, ...)
>
> 0x00 0xE1 Type-info=0x00E1 (Since the 2nd octet is 0 this is the
> "libcpap LINKTYPE value". Instead of 0x00E1 it should be the
> LINKTYPE value)
>
> 0x00 0x47 TLV-total-length (in the example this example there is
> totally 72 bytes with TLV data)
I like the concept of TLVs here. Is this per-frame data or per-capture
data? Above, you seem to have fields, like the version, that is
per-capture data, but here we seem to have moved to per-frame data.
> 0x03 TAG-SOURCE-ADDRESS (Source address name padded to 20 byte
string - always a null terminated string)
Hmmm, why can't this be part of the TLV data?
Ohh, I see, it is TLV data ...
> 0x14 Len (20 bytes)
> 0x4C 0x4F 0x4E 0x44 0x4F 0x4E 0x2D 0x56 0x4D 0x53 0x2D 0x31 0x32 0x00
> 0x00 0x00 0x00 0x00 0x00 0x00 ("LONDON-MV1-12")
London calling ...
> 0x05 TAG-DEST-ADDRESS (Destination address name padded to 20 byte
string - always a null terminated string)
> 0x14 Len (20 bytes)
> 0x4C 0x4F 0x4E 0x44 0x4F 0x4E 0x2D 0x48 0x4A 0x37 0x2D 0x31 0x34 0x00
> 0x00 0x00 0x00 0x00 0x00 0x00 ("LONDON-HJ7-14")
>
> 0x08 TAG-CICUIT-ID (Circuit id as numeric value)
> 0x02 Len (2 bytes)
> 0x07 0x00 Value=1792 (0x700)
>
> 0x42 TAG-PROTOCOL-STRING (Protocol string padded to 10 byte string
-always a null terminated string)
> 0x0A len (10 bytes)
> 0x4D 0x54 0x50 0x32 0x00 0x00 0x00 0x00 0x00 0x00 ("MTP2")
>
> 0x1A TAG-COMMENT
> 0x0A Len (10 bytes)
> 0x43 0x49 0x43 0x31 0x37 0x39 0x32 0x00 ("CIC1792")
>
> 0x00 TAG-PADDING-OCTET
>
> 0x00 TAG-PADDING-OCTET
>
> The TAG field is 1 or 2 byte long (Tag value 0-127 should be used for
> commonly used TAGs and then one octet is used for the TAG).
> TAG 0 is a padding tag with no length octet.
>
> The LEN field is 1 or 2 byte long (When the length of the parameter is
> max 127 octets then the LEN field will be 1 byte long).
I think this is a good start, and the three or so of us who are
interested in this should discuss it some more and perhaps create a
proposal (maybe even a draft RFC).
People I know who are interested are Guy Harris, Ronnie Sahlberg, Greg
Morris, Martin and myself.
It also happens that SNIA has a group who are trying to put together a
proposal for a network capture repository and we would like to ensure that
they do it the right way. Chris Hertel has expressed an interest in
working with us on this as well.
Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
