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.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_________________________________________________________________
Share your photos without swamping your Inbox. Get Hotmail Extra Storage
today! http://join.msn.com/?PAGE=features/es
