Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Selecting Decoders from Wiretap

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 10 Apr 2007 01:54:27 -0700
Rolf Fiedler wrote:
Hi,

some time ago I added the EyeSDN trace format to the wiretap library and
it works fine for the main application, ISDN tracing. D channel data is
decoded as Q.931 and B channel data is passed to PPP/IP decoding. All
this works fine.

Now we have added a number of applications:
a) ATM tracing on E1 lines (we have raw cell capture incl. ATM headers)
b) SS7 signalling on E1 lines
c) X.25 on B channels of E1 lines

In each of these applications, Wireshark can not select the proper
decoder because we fail to tell it which decoder to use.

If you have an {ATM, SS7, X.25} capture, is that a characteristic of the file (such that all the packets in the file are {ATM cells, MTP2(?) packets, LAPB(?) packets), or do different packets have different contents (so that a capture can mix multiple types of packet)?

A comment in wiretap/eyesdn.c says:

 * Each Frame starts with the 0xff Flag byte
 * - Bytes 0-2: timestamp (long usec in network byte order)
 * - Bytes 3-7: timestamp (40bits sec since 1970 in network byte order)
 * - Byte 8: channel (0 for D channel, 1-30 for B1-B30,
 *     128 ATM cells, 129 ATM layer indications)
 * - Byte 9: Sender (0 NT, 1 TE)
 * - Byte 10-11: frame size in bytes
 * - Byte 12-n: Frame Payload

which suggests that a capture can mix multiple types of packets, with different channel numbers indicating the type of packet.

Is that the way the ATM tracing is done? What about SS7 (is that MTP2 or some other layer?) and X.25?

If it's done that way, you should use WTAP_ENCAP_PER_PACKET as the encapsulation type, and set wth->phdr.pkt_encap to the appropriate encapsulation value in eyesdn_read() (WTAP_ENCAP_ISDN for ISDN, WTAP_ENCAP_ATM_PDUS or WTAP_ENCAP_ATM_PDUS_UNTRUNCATED with the appropriate pseudo-header for ATM, WTAP_ENCAP_MTP2/etc. for SS7, WTAP_ENCAP_LAPB for X.25 if it's LAPB).

Now my question:
Is there a way to dynamically select the decoder in the Wiretap module?
If I manually select ISUP as decoder (for SS7 traces), I receive
"unknown WTAP_ENCAP 17" (17 is ISDN, which I selected in our wiretap
module).

What I really would like to have is that the user can select the
decoding format depending on the knowledge of the data she captured.

I.e., the file doesn't *specify* what type of data is in the packet?

Is
this possible? Which WTAP_ENCAP is necessary in this case?

At the moment I could specify a different WTAP_ENCAP type for the D
channel, the B channel and for ATM traces. But the trace file does not
contain information about D channel protocol (SS7 or Q.931 for instance)
or B channel protocol (e.g. X.25 or PPP).

OK, so it does specify for ATM, but not for other captures.

What is the best way to solve this? What would be the best WTAP_ENCAP
type for
the D channel,
the B channel and
ATM cells?

For ATM cells, it'd be WTAP_ENCAP_ATM_PDUS or WTAP_ENCAP_ATM_PDUS_UNTRUNCATED with the appropriate pseudo-header.

For the others, there isn't one. Either a new mechanism that allows options to be passed to the Wiretap module would need to be added, with the Eyesdn module specifying an option to select the B-channel and D-channel protocols, or you'd have to, for example, add a WTAP_ENCAP_EYESDN encapsulation, with a dissector that has an option or options to select the B-channel or D-channel protocols.