Ethereal-dev: RE: [Ethereal-dev] Patch to expose OPC/DPC from MTP3, SCCP preferences
I will add AT_SS7PC.
Does anyone have any suggestions for PC formatting ?
>From the packet-mtp3.c dissector I will take the following:
ANSI/CHINESE ITU x-y-z where each of x, y and z are 8 bit values.
ITU MTP3 Q.704 does not seem to indicate a format for the PC other
than being a 14 bit value. However, I have seen it represented as
a-b-c where a and c are 3 bits and b is 8 bits.
Our engineers prefer the 14 or 24 bit decimal value as opposed to
any formatting because then there is no ambiguity about the value.
I have also seen:
8.8.8 for 24-bit point codes
3-8-3 for 14-bit
I.e. the '.' versus '-' was supposed to indicate 24 versus 14 bit.
Anybody else have input ?
> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: Wednesday, December 03, 2003 4:19 PM
> To: mlum@xxxxxxxxxxxxx
> Cc: Ethereal
> Subject: Re: [Ethereal-dev] Patch to expose OPC/DPC from MTP3, SCCP
> preferences
>
>
>
> On Dec 3, 2003, at 4:04 PM, Michael Lum wrote:
>
> > Guy could you give me the name of file that I could reference
> > for solution number 2 ?
>
> See:
>
> "epan/packet_info.h" for the definition of the
> "address_type" enum (to
> which you'd add AT_SS7PC or something such as that), the "address"
> structure (which is what's the source and destination address fields in
> the "packet_info" structure are), and the macros for manipulating them;
>
> "epan/to_str.c" (see the "address_to_str_buf()" routine) for
> information on formatting addresses for display in columns;
>
> "packet-atalk.c" for an example of code using
> "SET_ADDRESS()" to set
> source and destination addresses in a case where the address data isn't
> a contiguous chunk of data from the packet;
>
> "packet-ip.c" for an example of code using "SET_ADDRESS()" to set
> source and destination addresses in a case where it is a contiguous
> chunk of data from the packet.
>
> I infer that the the OPC and DPC are displayed differently depending on
> the SS7 variant being used. One way to do that might be to include an
> SS7 variant indicator in the address; another way might be to have some
> way to export the preference setting to the code in "epan/to_str.c".
>
> In the long run, we should probably have some way in which *dissectors*
> can register new address types, so that the code to format them is part
> of the dissector code and can get at the preference setting, and so
> that new address types can be added without having to change
> "epan/packet_info.h" or "epan/to_str.c".
>
> Note also that the conversation code uses "address" structures to
> represent network-layer addresses, so solution 2 would also provide
> some infrastructure for doing SCCP conversations.
