["Martin Regner" <martin.regner@xxxxxxxxx>]

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.