Jeff Morriss wrote:
>[...]
>> Does anybody have any thoughts on what direction to take with this?
>>
>> I'm leaning towards asking 'tcpdump-workers' for some new LINKTYPE_
>> definitions:
>>
>> LINKTYPE_MTP2
>> LINKTYPE_MTP3
>> LINKTYPE_SCCP (Navin, I assume you want this one? I don't need it)
>>
>> and ditch the "fake link" dissector for now. (But I'd like some level
>> of agreement before doing so.)
>
>Ugh, how quickly I forget...
>
>I need to be able to put both MTP2 and MTP3 in the same file, so just
>getting new LINKTYPE_'s won't work (I gave this same response to whoever
>originally suggested this a while back <sigh>).
>
>Would anyone be upset if I request a new LINKTYPE_ for this "raw"
>dissector and resubmit for inclusion? Maybe with this updated header:
>
>typedef struct _fakelink_hdr {
> /* NOTE: These are in network-byte order. */
> guint16 version;
> guint16 spare;
> guint16 type;
> guint16 length;
>} fakelink_hdr;
>
>Or does anyone have any better ideas (I still think the "path to the
>protocol" idea is too complicated--or else I (still) don't understand it).
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.
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 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
0x00 Frametype=0 (0=Decode by libpcap LINKTYPE, 1=Decode by tcp-port, 2=Decode by udp-port , ...)
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)
0x03 TAG-SOURCE-ADDRESS (Source address name padded to 20 byte string - always a null terminated string)
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")
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).
Then after that we have the MTP2 data.
