Re: mergecap truncated files

[Guy Harris <guy () alum mit edu>]

On Jun 18, 2018, at 9:35 PM, Jaap Keuter <jaap.keuter () xs4all nl> wrote:

> ... so hardening against truncated files is already a feature of editcap, which could be extended to the other 
> command line tools.
> Spitting out a line of stderr and keep going would be a possible course of action for mergecap.

I wouldn't call it "hardening"; it just means that the main processing loop of editcap is

        while (reading a packet succeeds) {
                process the packet
                write the resulting packet out
        }
        if (it failed due to an error rather than an EOF)
                report the error

rather than

        while (reading a packet succeeds) {
                process the packet
                write the resulting packet out
        }
        if (it failed due to an error rather than an EOF) {
                report the error
                remove the file to which we were writing
        }

just as the main reading loop of Wireshark is

        while (reading a packet succeeds)
                add the packet to the packet list
        if (it failed due to an error rather than an EOF)
                report the error

rather than

        while (reading a packet succeeds)
                add the packet to the packet list
        if (it failed due to an error rather than an EOF) {
                report the error
                close the capture and revert to the splash window
        }

What we could do is have the main loop of mergecap be

        while (we think we still have packets to read) {
                for (all files that haven't gotten an EOF or error and for which we don't have a packet buffered up) {
                        try to read a file from that packet;
                        if (that failed) {
                                if (it failed due to an error)
                                        report the error;
                                mark the file as having gotten an EOF or error;
                        } else
                                note that we have a packet buffered up for that file;
                }
                for (all packets we have buffered up)
                        pick the appropriate packet, write it out, and note that we don't have a packet buffered up 
from its file;
        }

For TShark, the only pass for one-pass processing, and the first pass for two-pass processing is *already* something 
like

        while (reading a packet succeeds)
                print stuff out from the packet
        if (it failed due to an error rather than an EOF)
                report the error

so all we'd need to do is make sure that, for two-pass processing, we don't skip the second pass if we got an error on 
the first pass.

The same applies to capinfos, except capinfos doesn't have two-pass processing, so it probably doesn't need any change.
> Thanks,
> Jaap
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe