Guy Harris wrote:
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.)
You mean you don't work on this full time (like it sometimes appears you
do)? ;-)
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").
Yes, MTP2 maps to the data link layer in the OSI model.
Below MTP2 is basically channelizing, framing, and other scary (I'm a
software person) hardware or electrical stuff. Usually if you're
looking at/capturing that stuff you're not overly concerned with what's
in the payload (MTP2+).
If MTP3 were the SS7 equivalent of DLT_RAW, what would raw SCCP be? (I
don't have a use for raw SCCP but I know Navin--the original author--does.)
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?
In fact the LINKTYPE_RAWSS7_<prot> values aren't used as file formats,
only LINKTYPE_RAWSS7 is. The LINKTYPE_RAWSS7_<prot> values are only
used inside of a file of type LINKTYPE_RAWSS7. (It's relatively common
I think to be able to have simultaneous captures running at different
levels, going to the same output--so it's useful to have MTP2, MTP3 and
maybe even SCCP captures in the same file.)
The only reason for the _<prot> values being LINKTYPE_'s is to maintain
one central "numbers" repository: libpcap. Someone (or more than one
person?) suggested that instead of Ethereal maintaining these numbers,
we should just use LINKTYPE_'s. Not having ever been burned by
non-centralized number allocation, I thought "sure, why not?".
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.
You know, someone (Martin?) asked me that question a while ago and my
response was something like "because MTP2 doesn't have a (useful) length
indicator". Now I get it, though: rawss7.length is useless because
PCAP already has the length. <sigh> I'll take it out.