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] capturing from a named pipe - other file formats

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 15 Jul 2010 16:44:30 -0700
On Jun 14, 2010, at 12:53 AM, Rolf Fiedler wrote:

> At the moment wireshark only supports the libpcap trace file format when 
> capturing from a named pipe or stdin. I would like to extend this to 
> support the EyeSDN trace file format for captures from ISDN interfaces.

If the goal is to support capturing from ISDN interfaces, there's more than one way to do it.

If you know for certain that a given capture will be an ISDN capture, then, if you were to get a DLT_ value for ISDN, the capture could be delivered in pcap format (and you could even perhaps add to libpcap/WinPcap support for capturing *directly* from EyeSDN devices).

The link-layer header would have to include:

	a direction indicator;

	a channel indicator;

followed by the payload (LAPD for D channels, presumably, at least by default; the ISDN dissector currently uses heuristics to try to determine the traffic type on B channels).

If you also want to deliver layer 1 events, I'd ask for a DLT_EYESDN_ISDN link layer, with an additional flag in the link-layer header indicating whether the packet is a layer-1 event or an ISDN packet.

The code to read EyeSDN traffic also has support for LAPB, raw ATM cells, MTP2 frames, DPNSS (is that

	http://en.wikipedia.org/wiki/Digital_Private_Network_Signalling_System

?), DASS2 (again, is that

	http://en.wikipedia.org/wiki/DASS2

?), and BACNET-over-HDLC.  Are those still supported?  If so, and if you can determine at the beginning of the capture whether those are being used or not (so that you don't need per-packet encapsulation type, other than perhaps packet vs. layer-1 event), you could possibly use existing DLT_ values, if they're available and usable for the link-layer type in question, or request new DLT_ values if necessary (as they would be if, for example, you needed to report layer-1 events, or if you needed to supply direction or channel information and the link-layer header defined for the existing DLT_ value didn't include that information).