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
