[John Dill <John.Dill@xxxxxxxxxxxxxxxxx>]

>From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
>To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
>Subject: Re: [Wireshark-dev] wireshark capture/filtering question
>Message-ID:
>        <CALcKHKrirhvYNqfP+1=sOdLda5GstqvuxMR+WKoEBsvnLV1KVA@xxxxxxxxxxxxxx>
>Content-Type: text/plain; charset="utf-8"
>
>On Fri, 20 Nov 2020 at 14:49, 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.  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.
>> Another factor they are considering is looking at chapter 10 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).
>>
>>
>>
>> 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.
>>
>>
>> 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).
>>
>>
>>
>> Any ideas would be greatly appreciated.  If there's some source files to
>> study, that would be helpful too.  I've only implemented a few packet
>> dissector plugins for various avionics protocols, not gone this deep into
>> the internals.
>>
>>
>>
>> Thanks,
>>
>> John D.
>>
>>
> Hi John,
>
>To clarify, you want to feed the 1553 stream into the wireshark engine,
>apply some engine filtering and then output some products of that to
>another application?

Not exactly.  What I'm looking to do is to merge our existing 1553 capture
C code and wireshark capture code (inspired from tshark or dumpcap) into
the same application.

The 1553 data part would get passed records as is over a TCP socket to a
dashboard application for display (not injected into Wireshark).  This
application interfaces with a PCMCIA card and the 1553 data is stored
in a queue of fixed length records.  Those records are then read and
streamed by a C program using TCP packets to a dashboard application
that reads them, decodes all the data fields and puts them on a GUI for
display.  This application is also capable of writing captured 1553 data
in fixed length records to a file.  The application can also load a 1553 data
capture file and streaming the records to the dashboard application to
simulate a playback of a flight at varying playback speeds.

The packet part of the data would be captured from a mirror port and
get filtered by the bpf capabilities to eliminate packets of non-interest, and
then get passed in some manner to the same dashboard application over TCP.
I have a NDO dissector that can heuristically detect those packets of interest,
like "ndo.id == CDU_DM_Display_Buffer" or "ndo.id == CDU_DM_Key", so I'd
like to use that capability to detect when these payloads of certain packets
are found.

This includes the TCP desegmentation capabilities as well, since the CDU
Display packet is segmented over 3 packets.  Once a complete packet with
the NDOs of interest is detected, the dashboard would get a copy over a
separate TCP stream.  The NDOs would be packaged into new frames and
sent via TCP to the dashboard application for display.

The capture application also needs to take these NDOs of interest when
they are detected, generate frames that can be multiplexed with 1553
data to be saved to file in the chapter 10 format.  chapter 10 format is a
IRIG 106 avionics standard for multiplexing different data modalities,
which I'm planning to use to have a single file to playback the flight.

As a starting point, I'm looking to see if there's a way that I can read
a packet stream, detect NDOs of interests, but instead of writing
dissected information to the screen or a file, I want the output to
be over a TCP socket that's established from the dashboard application.
Think of tshark having a socket waiting for a connection, the dashboard
connects, then starts outputting the filtered packet frames to it in
addition to it's capability to save the frames to a file.  The output file
would be capable of multiplexing the 1553 and network traffic of interest
it sees into a chapter 10 file.

Conceptually, it's kind of like having two tsharks, one for reading the
interface using pcap, using bpf and my plugin dissector to filter for
packets of interest, then outputting new frames of that data over TCP
to another tshark (dashboard) that displays it (prints it out to stdout).

Sorry if it's still not clear.  I'm still kind of trying to work it out as I'm
going and I don't fully understand how tshark and dumpcap and the
pcap library all interact yet.