[Guy Harris <gharris@xxxxxxxxx>]

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

> 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.

OK, so what programs are involved here?

Is the PCMCIA card something that plugs into the (presumably) MIL-STD-1553 serial bus and captures traffic from it?

If so, is that what your existing 1553 capture C code reads from?

What program sends those records on a TCP socket?  Is that the existing C code?

What program reads from the TCP socket?  The dashboard application?

And are you describing the code that exists *now*, or the code you're talking about that, in some fashion, includes some Wireshark code?

> 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,

BPF doesn't know anything about MIL-STD-1553.  You could write BPF filter language expressions that test fields at particular offsets (or generate your own BPF machine code), but that would only require a small part of libpcap's capability - it wouldn't require any Wireshark code at all.

Or do you mean using BPF to filter TCP packets arriving over, for example, Ethernet?

If your existing program is sending the packets over a TCP socket, and you want to use libpcap/WinPcap/Npcap to capture that traffic and extract it, is there some reason you want to do that rather than just listening on the TCP socket?

Currently, some remote capture protocols are handled in Wireshark by sniffing the network for them and dissecting them within Wireshark, with the dissector proceeding to hand the captured packets within the capture protocol packet to the appropriate dissector, but that's a *HORRIBLY* greasy hack, which would be much better handled by libpcap being able to just listen for that traffic using the regular OS networking stack and hand them to an application (tcpdump, Wireshark, whatever).  That's on my to-do list; step 1 is making rpcap capable of using the newer pcap_create()/pcap_activate() APIs, and then step 2 is to add support for *other* URL schemes for use with other protocols.

> 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,

OK, so you need Wireshark's full dissection capabilities, meaning dumpcap can't do it alone.

> 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.

So the goal here is to add filtering capability to the existing "read 1553 packets and send them over a TCP socket to the display application" data path?

Note that Wireshark isn't required to use libpcap for all its capturing; there's a mechanism called "extcap":

	https://www.wireshark.org/docs/wsdg_html_chunked/ChCaptureExtcap.html

which allows a program to get packets from some source *other* than libpcap/WinPcap/Npcap and feed them to Wireshark's packet capture code.

That *would* require that you get a pcap/pcapng link-layer header type for 1553, but it would mean that you could directly feed a 1553 packet stream to Wireshark/TShark.