Martin Regner wrote:
Jeff Morriss wrote:
[...]
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.
Yes, but then it becomes tricky to determine if what you're looking at
was monitored at MTP2 or MTP3 ("Is it a fake MTP2 header or a real one?").
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.
Does anyone have any objection to doing both? E.g., near-term have a
fake-link (possibly renamed to "rawss7"?) file format while a newer,
more flexible format is developed?
(In this case it might not be necessary to get a LINKTYPE_ for each
protocol but just one for the file format?)
