Guy Harris wrote:
On Sep 12, 2003, at 11:27 AM, Jeff Morriss wrote:
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.
Yes, that sounds similar to the physical link-layer Ethernet framing.
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.)
From a quick look at
http://www.protocols.com/pbook/ss7.htm
it looks like a transport-layer, or connection-oriented network layer,
protocol. If the former, it'd be DLT_TCP, except that there's no such
thing as DLT_TCP; if the latter, there isn't any direct equivalent in IP
land.
Well, SCCP classes 0 and 1 are not connection-oriented but classes 2 and
3 are. I've seen SCCP called both transport-layer and network-layer.
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.)
Simultaneous captures on the same link, or on different links?
If they're on different links, that'd be something that "libpcap TNG
format" would do with a multi-interface capture; unfortunately, libpcap
TNG format doesn't exist yet (except as collections of requirements and
ideas in people's heads and occasional mail messages).
If they're on the same link, I'm curious why there'd be more than one
capture on the same link.
Usually it would be capturing on different links--or at some
higher-layer (maybe even at the application). Because MTP2 SS7 links
are slow (48000, 56000, or 64000 baud) and for redundancy, no one ever
has just one link. Plus, MTP3 allows its users to load-share among
links, so monitoring just one link is usually useless (unless you're
looking at a low-level problem).
For now, the protocol type is necessary, but it's not really a LINKTYPE_
value - tcpdump.org can maintain other values as well, so perhaps
they're better assigned as SS7TYPE_ values, in which case they could
start at 0.
I agree it's not really a LINKTYPE_ value--though the argument has been
that there was plenty of address space for LINKTYPE_'s (so why create
another numbering scheme). I'm fine with either one...
The other thought I had was whether there might be other uses for "PCAP
embedded in PCAP" which is essentially what LINKTYPE_RAWSS7 becomes when
the "length" is dropped. I also wondered whether this could be done
directly in wiretap instead of creating a "packet-rawss7.c"; I think it
could be, but it's probably much simpler to do it in "rawss7".