Wireshark · Wireshark-users: Re: [Wireshark-users] Need to record bandwidth used by branch office VPN tunnels

[Christopher Maynard <Christopher.Maynard@xxxxxxxxx>]

Laura Chappell <lchappell@...> writes:

> Wouldn't it be best if tshark stopped saving the packets once the statistic
> is obtained for the timeframe? 

Due to privilege separation, tshark isn't actually saving any packets;
dumpcap is.

Some background:
>From Jeff Morriss's comment in bug 2234[1]:

    Yes, this is actually the expected behavior now.  As a result of the 
    work done for privilege separation the (small, reasonable to run 
    setuid-root) tool doing the capturing (dumpcap) is also writing out the 
    files.

    tshark then reads that file in so it can display the output (when not 
    using "-w" to write the file).

Guy Harris opened bug 2743[2] as a potential remedy, but this has yet to be
implemented.

Another potential future solution (that unfortunately doesn't currently
avoid creating a temp file either) would be to have dumpcap[3] pipe the
packets to tshark[4], something like as follows:

    dumpcap -i <n> -q -P -w - | tshark -i - –q 
            –z io,stat,3000,ip.addr==192.168.1.0/24
                           ,ip.addr==192.168.2.0/24
                           ,ip.addr==192.168.3.0/24 > mystats.txt

CTRL+C to stop the capture process manually or use a –a autostop condition
if desired. 

In this case, it's not the first instance of dumpcap creating the temp file
but the second one capturing on stdin, i.e., '-'.  If this were possible
though, it would probably resolve [or help to resolve] bug 1814[5] as well.

And while a successful resolution to bug 2743 would negate the need for
explicit piping, my thought here was that it *might* be easier to make
changes to tshark to avoid using dumpcap when capturing from a pipe, since
that's what bug 2743 proposes that dumpcap does implicitly when tshark is
not writing to a file.  Here we have an explicit pipe though, so *perhaps*
it's a little easier to get this part working at least?  I haven't looked
into what changes would be needed though, so it might end up being just as
much work either way.

Regardless, as others have already mentioned, there are other tools better
suited for this particular job than *shark.

- Chris


[1]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2234#c1
[2]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2743
[3]: http://www.wireshark.org/docs/man-pages/dumpcap.html
[4]: http://www.wireshark.org/docs/man-pages/tshark.html
[5]: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1814