[Guy Harris <guy@xxxxxxxxxxxx>]

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.