Yes, unfortunately at least the following dissectors use 'p2p_dir':
ANSI A - packet-ansi_a.c
GSM A - packet-gsm_a.c
GSM SMS - packet-gsm_sms.c
GSM MAP - packet-gsm_map.c
There are messages for which the form depends on whether the message is
being received or transmitted. Since I wrote the dissectors for use at
work the assumption I made was that the SCCP 'source point code' parameter
represents an MSC. All 'directions' are relative to that, for example,
P2P_DIR_RECV in the packet-ansi_a.c dissector means the Mobile Switching
Center (MSC) has received a message from a Base Station Controller (BSC).
I also have a private dissector that sets p2p_dir for use by the above
dissectors.
I believe p2p_dir was suggested to me in the development mailing list
but changing it to something more robust would be great.
Thanks.
-----Original Message-----
From: Jeff Morriss [mailto:jeff.morriss@xxxxxxxxxxx]
Sent: August 10, 2004 6:44 AM
To: Ethereal development
Cc: mlum@xxxxxxxxxxxxx
Subject: Re: [Ethereal-dev] p2p_dir, gsm_sms, and promiscious capturing
Guy Harris wrote:
> On Tue, Aug 10, 2004 at 06:17:10PM +1200, Bruce Fitzsimons wrote:
>
>>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?
>
>
> It's safe, assuming that, once it's been set, no lower-level dissector
> does anything with that flag after control is returned to it.
>
> Passing it forward through private_data is probably cleaner (and makes
> it clearer that the direction can be trusted to be known - using the
> p2p_dir flag doesn't make that clear, as that flag is, in general, *not*
> guaranteed to either be P2P_DIR_RECV or P2P_DIR_SENT).
Note that the SCCP dissector (though not the SUA dissector) has a
preference which allows it to set the P2P direction as well (based on a
preferenced "source point code". I'm not sure if the GSM dissectors
rely on this at all or not, but if you're using SUA instead of SCCP you
may see different (then intended) behavior.
