["Michael Lum" <michael.lum@xxxxxxxxxx>]

Sorry for reading these emails backward.

The use of GSM SMS, GSM MAP, GSM A, ANSI A all assumed they were being
carried on SCCP or the equivalent.  I do not believe the messages
contain a direction indication, the direction is known by the way
the network is configured and who the sender is.  For instance in the
A-interface case the SCCP links are traditionally point to point SCCP links
between the Mobile Switching Centre (MSC) and the Base Station Controller
(BSC).  When the MSC generates a GSM A-interface message to be sent to
the BSC it knows what fields, as defined by the specification, that it
must/should populate.  In turn the BSC knows what fields it should expect
to decode.  When SCCP is carried over IP and is captured and used in
Ethereal how do you determine the direction?  I created the 'source point
code' field in the SCCP dissector for that purpose.

I wasn't really happy with the solution but hey, I was working in my
spare time.

Thanks, I hope that makes the 'design' a little clearer!

-----Original Message-----
From: Guy Harris [mailto:gharris@xxxxxxxxx] 
Sent: August 9, 2004 11:02 PM
To: Ethereal development
Cc: mlum@xxxxxxxxxxxxx
Subject: Re: [Ethereal-dev] p2p_dir, gsm_sms, and promiscious capturing

On Tue, Aug 10, 2004 at 05:41:57PM +1200, Bruce Fitzsimons wrote:
> 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.

It's probably "right" in the sense that it's either:

	1) P2P_DIR_SENT, meaning that the packet was captured on a
	   point-to-point link in a direction that's considered "sent";

	2) P2P_DIR_RECV, meaning that the packet was captured on a
	   point-to-point link in a direction that's considered
	   "received";

	3) P2P_DIR_UNKNOWN, meaning that Ethereal it wasn't sent on a
	   point-to-point link at all, so that a simple notion of "sent"
	   vs. "received" doesn't apply, or that it was sent on a
	   point-to-point link but the direction wasn't recorded in the
	   file, so it can't be determined whether it was "sent" or
	   "received".

Unfortunately, packet-gsm_sms.c appears to be

	1) assuming that the direction the packet went along the
	   lowest-layer link corresponds to the direction it went in the
	   radio link between the handset and the station, which *might*
	   be true but I'm not sure it's *guaranteed* to be true

and

	2) assuming that such a direction is even *available*, which it
	   is *not* guaranteed to be - you don't get it on Ethernet, for
	   example.

> I'm still considering if this flag should even be 
> used for this purpose,

It shouldn't be used for that purpose.

> although I can't see any more reasonable way to do it.

If there is always a lower-level GSM protocol, in the protocol stack
leading up to SMS, that contains a direction indication that specifies
whether the traffic is to or from the handset, the dissector for that
protocol (or the dissectors for those protocols, if there's more than
one such protocol) should use the private_data pointer in the
packet_info structure to pass a direction indication to subdissectors. 

If there's always a GSM protocol with *some* direction indication, but
it doesn't indicate which direction is to the handset and which is from
the handset, there'd have to be some mechanism to associate, with
packets in a particular GSM flow or circuit, an indication of what
direction is to or from the handset.

If there isn't even that, you'd have to have mechanisms to associate
directions with whatever lower-level protocols the GSM traffic is
running atop - and you probably shouldn't assume there's IP somewhere in
the stack, as it's not inconceivable that Ethereal could someday get
code to read capture files from devices that capture, for example,
on-the-air GSM traffic, with no IP involved.