> On 18 Jun 2018, at 20:30, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Jun 17, 2018, at 3:00 PM, Catalin Patulea <cat@xxxxxxxxxxxxxx> wrote:
>
>> I'm trying to merge a few pcap files, some of which are truncated. I'm
>> getting this error:
>> $ mergecap -a sip.pcap-201806* -w /tmp/out.pcap
>> mergecap: Error reading sip.pcap-20180616-111355: Less data was read
>> than was expected
>
> That error message translates to "sip.pcap-20180616-111355 is truncated".
>
>> at this point, mergecap stops processing any later files. I would
>> prefer mergecap discard the truncated frame, and continue with next
>> files. I understand this will potentially lose some data, this is
>> appropriate for my application.
>>
>> Is there any way to configure mergecap for this?
>
> No.
>
>> If I write a patch
>> for an optional new command-line flag, is it likely to be accepted?
>
> Possibly, although this would be a feature useful only to handle files damaged by being truncated; there's nothing mergecap-specific about the issue of truncated files, so there's no particular reason why this should be a *mergecap* feature, and there's already a way to deal with truncated files - you could use editcap to read sip.pap-20180616-111355 and write out a file containing all the complete packets in it, i.e.
>
> for i in sip.pcap-201806*
> do
> editcap "$i" "$i".cleanedup
> done
> mergecap -a sip.pcap-201806*.cleanedup -w /tmp/out.pcap
... 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.
Thanks,
Jaap
