Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] mergecap truncated files

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Tue, 19 Jun 2018 21:03:56 +0200
So Catalin, there you have it. These are the pseudo code of the changes to be made to the CLI tools.
Go ahead and push your changes to Gerrit[1].

Thanks,
Jaap



On 19 Jun 2018, at 09:20, Guy Harris <guy@xxxxxxxxxxxx> wrote:

On Jun 18, 2018, at 9:35 PM, Jaap Keuter <jaap.keuter@xxxxxxxxx> 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