Re: Adding pcap-ng pipe support to dumpcap

[Ed Beroset <beroset () mindspring com>]

On 08/30/2017 07:58 PM, Stephen Donnelly wrote:

> Why pcap-ng specifically? Although pcap-ng is higher featured than pcap, it is not Wireshark's internal representation. 
> Pcap-ng is merely the default output format.

I don't know about other people's desire for this, but here's mine:  I 
am working on a Raspberry Pi based sniffer tool for IEEE 802.15.4 
traffic and want to be able to have the Pi serve up sniffed packets to 
an instance of Wireshark on another machine.  Rather than fiddle with 
pcap, it seemed to make sense to me to use pcapng as the output format 
for the Pi-based sniffer.  It was only after I had finished that, that I 
realized that pcapng was not supported via a pipe.

> Since Wireshark has the ability to detect and read multiple formats already in wiretap, why not leverage that?
>
> At the very least extcap tools should be able to supply data in any format understood by wiretap, but since the extcap 
> data currently goes via dumpcap (maybe not sensible either?) they are restricted to pcap only and have to convert to 
> that internally, potentially losing information.

Yes, exactly the situation.  So I've created a patch which works for my 
immediate needs, but is rather hack-ish and ugly for any other, at least 
in part due to some of the factors you mention.

> Wouldn’t it be better for the capture tool to indicate which of the wiretap formats it intends to use, rather than 
> switching from one fixed format to a different fixed format? This would then support both pcap and pcap-ng 
> intrinsically, as well as all other formats.

One problem is that as dumpcap is currently written, it treats files and 
pipes very differently.  Part of that appears to be due to the fact that 
Windows treats them very differently, but I can't help but think that 
the general approach you describe is the better long term strategy. 
There are some limitations.  Specifically, pipes don't allow random 
access, so any file formats that currently require that would need to 
either be rewritten or omitted for the pipe-able formats.

Might be doable in that way, but it would require a lot of re-engineering.

Ed
___________________________________________________________________________
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