On Nov 20, 2020, at 6:48 AM, John Dill <john.d...@greenfieldeng.com> 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).
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
