On Wed, Sep 10, 2003 at 04:01:00PM -0400, Jeff Morriss wrote:
> Since nobody objected to my email:
>
> http://ethereal.com/lists/ethereal-dev/200308/msg00193.html
...perhaps because they didn't have time to give it the attention it
deserved. Sorry about that (part of the problem is that the thread
mixed the short-term "raw SS7" discussion and various "next-generation
libpcap format" issues - the latter required more of my brain than I had
available at the time; I hope to be able to start thinking about that
again soon.)
The idea seems like a reasonable short-term way of storing SS7 captures
when there's nothing below the specified protocol layer.
In fact, if MTP2 can be thought of as a link-layer protocol like the
various HDLC-based link layers (e.g., LAPB) - i.e., if there're aren't
MTP1 headers of any interest (or if they're generally not seen in
captures except *really* low-level captures, sort of like the physical
link layer Ethernet framing) - then MTP2 really does sound like
something worthy of a link-layer type, and MTP3-without-MTP2 could be
considered an SS7 equivalent of DLT_RAW (DLT_RAW is "raw IP").
I just have a couple of questions:
> about creating both a "raw SS7" dissector while a new more flexible file
> format is developed, here's the "fakelink" dissector again, with some
> major changes:
>
> - renamed to Raw SS7 (yes, it can be used for non-SS7 things, but it's
> named "rawss7" in deference to the flexible file format)
>
> - LINKTYPE_'s have been allocated with tcpdump.org (both for the file
> format and the protocol types)
>
> - the 'rawss7.type' has been increased to 32 bits so that it will
> actually fit any possible LINKTYPE_ values
Why have multiple LINKTYPE_ values for different protocols
*and* type values in the "raw SS7" header for those protocols?
What's the purpose of the length field in the header? The rawss7
dissector appears to put it into the protocol tree, but doesn't fetch
its value and thus doesn't do anything with it.
