[Rolf Fiedler <rolf.fiedler@xxxxxxxxxxxxx>]

Hello again!

Guy, thanks for your helpful response. Please find my comments below...

> 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).


The file format can potentially mix different frames (like ATM cells and
HDLC frames), but from the application point of view there is no link
where the data is mixed and so one trace file only contains data from
one context.

For SS7 the trace file contains HDLC frames, mostly TUP (telephony user
part) application frames (having MTP2/MTP3 headers).

> 
> > 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.

You are right. We know if its D channel, B channel or ATM, but don't
know which protocol/AAL is used in the stream. It would be good if this
could be configured in Wireshark.

> 
> > 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.
> 

What I would really like is that the user could specify how to decode
the frames. So if I add a new encapsulation, could I then implement
something like this?

My understanding of your proposal is as follows:
- I add a WTAP_ENCAP_EYESDN
- I add a dissector for this
- I add options for this dissector, which would show up under
  Edit->Preferences->Protocols->EyeSDN (basically a combo-box for each
of D channel/B channel/ATM cells stating the desired dissector).
- With this option I could select which dissector the packet is passed to.
- in my wiretap module I always pass to the eyesdn dissector, which then
passes on to the proper dissector.

If the above description is correct, then this would very much fit my
requirements.

To make things worse there are more ISDN protocols (DASS2, DPNSS) which
are not yet supported by Wireshark, but could be added with this scheme.

Can you please confirm if I understood correctly. If yes I will try to
implement this.

Thanks
Rolf