Ethereal-dev: RE: [Ethereal-dev] Patch to expose OPC/DPC from MTP3, SCCP preferences
Excellent, that's would I was looking for, including the last
bit about conversations.
I'll take a look.
> -----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.
