Wireshark mailing list archives
Re: wireshark capture/filtering question
From: John Dill <John.Dill () greenfieldeng com>
Date: Fri, 20 Nov 2020 19:02:46 +0000
From: Graham Bloice <graham.bloice () trihedral com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: Re: [Wireshark-dev] wireshark capture/filtering question Message-ID: <CALcKHKrirhvYNqfP+1=sOdLda5GstqvuxMR+WKoEBsvnLV1KVA () mail gmail com> Content-Type: text/plain; charset="utf-8" On Fri, 20 Nov 2020 at 14:49, John Dill <John.Dill () 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. 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. ___________________________________________________________________________ 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-request () wireshark org?subject=unsubscribe
Current thread:
- wireshark capture/filtering question John Dill (Nov 20)
- Re: wireshark capture/filtering question Graham Bloice (Nov 20)
- Re: wireshark capture/filtering question Guy Harris (Nov 20)
- <Possible follow-ups>
- Re: wireshark capture/filtering question John Dill (Nov 20)
- Re: wireshark capture/filtering question Guy Harris (Nov 20)
- Re: wireshark capture/filtering question John Dill (Nov 23)