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.