On Oct 7, 2003, at 8:01 AM, Jeff Morriss wrote:
I think a conversation is probably the best way to go--MTP3 point
codes are the addresses and xLRs are the "ports", though in order to
do this I think the conversation routines would need to know about
MTP3 point codes as addresses (probably as guint32's so the
conversation code wouldn't have to learn about all the different
variants?).
All you'd need to do to have the conversation code (in the sense of the
stuff in epan/conversation.{c,h}) know about that would be to create an
address type for MTP3 point codes; add an AT_MTP3 (or whatever the
appropriate name is) to the "address_type" enum in
"epan/packet_info.h", have the MTP3 code construct the address
structure appropriately, and use those structures when creating
conversations.
If you add to "address_to_str_buf()" in "epan/to_str.c" code to handle
those addresses, you could have the MTP3 dissector do "SET_ADDRESS()"
calls to set "pinfo->net_src" and "pinfo->net_dst", which would cause
the address columns for packets containing MTP3 to show the point codes
(I assume "DPC" is "Destination Point Code" and "OPC" is "Origination
Point Code") in the address columns. (For SS7-over-IP, I don't know
whether that'd be considered a feature or a misfeature - it might be
nice to have a way of controlling which level of address shows up in
the address columns, both for cases where you have one
network-layer-like protocol, such as MTP3, carried inside other
protocols with their own network layer and for cases where you carry
one network-layer protocol inside other protocols with the *same*
network layer, e.g. various ways of tunneling IP traffic inside IP,
including IP-over-Frame Relay-over-GRE-over-IP-over-Ethernet; people
have sent captures with that....)