Re: rewind a capture file

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

On Jun 27, 2012, at 12:24 AM, rixed () happyleptic org wrote:

> I'd like to be able to read a pcap in a loop.
>
> There are two options I know of:
>
> - either close the pcap_handle when the pcap_dispatch/pcap_next function
>  returns the error-code for signaling end of file, and reopen it.
>
> - or retrieve the pcap FILE* with pcap_file(), and rewind by hand (ie. seek
>  after end of the global pcap header at offset 24, or getpos at first packet
>  and setpos later to rewind).
>
> It's inconvenient for me to simulate looping by closing/reopening the pcap
> file so I implemented the alternative (reset the file handle position), but it
> seams a little odd to do this kind of things by hand, and does not seams
> particularly future-proof since it assumes that the file current offset is set
> to next packet position,

...and that a file you've opened with pcap_open_offline() has a 24-byte header followed by a sequence of packets, which 
hasn't been guaranteed to be the case since libpcap 1.1.0; that was the first release that also read pcap-NG files.

> and that the file is actually not already closed when
> the end of file error code is returned.

That'll probably continue to be the case - there's no point in closing it until the application calls pcap_close().

> Is there a better way to do this?

Unfortunately, no.  pcap_seek() and pcap_tell(), or something such as that, might be a useful addition for this, 
although it's a bit more complicated for pcap-NG, as you want to handle, for example, seeking back and then re-reading 
an Interface Description Block.

> Is there a proper way to find out the file header's size?

For pcap, there's no alternative way, but the documentation:

        $ man pcap-savefile

                ...

        PCAP-SAVEFILE(5)                                            PCAP-SAVEFILE(5)



        NAME
               pcap-savefile - libpcap savefile format

        DESCRIPTION
               NOTE:  applications  and  libraries should, if possible, use libpcap to
               read savefiles, rather than having their own code  to  read  savefiles.
               If,  in the future, a new file format is supported by libpcap, applica-
               tions and libraries using libpcap to read savefiles  will  be  able  to
               read  the new format of savefiles, but applications and libraries using
               their own code to read savefiles will have to be changed to support the
               new file format.

               ``Savefiles''  read and written by libpcap and applications using libp-
               cap start with a per-file header.  The format of  the  per-file  header
               is:

                      +------------------------------+
                      |        Magic number          |
                      +--------------+---------------+
                      |Major version | Minor version |
                      +--------------+---------------+
                      |      Time zone offset        |
                      +------------------------------+
                      |     Time stamp accuracy      |
                      +------------------------------+
                      |       Snapshot length        |
                      +------------------------------+
                      |   Link-layer header type     |
                      +------------------------------+

says it's 24 bytes long, so that's not going to change.

It's pcap-NG that causes the problem (and support for reading other capture file formats might be added in the future).

> Also, out of curiosity, what was the intended use of pcap_file() in the first place?

I'm not sure, as I wasn't one of the developers in those days.  It *is* used by tcpslice, so perhaps it was added for 
that.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.