Re: Adding pcap-ng pipe support to dumpcap

[Jeff Morriss <jeff.morriss.ws () gmail com>]

On Thu, Aug 31, 2017 at 12:54 PM, Guy Harris <guy () alum mit edu> wrote:

> On Aug 31, 2017, at 3:37 AM, Ed Beroset <beroset () mindspring com> wrote:
>
> > On 08/30/2017 09:31 PM, Guy Harris wrote:
> > > On Aug 30, 2017, at 6:00 PM, Ed Beroset <beroset () mindspring com> wrote:
> > > > but I can't help but think that the general approach you describe is
> the better long term strategy.
> > > Probably.  It means that the interface between *shark and extcap
> programs would be different - but, while having extcap programs behave like
> dumpcap might complicate the extcap programs (although some of the code to
> do that could be in a library used by dumpcap and by extcap programs), it
> might simplify the Wireshark capture code path.
> > I'm not sure that the interface between dumpcap and Wireshark/tshark
> would need to change to accommodate a wider variety of inputs via pipes.
>
> It wouldn't.
>
> The interface between *extcap programs* and Wireshark/tshark would need to
> change if we want to have extcap programs work like dumpcap, so that they
> talk directly to Wireshark/tshark, and write directly to a capture file,
> rather than talking to dumpcap by sending packets over a pipe.  That was
> Stephen's suggestion, and I think it's worth considering.

A counter argument to this would be that there are some advantages to not
using a (temporary) file as the buffer packets.  The ones I've had in mind
for some time are:
* Bug 2234 (filtering tshark captures with read filters (-R) no longer
works) - an Known Problem in our release notes since privsep came in.
* Bug 1650 (dumpcap can remove a ring-buffer file before *shark has read
it; the resulting packet loss is reasonable but error presented to the user
is quite bad).
* Just the general idea of using (slow) files for a buffer.

___________________________________________________________________________
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