On Jun 27, 2012, at 12:24 AM, ri...@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.
