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).

Regards,
-Jeff




Reply via email to