ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] p2p_dir, gsm_sms, and promiscious capturing

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Bruce Fitzsimons <Bruce@xxxxxxxxxxxxxx>
Date: Tue, 10 Aug 2004 18:17:10 +1200
Guy Harris wrote:

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".
Okay, I agree, its probably best not to toy with a variable that indicates how Ethereal captured something.

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
I've discovered that packet-gsm_map.c does set the direction indicator. And it appears to be doing so correctly (mea culpa, I think one of *my* messages is corrupt). I'm not sure of the basis for this decision but it does appear to work reliably.

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

It shouldn't be used for that purpose.

I'd agree it perverts the nature of the flag. Its a relatively safe hack though, in that I assume it only affects the subsequent layers for decoding?

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.
It does appear that the direction can be determined (which is news to me, so I'm going to research that). There has been a lot of thought put into it.

Thanks for your input Guy.

/Bruce