Hello, (CC to the author of the gsm_sms.c decoder)
This is my first post, so please bear with me.
I am working on decoding GSM MAP inside SUA (inside SCTP, inside IP).
This is being captured on a Sun machine by snoop. I'm using Ethereal 10.4
I am working on some tweaks to make this all play happily together.
These include:
1. making the SUA decode support SUA 8 (a different data tag).
2. making TCAP register for arbitrary SSNs, rather than a fixed list
3. making p2p_dir settable somehow.
Number 3 is the subject of this email. The problem I am experiencing is
that the packet-gsm_sms.c decoder does not decode the innermost (GSM
03.40) packet of data correctly in all circumstances. This packet has an
indicator to say what type it is, but the protocol overloads the
indicator to have a different meaning depending on the direction of the
traffic (Handset->SMSC or SMSC->Handset).
packet-gsm_sms.c uses the p2p_dir set by packet-frame.c to decide which
direction the packet was flowing. In my case I'm not sure how the
p2p_dir flag value was determined (it doesn't show up anywhere) but its
certainly not right. I'm still considering if this flag should even be
used for this purpose, although I can't see any more reasonable way to
do it.
Regardless I feel this does show up a limitation in that if the
direction cannot be determined then packets will potentially be
incorrectly decoded. This could potentially affect a bunch of protocols.
It would be nice if it were possible to indicate the direction of
traffic flow, perhaps by matching IP addresses based on configuration of
the IP layer?
I'd appreciate peoples thoughts on the matter.
At the moment I'm thinking of a parameter on the IP decoder that would
allow a user to specify a list of definitive source addresses. Its
difficult to stop there though (wildcards, masks etc). I'm happy to
build it.
/Bruce
