Wireshark mailing list archives

Re: capturing from a named pipe - other file formats


From: Guy Harris <guy () alum mit edu>
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).
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


Current thread: