I agree the best way would be to track the connections--there's a
comment about this in the dissector now:
case MESSAGE_TYPE_CC:
/* TODO: connection has been established; theoretically we could keep
* keep track of the SLR/DLR with the called/calling from the CR and
* track the connection (e.g., on subsequent messages regarding this
* SLR we could set the global vars "call*_ssn" so data could get
* sub-dissected).
*/
I think a conversation is probably the best way to go--MTP3 point codes
are the addresses and xLRs are the "ports", though in order to do this I
think the conversation routines would need to know about MTP3 point
codes as addresses (probably as guint32's so the conversation code
wouldn't have to learn about all the different variants?).
packet steve wrote:
A heuristic dissector would be difficult. A better solution is to track
of the SCCP connections. SCCP tries hard to save bytes: Few messages
contain both source and destination reference numbers. For RANAP, the
SCCP Connection Request comes from the radio network (UTRAN) and
contains a UTRAN local reference number. The subsequent SCCP
Connection Confirm has both core network and UTRAN reference numbers:
these are key values for the connection, though you'll probably also
want to track MTP3.
DATA FORM 1 will contain RANAP messages.
On Oct 6, 2003, at 8:29 AM, Michael Lum wrote:
There is a problem with the RANAP dissector in that it
will only dissect packets that have the correct SSN.
However, RANAP, and A-interface (BSSAP/BSAP) protocols
use connection oriented SCCP. Most of the messages do not
contain an SSN field.
The following messages are used:
UNITDATA
Connection Request
Connection Confirm
Connection Refused
DATA FORM 1
RELEASED
RELEASE COMPLETE
Only the UNITDATA and Connection Request contain an SSN field.
I presume at least one of those other message types contains payload
to be dissected as, for example, RANAP, even though they contain no SSN.
What is the best solution for making sure the dissector gets all
the messages?
Either
1) make the dissectors in question heuristic
or
2) add support for some notion of an SCCP connection that includes
the ability to attach a dissector to the connection.
There are two mechanisms that could be used for that notion of a
connection:
1) conversations, for protocols where packets contain identifiers
for both endpoints;
2) circuits, for protocols where packets contain a circuit ID
value rather than endpoint identifiers.