Open mruprich opened 1 year ago
Thank you for reporting this bug, it reproduces as described.
@infrastation Tried a little bit of debugging, I think the problem is in the find_header() function. In sf_find_end, we expect that find_header will return HEADER_DEFINITELY:
if ( find_header( p, bufpos, num_bytes,
first_time, 0L, &hdrpos, &hdr ) != HEADER_DEFINITELY )
goto done;
But HEADER_DEFINITELY is never set in find_header function unless there are at least two packets:
if ( next_header + PACKET_HDR_LEN < bufend )
{ /* check for another good header */
extract_header( p, next_header, &hdr2 );
if ( reasonable_header( &hdr2, hdr.ts.tv_sec,
hdr.ts.tv_sec + MAX_REASONABLE_HDR_SEPARATION ) )
{ /* a confirmed header */
switch ( status )
{
case HEADER_NONE:
case HEADER_PERHAPS:
status = HEADER_DEFINITELY; <----- only when there is a next_header
*hdrpos_addr = bufptr;
*return_hdr = hdr;
Only HEADER_PERHAPS is set for the first packet:
case HEADER_NONE:
status = HEADER_PERHAPS;
*hdrpos_addr = bufptr;
*return_hdr = hdr;
break;
So at the end of the function:
if ( status == HEADER_PERHAPS && saw_PERHAPS_clash )
status = HEADER_CLASH;
return status;
Status is always HEADER_PERHAPS. Not sure if the solution would be to simply assume that HEADER_DEFINITELY could be returned instead since saw_PERHAPS_clash is 0?
Thank you for looking into this. A pcap savefile with one packet is a valid file and as far as the man page and the command-line options go, there seems to be no fundamental reason to require more than one packet to process pcap savefile(s) as described. So ideally it would be nice to have this edge case bug fixed. However, if due to implementation details fixing the bug would be too difficult, at the very least it would be appropriate to document it and to print a more useful error message.
The error appears even when the captures are merged with a different tool like mergecap
$ file merged-with-mergecap merged-with-mergecap: pcapng capture file - version 1.0
If you do:
$ mergecap -F pcap -w merged-with-mergecap one-packet-capture ten-packet-capture $ file merged-with-mergecap merged-with-mergecap: pcap capture file, microsecond ts (little-endian) - version 2.4 (Ethernet, capture length 262144) $ tcpslice merged-with-mergecap -w merged-capture
With a pcap file (11 packets), no error.
So two issues have come up here:
Hi guys, just checking whether there is some update here. Is there a consensus on what would be the best approach?
Perhaps updating the man page could be the easiest starting point.
Apparently, tcpslice also fails to handle correctly an input file with 0 packets. tcpslice(1) now mentions that and the problems above.
When using tcpslice to merge two capture files, if one of those files has just one packet, tcpslice will fail with following error:
tcpslice: problems finding end packet of file capture-file
This does not have to be just the action of merging two files. Just reading the one file with one packet ends up the same. This is reproducible in a following ways:
The error appears even when the captures are merged with a different tool like mergecap: