[Guy Harris <gharris@xxxxxxxxx>]

On Nov 20, 2020, at 6:48 AM, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:

> I've had some recent discussions about adding some network capture to our avionics data capture dashboard program.  Currently, the architecture uses a Java program as the GUI and a TCP socket interface for playback/record control and data with a C program capturing 1553 data.

"1553" as in MIL-STD-1553:

	https://en.wikipedia.org/wiki/MIL-STD-1553

or something else?

> The C program has the capability of reading from a file or the live card and streaming 1553 packets to file and to the GUI for processing.
>  
> What I would like to try to do is sniff out the packets for Control Display Unit (CDU) key presses and the Display screen data (which includes a 24x15 grid of characters and attribute data for each character).  The initial goal of this is to provide a real time virtual CDU display, and if things go well, store the display and key presses packet data so that during playback of a recording, one can see a virtual display of what happened between what the pilots are doing vs the 1553 data.  All of this display data is on a single port, and we currently have a plugin that processes all the Network Data Objects for that port.
>  
> The idea that was passed around would be to either integrate the packet capture portion in with the existing 1553 data capture program, or integrate the 1553 data capture in with a Wireshark command line tool.

So what is the reason to include Wireshark code into the code path?

The only Wireshark command-line tool that interprets packet contents is TShark (which uses the same dissection engine as Wireshark); what role would it play in this process?

> Another factor they are considering is looking at chapter 10

Presumably that's chapter 10 of MIL-STD-1553 (or whatever standard "1553" refers to).  Not everybody here is familiar with that standard.

> to multiplex the 1553 and ethernet data into a single file format, so that complicates matters further (although that should make the time sync of 1553 and display playback easier).

Chapter 10 is an appendix of MIL-STD-1553B from 1978; I'm not seeing much there about multiplexing, just 10.3 "Multiplex selection criteria".

For a file format containing both 1553 and Ethernet data, one possibility would be to define a link-layer header value:

	https://www.tcpdump.org/linktypes.html

for 1553" and use a pcapng file with one interface using LINKTYPE_ETHERNET and one using LINKTYPE_MIL_STD_1553 (or whatever).
 
> I'm just wondering if anyone here has had experience using Wireshark utilities as a capture interface for streaming filtered network packets to another application, and maybe I can follow in their footsteps.

"Filtered" meaning you only want to see packets that match a filter expression?

> The problem appears to be pretty complex, so hopefully I explained what I want to try to do.  As a first pass, I think my goal will be to see if I can wrangle a simple dashboard application that takes a live filtered stream of packets from dumpcap or tshark, and forward that data to a GUI for display (basically part of the backend for a virtual CDU display).

dumpcap can't do much filtering - it doesn't dissect the content of packets.  (This is intentional; it may have to run with elevated privileges in order to capture on a network interface, and we didn't want to have anything using the Wireshark dissection code run at elevated privileges.)

I don't see where it would do anything more than what your existing C program would do, other than capturing on Ethernet at the same time and combining the Ethernet and 1553 packets into a single pcapng file.

If TShark had a dissector for 1553 (it currently doesn't), it could support a "read filter" to filter the packets.  It's not really set up to write to a file *and* to another program (which it would do over a pipe).